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

A project folder must be open for the MCP list to update. If Tabnine is open in you IDE without a workspace folder, the Tabnine MCP engine stays dormant. It won't read global or local JSON.

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.

.tabnine/mcp_servers.json can also be placed in the home directory: ~/.tabnine/mcp_servers.json

To direct to specific MCP servers, create the mcp_servers.json file, which will follow this structure here:

{
    "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. <server-name> – the name of the server itself

3. command – the script command that launches the server

Optional fields include:

1. args – command line arguments (with no spaces, otherwise they’ll be treated as separate paths)

2. env – environment key-value pairs

Here is an example of that structure filled in with variables for Jira:

{
  "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:

Category	MCP Servers
Development Tools	GitHub GitLab
Project Management	Notion - For Notion API
CloudOps	Azure - Access to Azure Storage, Cosmos DB, the Azure CLI, etc. Azure DevOps - Specific to services like repos, builds, releases, tests, code, etc. AWS AWS CloudTrail AWS CDK AWS Core Google Cloud Protocol
Database Tools	MCP Toolbox for Databases (open source) InfluxDB Qdrant ClickHouse Neon
Languages & Frameworks	Svelte Next.js
Monitoring	Grafana Elastic (Elasticsearch & Kibana)

Configuration Examples

Local MCP Server (Stdio Transport)

Detected by: Presence of command field

{
  "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)

{
  "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.

{
  "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

{
  "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)

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.