# Model Context Protocol servers (MCP)
## What is MCP?
The **Model Context Protocol (MCP)** is an open standard for connecting large language models (LLMs) to external tools, data sources, and APIs. *MCP servers* implement the MCP. They act as standardized interfaces that allow language models to communicate with external applications or systems—similar in concept to APIs, but specifically designed for LLM-driven interactions.
With Tabnine Agent, these are managed in a similar manner to creating guidelines, through a specific file.
***
### MCP Server Configuration
MCP servers are configured through a JSON file under the `.tabnine` folder in your project root:
First, enter the same `/.tabnine/` directory inside your project directory.
{% hint style="success" %}
`.tabnine/mcp_servers.json` can **also** be placed in the home directory:\
\
`~/.tabnine/mcp_servers.json`
{% endhint %}
To direct to specific MCP servers, create the `mcp_servers.json` file, which will follow this structure here:
```json
{
"mcpServers": {
"server-name": {
"command": "server-executable",
"args": [
"arg1",
"arg2"
],
"env": {
"API_KEY": "your-api-key",
"BASE_URL": "https://api.example.com"
}
}
}
}
```
In that `mcp_servers.json` file, list each server you want to include. For each server mentioned in the file, Tabnine Agent requires the following configuration components:
1. `mcp_server` — this is the top-level container
2. `` – the name of the server itself
3. `command` – the script command that launches the server
Optional fields include:
4. `args` – command line arguments (with no spaces, otherwise they’ll be treated as separate paths)
5. `env` – environment key-value pairs
Here is an example of that structure filled in with variables for Jira:
```json
{
"mcpServers": {
"mcp-atlassian": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"mcp-atlassian:latest"
],
"env": {
"JIRA_URL": "https://mcp.atlassian.com/v1/mcp",
"JIRA_API_TOKEN": "7H15-15_Ju57-4_54Mp13-4P1_C0D3-f0R_47145514n-Bu7_U-c4N-g3N3R473-Y0Ur-0Wn_Fr0M-y0Ur-J1R4_4Cc0Un7-47-1D-47145514N-C0M"
}
}
}
}
```
***
### Supported Transport Layers
The service automatically detects the transport type based on your configuration:
| ***Detected Transport*** | ***Configuration Field*** | ***Use Case*** |
| ------------------------ | ------------------------- | ---------------------------- |
| **STDIO** | `command` present | Local MCP servers, CLI tools |
| **Streamable HTTP** | `url` present | Modern remote APIs |
| **SSE** | `transport: "sse"` | Legacy remote servers |
***
### Commonly Used MCP Servers
There are dozens of available MCP integrations on the market, official MCP servers for individual third parties. Here are a few of commonly used ones:
## Configuration Examples
#### Local MCP Server (Stdio Transport)
**Detected by**: Presence of `command` field
```json
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/username/Documents"
],
"env": {
"NODE_ENV": "production",
"DEBUG": "mcp:*"
},
"cwd": "/Users/username/workspace"
}
}
}
```
**Properties**:
* `command` (required): The executable to run
* `args` (optional): Array of command-line arguments
* `env` (optional): Environment variables for the process
* `cwd` (optional): Working directory for the process
#### Remote MCP Server with JWT Authentication
**Detected by**: Presence of `url` field (defaults to Streamable HTTP)
```json
{
"mcpServers": {
"my-api": {
"url": "https://api.example.com/mcp",
"requestInit": {
"headers": {
"Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"Content-Type": "application/json"
}
}
}
}
}
```
**Properties**:
* `url` (required): The MCP endpoint URL
* `requestInit` (optional): Standard Fetch API RequestInit object
* `headers`: HTTP headers to include in all requests
* `sessionId` (optional): Session identifier for the connection
#### Remote MCP Server with API Key (multiple headers)
This example shows how various authorizations might appear in the `mcp_servers.json` file.
```json
{
"mcpServers": {
"weather-service": {
"url": "https://weather-mcp.example.com/mcp",
"requestInit": {
"headers": {
"Authorization": "Bearer token",
"X-API-Key": "api-key",
"X-Client-ID": "client-id",
"X-Environment": "production",
"X-Session-Token": "session-token-value"
}
}
}
}
}
```
#### Legacy SSE Server
**Detected by**: Explicit `transport: "sse"` field
```json
{
"mcpServers": {
"legacy-api": {
"transport": "sse",
"url": "https://old-api.example.com/sse",
"requestInit": {
"headers": {
"Authorization": "Bearer legacy-token-123"
}
},
"eventSourceInit": {
"withCredentials": true
}
}
}
}
```
**Properties**:
* `transport` (required): Must be `"sse"`
* `url` (required): The SSE endpoint URL
* `requestInit` (optional): Request configuration
* `eventSourceInit` (optional): EventSource-specific options
* `authProvider` (optional): OAuth client provider (advanced)
{% hint style="info" %}
Some MCP servers can silently fail OAuth authentication after a token is revoked on the provider side. When this happens, the local cached OAuth credentials remain in place, and the OAuth flow is *not* automatically re-triggered.
These cached OAuth credentials are stored in the .`mcp_auth` folder in your home folder. The fix is to remove the .mcp-auth folder. This removes all cached credentials and will force all new OAuth flows to retrigger.
Delete the `.mcp_auth` folder from the user’s home directory. This clears all cached OAuth credentials. The next MCP action requiring authentication will correctly trigger a fresh OAuth flow.
{% endhint %}
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.tabnine.com/main/getting-started/tabnine-agent/mcp-intro-and-setup.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.