For the complete documentation index, see llms.txt. This page is also available as Markdown.

MCP Servers

Beta · Tabnine plugin for OpenCode v0.5.1

The Tabnine plugin for opencode ships with two built-in Tabnine MCP servers and lets you add your own. This guide covers:

  • The built-in Remote Codebase Search and Coaching Guidelines servers

  • Viewing and disabling MCP servers

  • Adding your own MCP servers

  • How your organization's MCP governance applies

Looking for MCP in your IDE? This page covers the tabnine-opencode CLI. For MCP servers with Tabnine Agent in your IDE, see Understanding MCP Servers.

Built-in Tabnine MCP servers

Two Tabnine-hosted MCP servers are registered automatically, with no configuration needed:

  • tabnine-context – Remote Codebase Search. The agent is steered to prefer these tools for codebase-wide questions.

  • tabnine-coaching – Coaching Guidelines.

Both are remote (HTTP) servers authenticated with your Tabnine sign-in, and they stay authenticated for the life of the session. Each server registers only when your Tabnine deployment supports it (Coaching Guidelines additionally depends on your account's features), so you may see one, both, or neither depending on your setup.

You need to be signed in for the built-in servers to register. If you sign in during a running session, they come online without a restart. See Signing In and Working with Models.

See your connected servers

Run the /mcps command inside the TUI to open the MCP dialog. The built-in Tabnine servers appear there live, alongside any servers you added yourself.

Your existing opencode configuration also applies. tabnine-opencode reads your standard opencode config (for example ~/.config/opencode/opencode.json) in addition to its own Tabnine config directory at ~/.tabnine/opencode/config/opencode.json. MCP servers and other settings you already use with opencode work here too, so you may see your own servers in the /mcps dialog next to the built-in Tabnine ones. Where the same setting is defined in both places, the Tabnine config directory takes precedence.

Turn the built-in servers off

The built-in servers are on by default.

1

Disable a server for a single run

Set the matching environment variable to 0 or false before launching:

2

Disable a server permanently

Set a plugin option instead. Edit ~/.tabnine/opencode/config/opencode.json and turn the Tabnine plugin's string entry in the plugin array into a two-element tuple: the plugin specifier followed by an options object.

Replace /Users/you with your home directory, and keep any host option the installer already wrote in that object. A boolean plugin option takes precedence over the matching environment variable; when neither is set, the server is enabled.

Added the plugin to your own opencode too? Set the same options on the plugin's tuple in ~/.config/opencode/opencode.json instead.

Allow the Tabnine tools under strict permissions

The built-in servers expose tools under the keys tabnine_context_* and tabnine_coaching_*. If you run opencode with deny-by-default permissions, allow them explicitly in your opencode config (for the Tabnine install: ~/.tabnine/opencode/config/opencode.json):

Add your own MCP servers

You can connect your own MCP servers, both local (stdio) and remote (network) transports, by adding them to your opencode configuration. They then show up in the /mcps dialog next to the built-in Tabnine servers.

Add a top-level mcp map to an opencode config file. To make a server available everywhere, use the Tabnine config at ~/.tabnine/opencode/config/opencode.json; to scope it to one repository, put it in an opencode.json in that project's root instead. Each entry maps a server name to its configuration, with type selecting the transport:

  • type: "local" – runs the server as a subprocess. command is required: an array containing the command and its arguments. Optional fields: cwd, environment (a string map), enabled, timeout (ms).

  • type: "remote" – connects over the network. url is required. Optional fields: headers (a string map), oauth, enabled, timeout (ms).

The built-in Tabnine servers are registered at runtime and never appear in this map. The transport types and their fields are defined by opencode.

opencode reference: MCP servers are a standard opencode feature; see the opencode MCP servers docs for transports and the full schema, and the Config docs for where the mcp key lives.

Your organization governs MCP servers. Any MCP server you add is subject to your organization's MCP governance policy: a blocked server is removed and a toast tells you why, and a re-allowed server reconnects automatically. The built-in Tabnine servers are exempt and are never blocked. Administrators configure policy modes and allowlists in MCP Governance.

If a server is blocked by your organization

When your organization's policy blocks a server you configured, the CLI shows a toast:

MCP server "<name>" was blocked by your organization: <reason>

The reason states what the policy objected to. For example: "All MCP servers are blocked by your organization.", "Only remote MCP servers are allowed by your organization.", or "This MCP server is not in the allowlist." A blocked server is removed for the session, so it won't reconnect until the policy allows it.

Policy is re-checked every 5 minutes while the CLI runs, so an admin change takes effect without a restart. When a server becomes allowed again, you'll see:

MCP server "<name>" is now allowed by your organization and has been connected.

If you believe a server was blocked in error, contact your organization's Tabnine admin.

Next, see Scripts and CI to run tabnine-opencode non-interactively, or Troubleshooting for common fixes.

Last updated

Was this helpful?