Opencode - best MCP Plugins of 2026

Published: 2026-09-07

Introduction

By 2026, AI-assisted coding has stopped being an experiment and become the default way thousands of teams build software. As language models got better, so did the infrastructure around them: a whole ecosystem of protocols, formats and tools emerged that lets an agent do real work with the outside world — documentation, browsers, repositories, databases, cloud services and monitoring systems.

At the center of that infrastructure sits the Model Context Protocol (MCP) — an open protocol that, within a couple of years, became the de facto standard for attaching any tool to any AI agent. OpenCode, one of the fastest-growing terminal-based coding agents, was designed with first-class MCP support from the start. Today it can run both local and remote MCP servers with just a few lines of configuration.

This is a practical, in-depth review of the best MCP servers (often colloquially called "plugins") for OpenCode in 2026. We will cover the difference between MCP, plugins and built-in tools, how to set up local and remote servers, how OAuth authorization works, why heavy MCP servers can bloat your context window, and how to fight that. Then we will walk through a dozen of the most useful integrations one by one: from Context7 for up-to-date documentation to Playwright and Chrome DevTools for browser work, from GitHub MCP and Grep.app for code work to Sentry, Cloudflare, Supabase and Vercel for production infrastructure.

Every configuration below is taken from the official OpenCode documentation and the official repositories of the respective projects and was verified in September 2026.

OpenCode in a Nutshell

OpenCode is a powerful AI coding agent that lives in your terminal. Unlike many competitors, it is not tied to any editor or platform: you launch it anywhere, it reads your project structure, opens files, runs commands, works with git and hands the model real developer tools. As of this writing, OpenCode officially runs in the terminal (TUI), in a web interface, inside IDEs through dedicated extensions, and even as an Agent Client Protocol (ACP) backend for third-party editors.

The features that matter for this article:

Built-in tools — code search, file read/write, bash execution, web search and web page fetching. All of them are enabled by default and need no configuration.
Agent system — the built-in Build and Plan agents, plus the General, Explore and Scout subagents. Agents can be created and tuned, and you can restrict which tools and MCP servers they are allowed to touch.
MCP support — OpenCode officially supports both local and remote (HTTP) MCP servers. Connected MCP tools become available to the model on equal footing with the built-ins.
Plugins — JavaScript/TypeScript modules that hook into events and can add their own tools.
Rules and skills — AGENTS.md instruction files for the model and an Agent Skills mechanism for specialized workflows.
Flexible configuration — a single json file named opencode.json where you describe providers, models, agents, permissions, MCP servers and more.

It is also worth talking about the ecosystem: OpenCode is an open-source project with an active community. There are hundreds of ready-made plugins and a huge choice of MCP servers. That openness is exactly what makes OpenCode the perfect playground for MCP: everything in this article connects in minutes and works the same way on any operating system.

The official docs put it plainly: "Add local or remote MCP tools. You can add external tools to OpenCode using the Model Context Protocol" (https://opencode.ai/docs/mcp-servers/). Once connected, MCP tools automatically enter the model's hands alongside the built-in ones.

What is MCP and Why You Need It

The Model Context Protocol was introduced by Anthropic in late 2024 as an open standard that was supposed to solve a fundamental problem: every AI agent had its own, incompatible plugin ecosystem. A tool written for Claude Desktop could not be reused in another agent, and every integration had to be rewritten for every platform.

MCP fixed this radically. At its core it is a client-server protocol on top of JSON-RPC that defines three things:

Tools — functions the model can call from its runtime.
Resources — structured data the client can read.
Prompts — ready-made prompt templates a server can recommend.

The client — in our case OpenCode — connects to an MCP server, pulls the list of available tools together with their descriptions and argument schemas, and passes those descriptions to the language model. The model itself decides when to call which tool; the result returns into its reasoning loop. It looks a lot like function calling, but it works with any client and any server that implements the standard.

Why did MCP conquer the industry so fast? Several reasons:

Universal — one server works with dozens of clients: OpenCode, Claude Desktop, Cursor, Windsurf, VS Code, Copilot, Codex and others.
Two transports — a server can run locally as a subprocess (stdio) or be published on the internet as an HTTP service. Local transport fits filesystem and private integrations; remote fits cloud services.
Security and control — the client decides which servers to connect and which tools to allow.
A live community and a registry — the official MCP registry (registry.modelcontextprotocol.io) lists thousands of servers, and the list of reference servers is maintained by the protocol's steering group.

By 2026 MCP has effectively become the industry standard: every major vendor — GitHub, Cloudflare, Sentry, Supabase, Vercel, Firecrawl — ships its own official MCP server. That means you no longer write integrations by hand: just connect a ready server and describe to the model what you want done.

One terminology note up front: the word "plugins" in the title of this article is used loosely, in the sense of "ready-made extensions". Strictly speaking, MCP servers and OpenCode plugins are different things — the next section explains exactly how.

MCP, Plugins and Built-in Tools: What's the Difference

People often confuse the three ways you can extend OpenCode. They sound similar but work very differently.

Built-in tools

Out of the box OpenCode already ships a set of built-in tools: file read and write (read, write, edit), code search (grep, glob), shell commands (bash), web page fetching (webfetch) and web search (websearch). They need no setup and work immediately. The docs note that by default all tools are enabled and need no permission to run.

For many basic tasks that set is enough: the agent can read a project, find a bug, run tests and commands. But once the task leaves the filesystem — you need current library docs, a page opened in a real browser, GitHub access, a Sentry issue, or a Vercel deploy — the built-ins run out of steam. That is where MCP and plugins come in.

MCP servers

MCP is about connecting external tools and services. OpenCode's docs define it like this: "MCP servers allow you to integrate external tools and services. This includes database access, API integrations, and third-party services" (https://opencode.ai/docs/tools/).

A server is a separate process or a remote service that talks to OpenCode over the standard protocol. OpenCode connects to it on startup, pulls the tool list and hands it to the model. In effect MCP is the fastest way to "bolt in" a ready-made integration: thousands of servers have already been written by the community and the vendors.

OpenCode plugins

A plugin is a JavaScript/TypeScript module that runs inside OpenCode itself. Per the official docs, "plugins allow you to extend OpenCode by hooking into various events and changing the behavior" (https://opencode.ai/docs/plugins/). Plugins see events (commands, file changes, messages, tool runs), can alter tool arguments before execution (tool.execute.before / tool.execute.after hooks), add their own tools through a dedicated SDK, send system notifications, protect .env files, and even steer session compaction.

If MCP is an external battery connected through a standard socket, a plugin is more like surgery on the device itself: code that is deeply integrated into the agent's lifecycle and works with its internal events.

When to use what

The practical rule of thumb is:

Use MCP when you want to quickly attach a ready-made external integration: documentation, browser, GitHub, clouds, databases, monitoring. That is the main scenario of this article.
Use a plugin when you need to modify OpenCode's own behavior: hook tools, protect files, add event logic, inject environment variables.
Rely on built-in tools when the task is already solved by base means — reading files, searching, bash, webfetch. Do not connect MCP for features you already have: every connected server costs tokens.

Firecrawl is a nice example of the duality: you can use it through its MCP server or through the official opencode-firecrawl plugin. The MCP server is convenient when you want the scraping tools available to the agent on par with other servers. The plugin connects to OpenCode's own machinery and drives the Firecrawl CLI directly.

There is a similar overlap for web search: OpenCode has a built-in websearch that works through Exa or Parallel providers and needs no API key when you use OpenCode's official provider. That partly covers the niche of Firecrawl-style or Brave Search servers for simple searches. But the deep scenarios — crawling, data extraction, SPA rendering, Markdown conversion — still belong to the specialized servers.

How to Connect an MCP Server in OpenCode

MCP servers in OpenCode are declared in the opencode.json config file under the mcp section. Every server needs a unique name that you will use when talking to the model — for example, "use context7" or "use the gh_grep tool".

The general shape looks like this:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "name-of-mcp-server": {
      "enabled": true
    }
  }
}

As you can see, you can mark a server disabled (enabled: false) right away — handy when you want to switch a server off temporarily without deleting it.

Now to the two kinds of servers: local and remote.

Local MCP servers

Local servers run as a child process spawned from the command line and talk to OpenCode over standard input/output (stdio). To configure them you use type: "local" and a command array.

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "my-local-mcp-server": {
      "type": "local",
      "command": ["npx", "-y", "my-mcp-command"],
      "enabled": true,
      "environment": {
        "MY_ENV_VAR": "my_env_var_value"
      }
    }
  }
}

The full list of options for a local server:

Option	Type	Required	Description
type	String	Yes	MCP connection type, must be "local"
command	Array	Yes	Command and arguments used to spawn the MCP server
cwd	String	No	Working directory for the server process; relative paths resolve from the project root
environment	Object	No	Environment variables passed to the server
enabled	Boolean	No	Enable or disable the server at startup
timeout	Number	No	Timeout in milliseconds for loading the server's tools; default 5000

Pay attention to the environment field: that is how you pass API keys and other secrets. For GitHub MCP that might be GITHUB_PERSONAL_ACCESS_TOKEN, for Playwright MCP — configuration variables, for Mem0 — MEM0_API_KEY. Never hard-code keys into the config text; use environment variables instead.

Remote MCP servers

Remote servers live somewhere on the internet and talk to OpenCode over Streamable HTTP. You use type: "remote" and a url.

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "my-remote-mcp": {
      "type": "remote",
      "url": "https://my-mcp-server.com",
      "enabled": true,
      "headers": {
        "Authorization": "Bearer MY_API_KEY"
      }
    }
  }
}

Options for a remote server:

Option	Type	Required	Description
type	String	Yes	Connection type, must be "remote"
url	String	Yes	URL of the remote MCP server
enabled	Boolean	No	Enable or disable the server at startup
headers	Object	No	HTTP headers for requests to the server
oauth	Object	No	OAuth configuration, see the dedicated section
timeout	Number	No	Timeout in milliseconds for loading the server's tools; default 5000

The upside of remote servers is obvious: you install nothing locally, the vendor runs it. Context7, Grep.app, Sentry, Cloudflare, Supabase and Vercel all work this way. Organizations can also publish "default" MCP servers behind their own .well-known/opencode endpoint, and users can enable them in local config while overriding the settings.

Managing servers

Connected MCP servers become OpenCode tools alongside the built-ins, so you can switch them on and off right from the config, in the tools section. This works on two levels: globally and per-agent.

Global disable by server name:

{
  "mcp": {
    "my-mcp-foo": { "type": "local", "command": ["bun", "x", "my-mcp-command-foo"] },
    "my-mcp-bar": { "type": "local", "command": ["bun", "x", "my-mcp-command-bar"] }
  },
  "tools": {
    "my-mcp-foo": false
  }
}

And with glob patterns you can switch off all tools of several servers at once:

{
  "tools": {
    "my-mcp*": false
  }
}

One key detail: the tools of an MCP server are registered with the server name as a prefix. So to disable every tool of one server all you need is "<server_name>_*": false.

Per-agent setup

If you have many MCP servers, you can keep them disabled globally and only enable them in the agents where they are actually needed. The official docs recommend exactly this recipe for situations where "heavy" servers are not required every time.

The sequence is simple:

Disable the server as a tool globally (tools: {"my-mcp*": false}).
Enable it for a specific agent via agent.<name>.tools.

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "my-mcp": {
      "type": "local",
      "command": ["bun", "x", "my-mcp-command"],
      "enabled": true
    }
  },
  "tools": { "my-mcp*": false },
  "agent": {
    "my-agent": {
      "tools": { "my-mcp*": true }
    }
  }
}

This approach is especially useful for GitHub MCP and other servers with dozens of tools: the model only "sees" them in the agents where they matter and does not spend tokens on their descriptions elsewhere.

OAuth Authorization for Remote MCP

Many remote MCP servers require authorization. OpenCode handles OAuth authentication for remote servers automatically. The mechanics, per the docs (https://opencode.ai/docs/mcp-servers/):

OpenCode detects a 401 response from the server and kicks off the OAuth flow.
Dynamic Client Registration (RFC 7591) is used when the server supports it.
Tokens are stored securely for subsequent requests.

For most OAuth servers you need no special config at all; just point at the URL:

{
  "mcp": {
    "my-oauth-server": {
      "type": "remote",
      "url": "https://mcp.example.com/mcp"
    }
  }
}

On first use OpenCode will offer to authorize. If that does not happen, you can start the flow manually:

opencode mcp auth my-oauth-server

More commands for managing credentials:

# list all MCP servers and their authorization status
opencode mcp list

# delete saved credentials
opencode mcp logout my-oauth-server

# authorization status for all OAuth servers
opencode mcp auth list

# connection and OAuth diagnostics for a specific server
opencode mcp debug my-oauth-server

The opencode mcp auth command opens a browser for authorization. After confirmation the tokens are saved encrypted to ~/.local/share/opencode/mcp-auth.json.

If your MCP provider has handed you ready-made client credentials, you can pre-configure them:

{
  "mcp": {
    "my-oauth-server": {
      "type": "remote",
      "url": "https://mcp.example.com/mcp",
      "oauth": {
        "clientId": "{env:MY_MCP_CLIENT_ID}",
        "clientSecret": "{env:MY_MCP_CLIENT_SECRET}",
        "scope": "tools:read tools:execute"
      }
    }
  }
}

Finally, for servers that use plain API keys instead of OAuth, you can disable OAuth explicitly:

{
  "mcp": {
    "my-api-key-server": {
      "type": "remote",
      "url": "https://mcp.example.com/mcp",
      "oauth": false,
      "headers": {
        "Authorization": "Bearer {env:MY_API_KEY}"
      }
    }
  }
}

The oauth fields support clientId, clientSecret and scope. If clientId is omitted, OpenCode attempts dynamic client registration. Note the {env:VARIABLE_NAME} syntax — this is how OpenCode injects environment variable values into the config without exposing secrets in files.

How MCP Affects the Context Window

The most important practical nuance, warned about right in the official docs, is the effect of MCP on context size. The docs say: "When you use an MCP server, this increases the context. This can add up quickly if you have many tools. Therefore, we recommend being careful about which MCP servers you use" (https://opencode.ai/docs/mcp-servers/).

Here is why. Every time OpenCode starts, it collects the descriptions of all tools of all connected servers and puts them into the model context. Each tool is a name, a description and a parameter schema. For servers with dozens of tools — GitHub MCP in particular — that volume easily reaches thousands of tokens. The docs single GitHub out: "Some MCP servers like GitHub MCP add a lot of tokens and can easily blow up the context limit".

What does this mean in practice?

Do not connect every server at once. Start with three to five and add others as needed.
Do not duplicate functionality already covered by OpenCode's built-ins: files, search, web search.
For big servers use per-agent enablement and global disabling (see above).
For servers that let you choose a subset of tools (like GitHub MCP with its toolsets), configure the bare minimum.

Newer OpenCode versions also added a "lazy loading" mechanism: when MCP tool descriptions exceed a threshold (roughly 10% of the context window), they are offloaded from the main context and pulled back on demand through a dedicated search tool. This noticeably relieves the context, but it does not solve the problem on its own — smart configuration still beats hope in automation.

And to close the terminology loop: most solutions below are MCP servers rather than plugins in the strict sense of the word. Colloquially they are still called "OpenCode plugins", and that is exactly how this roundup groups them.

Top MCP Servers for OpenCode

Here is the whole selection in one table; details come below. Scores reflect practical value for a typical developer in 2026.

MCP server	What for	Kind	Transport	Score
Context7	Up-to-date docs for libraries and APIs	Remote	HTTP	★★★★★
Playwright MCP	Browser: sites, DOM, clicks, screenshots	Local	stdio	★★★★★
Chrome DevTools MCP	Chrome, console, Network, performance	Local	stdio	★★★★★
GitHub MCP	Repos, issues, PRs, GitHub API	Local/Remote	HTTP/stdio	★★★★★
Grep.app	Real-code search across public GitHub repos	Remote	HTTP	★★★★½
Firecrawl	Deep web scraping and crawling	Local/Remote	stdio/HTTP	★★★★½
Sentry MCP	Errors, stack traces, production monitoring	Remote	HTTP	★★★★
Memory MCP	Long-term agent memory (knowledge graph)	Local	stdio	★★★★
Mem0 MCP	Commercial memory platform	Remote	HTTP	★★★
Sequential Thinking	Step-by-step problem solving	Local	stdio	★★★★
Cloudflare MCP	DNS, Workers, Pages, KV, R2, tunnels	Remote	HTTP	★★★★½
Supabase MCP	Database and Supabase platform	Remote	HTTP	★★★★
Vercel MCP	Vercel projects, deploys, analytics	Remote	HTTP	★★★★

One honest caveat about this list: the OpenCode documentation officially provides only three ready-made examples — Sentry, Context7 and Grep by Vercel (plus a test server called server-everything). The other servers are official vendor integrations that the community and the ecosystem actively recommend. We flag this per service below.

Context7 — Up-to-Date Library Documentation

Context7 is a service by Upstash that gives the model current documentation for popular libraries and frameworks. Instead of "guessing" an API from training data — which objectively goes stale with every release — the model uses Context7 to fetch the relevant sections of the docs and use them.

Supported track includes Node.js, Python, React, Next.js, Laravel, Docker, Cloudflare, the OpenAI API and hundreds of others. This is especially valuable for fast-moving libraries: parameter schemas, new methods, behavioral changes.

Context7 is one of the three servers officially documented in the OpenCode guide. The base config:

{
  "mcp": {
    "context7": {
      "type": "remote",
      "url": "https://mcp.context7.com/mcp"
    }
  }
}

An API key is optional, but registering for a free account raises your request limits. Config with a key:

{
  "mcp": {
    "context7": {
      "type": "remote",
      "url": "https://mcp.context7.com/mcp",
      "headers": {
        "CONTEXT7_API_KEY": "{env:CONTEXT7_API_KEY}"
      }
    }
  }
}

This assumes the CONTEXT7_API_KEY environment variable is already set on your machine.

Usage in prompts is trivial — just mention the service: for example, "Use context7 and check the current OpenAI SDK API". You can also add a rule to your project's AGENTS.md like "When you need documentation, use the context7 tools", and the model will reach for Context7 automatically.

In a nutshell, Context7 closes the biggest pain of modern AI agents: stale knowledge about the latest library versions. It deserves the first spot in any roundup.

Playwright MCP — Browser Automation

Playwright MCP is Microsoft's official browser-automation server (repository microsoft/playwright-mcp). It lets the agent open sites, click, type, fill forms, drag and drop, upload files, read the page's accessibility tree, take screenshots, and inspect console messages and network requests.

The key trick: the server works not with pixel images but with a structured accessibility tree of the page. That is faster, cheaper in tokens and more accurate than screenshots. No vision models required.

Main capabilities:

browser_navigate — open a page by URL.
browser_click, browser_hover, browser_drag, browser_drop — interact with elements.
browser_type, browser_fill_form, browser_select_option — type text and fill forms.
browser_snapshot — snapshot of the accessibility tree (better than a screenshot).
browser_take_screenshot — screenshot of a page or an element.
browser_evaluate — run JavaScript on the page.
browser_console_messages — read the browser console.
browser_network_requests — list network requests.
browser_tabs — manage tabs.
browser_run_code_unsafe — run arbitrary Playwright code (use with caution).

Optionally the --caps flag adds more: network (request mocking), storage (cookies and localStorage), pdf, vision (coordinate-based work) and devtools.

The standard OpenCode config (from the official README):

{
  "mcp": {
    "playwright": {
      "type": "local",
      "command": ["npx", "@playwright/mcp@latest"],
      "enabled": true
    }
  }
}

You can also launch the server headless (--headless), pick a browser (chromium, firefox, webkit, msedge), emulate a mobile device (--device "iPhone 15"), set the viewport, a proxy or timeouts. The Docker image runs via docker run and supports only headless-chromium.

One important limitation: Playwright MCP is built for exploratory and long-lived browser automation, not for running E2E test suites. The official README recommends Playwright CLI plus a suite of Skills for tests and "high-performance" agents, because CLI calls use tokens far more efficiently: they do not load big tool schemas and verbose accessibility trees into context.

Chrome DevTools MCP — Deep Browser Analysis

Chrome DevTools MCP is Google Chrome's official server (repository ChromeDevTools/chrome-devtools-mcp, over 51,000 GitHub stars as of September 2026). It gives the agent the full power of DevTools: console, network, DOM, performance, Lighthouse, screenshots, JavaScript execution, even memory analysis.

The real feature set splits into categories:

Input automation: click, click_at, drag, fill, fill_form, hover, press_key, type_text, upload_file.
Navigation: navigate_page, new_page, list_pages, select_page, close_page, wait_for.
Emulation: viewport, network throttling, geolocation, user-agent.
Performance: trace recording with Core Web Vitals (LCP, INP, CLS) and insights analysis.
Network: list and details of network requests.
Debugging: evaluate_script, console with source-mapped stack traces, lighthouse_audit, screenshots, accessibility-tree snapshots.
Memory: heap snapshots and leak analysis (opt-in).
PWA, extensions, WebMCP — toggled with dedicated flags.

Standard config:

{
  "mcp": {
    "chrome-devtools": {
      "type": "local",
      "command": ["npx", "-y", "chrome-devtools-mcp@latest"]
    }
  }
}

For simple jobs there is a slim mode with just 3 tools and a headless flag:

{
  "mcp": {
    "chrome-devtools": {
      "type": "local",
      "command": ["npx", "-y", "chrome-devtools-mcp@latest", "--slim", "--headless"]
    }
  }
}

A common misconception from older reviews is that Chrome DevTools "only diagnoses" while Playwright "drives". In 2026 that is simply wrong: Chrome DevTools MCP automates the browser just as fully (clicks, forms, navigation), and its real edge is diagnostic depth — performance traces, memory snapshots, Lighthouse, fine-grained network analysis. The actual difference:

Playwright MCP — cross-browser automation (Chromium, Firefox, WebKit, Edge), accessibility-tree workflow, more "actions on the page".
Chrome DevTools MCP — Chrome only (Google Chrome and Chrome for Testing are officially supported), but with uniquely deep diagnostics.

Two things to know before you run it:

Google collects usage statistics by default (call success, latencies). Turn it off with --no-usage-statistics or the CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS environment variable.
Performance tools may send trace URLs to the CrUX API to cross-reference lab and field data. That is off by default; disable explicitly with --no-performance-crux.

For site, WordPress and MediaWiki work, the combo "Playwright for actions + Chrome DevTools for diagnosis" saves hours of manual testing.

GitHub MCP — The Whole of GitHub in the Agent's Hands

GitHub's official MCP server (repository github/github-mcp-server, over 32,000 stars as of September 2026) gives the agent a large slice of the platform: repositories, files, issues, pull requests, actions, code scanning, dependabot, gists, discussions, projects and more.

The modern version supports two ways to connect: a hosted GitHub server with OAuth, and a local server (Docker or binary) with a PAT.

The remote option:

{
  "mcp": {
    "github": {
      "type": "remote",
      "url": "https://api.githubcopilot.com/mcp/"
    }
  }
}

The local option via Docker, with the token injected as an environment variable:

{
  "mcp": {
    "github": {
      "type": "local",
      "command": ["docker", "run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"]
    }
  }
}

The defining trait of this server is the sheer number of tools, organized into toolsets: context, repos, issues, pull_requests, users, actions, code_security, code_quality, dependabot, discussions, gists, git, governance, labels, notifications, orgs, projects, secret_protection, security_advisories, stargazers, copilot and others. The default set is context, repos, issues, pull_requests, users.

This is exactly where the OpenCode docs' context-bloat warning kicks in. GitHub MCP is the textbook "heavy" server: dozens of tools, each with a big parameter schema. Just one of them can add thousands of tokens.

How to fight it:

Use toolsets and the --toolsets flag to enable only the groups you need. For example:

github-mcp-server --toolsets repos,issues,pull_requests,actions,code_security

or via the GITHUB_TOOLSETS="repos,issues,pull_requests" environment variable.

Disable GitHub MCP globally in OpenCode and only turn it on in the agents that need it (see the per-agent section).
For reading code in popular repositories you might skip GitHub MCP entirely — that used to be what Grep.app was for (next section).

Token hygiene deserves a paragraph. The official repo recommends separate tokens per project, minimal scopes, regular rotation, and never committing tokens. The environment field in the OpenCode config is the right home for such secrets.

Grep.app — Real-Code Search Across GitHub

Grep.app (a.k.a. Grep by Vercel) searches hundreds of millions of lines of code in all public GitHub repositories. Its MCP server lets the agent answer questions like:

"Find real implementations of this function in popular Node.js projects."
"Show how other projects use this API."
"Check how this error is handled in a well-known framework."

For a developer that is an invaluable source of practical examples: instead of the model's abstract knowledge, the agent finds how open-source code actually looks.

Grep.app is the third server officially described in the OpenCode docs. Config:

{
  "mcp": {
    "gh_grep": {
      "type": "remote",
      "url": "https://mcp.grep.app"
    }
  }
}

Use it by adding a prompt like "What's wrong here? Find an open-source usage example, use gh_grep" or an AGENTS.md rule like "If you are unsure how to do something, use gh_grep to search GitHub for code examples".

A practical caveat: the public endpoint historically has occasional stability hiccups (504s). Treat Grep.app as a supplementary source, not a single point of failure. For critical tasks keep an alternative handy — GitHub code search or the built-in websearch.

Firecrawl — Deep Web Scraping

Firecrawl is an internet research service specializing in scraping, crawling, extraction and page-to-Markdown conversion. Unlike a plain webfetch, Firecrawl can:

render JavaScript pages (SPAs) and extract their real content;
crawl sites by following links with configurable depth and limits;
extract structured data against a schema;
return clean Markdown, easy for a language model to chew;
handle dynamic and "heavy" pages that a plain HTTP request never returns.

The official repository is mendableai/firecrawl-mcp-server. You can run the server locally (stdio) or point at the cloud endpoint (https://mcp.firecrawl.dev/mcp). The cloud option needs an API key.

Local server config:

{
  "mcp": {
    "firecrawl": {
      "type": "local",
      "command": ["npx", "-y", "firecrawl-mcp"]
    }
  }
}

Remote config:

{
  "mcp": {
    "firecrawl": {
      "type": "remote",
      "url": "https://mcp.firecrawl.dev/mcp",
      "headers": { "Authorization": "Bearer {env:FIRECRAWL_API_KEY}" }
    }
  }
}

To be fair, OpenCode's built-in websearch and webfetch already cover basic web reading. Firecrawl earns its place when you need the heavy stuff: crawling a whole site section, extracting data, or walking dynamic pages. There is also an official opencode-firecrawl plugin that drives the Firecrawl CLI directly.

Sentry MCP — Production Monitoring

Sentry MCP (repository getsentry/sentry-mcp) connects the agent to your Sentry account: errors, stack traces, issues, releases and traces from production environments. For teams running real services this is one of the most useful connections there is — the agent can figure out itself where the app broke and why.

Sentry MCP is also one of the three official examples in the OpenCode docs. Config:

{
  "mcp": {
    "sentry": {
      "type": "remote",
      "url": "https://mcp.sentry.dev/mcp",
      "oauth": {}
    }
  }
}

After adding the config you must authorize:

opencode mcp auth sentry

Once authorized you can use Sentry tools in prompts: "Show the latest unresolved issues in my project. use sentry". The agent gets access to event search, issue reading, error analysis and traces.

Architecturally, Sentry MCP is a cloud service on top of the official Sentry API: it acts as a layer optimized for human-centric coding-agent workflows. There is also a local (stdio) variant, especially handy for self-hosted Sentry; for AI-driven search over events and issues you will need to configure an LLM provider (OpenAI, Anthropic or OpenRouter).

Worth knowing: the historical Sentry reference server in the modelcontextprotocol/servers repository has been archived — development now lives in the official getsentry/sentry-mcp. Same story as GitHub (see the reference-servers section below).

Memory: Memory MCP and Mem0

Long-term memory is a topic that fascinates everyone working with agents on large projects. You want the agent to remember project architecture, decisions, API quirks, rules, past fixes — and not forget them between sessions.

Memory MCP (reference server)

Memory is one of the protocol's official reference servers (modelcontextprotocol/servers, src/memory). It implements memory as a knowledge graph: entities, relations between them, and observations. The server runs locally and stores the graph in a file.

Config:

{
  "mcp": {
    "memory": {
      "type": "local",
      "command": ["npx", "-y", "@modelcontextprotocol/server-memory"]
    }
  }
}

Pros: simplicity, privacy (data stays local), open source. Constraint: scalability and graph search are limited by the server's capabilities.

Mem0

Mem0 is a commercial long-term memory platform with its own API and extras: semantic search, user segmentation, per-user/per-agent/per-app memory.

The historic open-source repository mem0ai/mem0-mcp was archived by the owners in March 2026: development moved to the official cloud service at https://mcp.mem0.ai/mcp. This matters because plenty of 2025 reviews still describe Mem0 as a "self-hostable server", which is no longer quite accurate.

Cloud config:

{
  "mcp": {
    "mem0": {
      "type": "remote",
      "url": "https://mcp.mem0.ai/mcp"
    }
  }
}

There is also a local mem0-mcp-server package (uvx mem0-mcp-server), but it requires MEM0_API_KEY and is essentially a thin wrapper over the platform.

Practical advice: both systems are good, but do not install them first. Get your base stack running (Context7, GitHub, Playwright, Firecrawl), confirm it is useful, then add memory.

Sequential Thinking — Step-by-Step Reasoning

Sequential Thinking is another official reference server (src/sequentialthinking in modelcontextprotocol/servers). It adds a tool that helps the agent structure solutions of complex multi-step problems: analyze the architecture, form hypotheses, verify them, make decisions, implement and check the result.

Config:

{
  "mcp": {
    "sequentialthinking": {
      "type": "local",
      "command": ["npx", "-y", "@modelcontextprotocol/server-sequential-thinking"]
    }
  }
}

The honest 2026 take: the line between this server and modern reasoning models has blurred. Many new models reason structurally out of the box, without an explicit "chain of thought" tool. So Sequential Thinking is a supplementary tool for specific scenarios (surveyable step-by-step reasoning, hypothesis verification) rather than a must-have in every stack. For most tasks a modern model will manage on its own.

Cloudflare MCP — All of Cloudflare's Infrastructure

Cloudflare MCP is not one server but a family of official servers (repository cloudflare/mcp-server-cloudflare, around 4,000 stars, plus cloudflare/mcp for the Code Mode server). Together they cover nearly the whole platform: DNS, Workers, Pages, KV, R2, tunnels, zones, analytics, observability and more.

Cloudflare's cloud servers run on Streamable HTTP and need no local install. Each domain is its own server:

https://mcp.cloudflare.com/mcp — the Code Mode server (recommended, broad access via code execution);
https://docs.mcp.cloudflare.com/mcp — Cloudflare documentation;
https://bindings.mcp.cloudflare.com/mcp — Workers Bindings;
https://builds.mcp.cloudflare.com/mcp — Workers Builds;
https://observability.mcp.cloudflare.com/mcp — logs and analytics;
https://containers.mcp.cloudflare.com/mcp — development sandboxes;
https://browser.mcp.cloudflare.com/mcp — web pages to Markdown and screenshots;
plus logs.mcp.cloudflare.com, ai-gateway.mcp.cloudflare.com, dns-analytics.mcp.cloudflare.com, radar.mcp.cloudflare.com and others.

A typical Code Mode config:

{
  "mcp": {
    "cloudflare": {
      "type": "remote",
      "url": "https://mcp.cloudflare.com/mcp"
    }
  }
}

After OAuth authorization the agent can handle tasks like "check the DNS zone and find records pointing at the old server" or "deploy a Worker script". Instead of hand-writing curl calls to the Cloudflare API, the model works with the infrastructure directly.

One nice touch of the big remote family: it pairs well with Context7 — the OpenCode docs even show an example of asking for a Cloudflare Worker config with "use context7".

Supabase MCP — Database and Platform

Supabase MCP (repository supabase/mcp, around 3,000 stars) connects the agent to your Supabase projects. It runs as a remote server and provides tools for managing tables, reading configurations, running queries and working with platform services.

Config:

{
  "mcp": {
    "supabase": {
      "type": "http",
      "url": "https://mcp.supabase.com/mcp"
    }
  }
}

On first connection the agent will ask you to sign in to Supabase in the browser and pick an organization with the project you need. URL parameters let you restrict the server: for example, https://mcp.supabase.com/mcp?project_ref=<project-ref>&read_only=true&features=database,docs gives read-only access to the database and docs. A great example of lowering risk for production data.

A local variant exists too: with Supabase CLI running, the MCP server is available at http://localhost:54321/mcp (limited tool set, no OAuth).

Vercel MCP — Projects, Deploys, Analytics

Vercel MCP is Vercel's official remote server (docs: https://vercel.com/docs/agent-resources/vercel-mcp). It gives the agent access to projects and deploys, documentation search, visit and view analytics, deploy logs and web analytics.

The server lives at https://mcp.vercel.com and uses OAuth. In most clients you can just run:

npx add-mcp https://mcp.vercel.com

For OpenCode you configure it as a remote:

{
  "mcp": {
    "vercel": {
      "type": "remote",
      "url": "https://mcp.vercel.com"
    }
  }
}

A technical nuance worth knowing: Vercel MCP only accepts Vercel-approved clients. This is a conscious guard against "confused deputy" attacks and forged OAuth requests. If a client is not on the supported list, authorization may be rejected.

Web analytics and deploys are where Vercel shines as a platform, so this server is especially valuable for teams that push frontends to Vercel regularly.

Additional Reference MCP Servers

Beyond the above, it is worth knowing the protocol's official reference servers, even though OpenCode's built-ins make some of them partially redundant.

Server	Purpose	Launch command
Filesystem	Safe filesystem access	npx -y @modelcontextprotocol/server-filesystem /path
Fetch	Fetch web content and convert for LLM use	npx -y @modelcontextprotocol/server-fetch
Git	Read, search and operate on git repositories	uvx mcp-server-git
Memory	Graph-based long-term memory	npx -y @modelcontextprotocol/server-memory
Sequential Thinking	Step-by-step reasoning	npx -y @modelcontextprotocol/server-sequential-thinking
Time	Time and time zones	npx -y @modelcontextprotocol/server-time

These servers are maintained by the protocol's steering group and serve as canonical implementation examples. An important note from their README: they exist to demonstrate MCP's capabilities and act as examples for developers, not necessarily as production-ready solutions. For production, evaluate your own security requirements.

The historical GitHub and Sentry reference servers that once lived in this repository are archived — replaced by the official github/github-mcp-server and getsentry/sentry-mcp. The full list of archived servers also includes PostgreSQL, Slack, Puppeteer, Brave Search, Google Drive, Google Maps, SQLite, Redis and others. The current catalog of third-party servers lives at the official MCP registry: https://registry.modelcontextprotocol.io/.

Official Config Examples from the OpenCode Docs

For completeness, here are the three official OpenCode doc examples you can use as a starting point.

Sentry:

{
  "mcp": {
    "sentry": {
      "type": "remote",
      "url": "https://mcp.sentry.dev/mcp",
      "oauth": {}
    }
  }
}

Context7:

{
  "mcp": {
    "context7": {
      "type": "remote",
      "url": "https://mcp.context7.com/mcp"
    }
  }
}

Grep by Vercel:

{
  "mcp": {
    "gh_grep": {
      "type": "remote",
      "url": "https://mcp.grep.app"
    }
  }
}

Plus a test server to verify the mechanics (it adds a tool that adds two numbers):

{
  "mcp": {
    "mcp_everything": {
      "type": "local",
      "command": ["npx", "-y", "@modelcontextprotocol/server-everything"]
    }
  }
}

Use it like this: write "use the mcp_everything tool to add the numbers 3 and 4" and watch MCP work.

Security of Browser MCP Servers

Browser servers (Playwright MCP, Chrome DevTools MCP) are the most powerful extensions — and the most dangerous. Here is what you must know.

Playwright MCP

The official README states it plainly: Playwright MCP is not a security boundary. Main risks:

Prompt injection through page content — a malicious web page can contain instructions the model might start following as if they were its own. Mitigation exists in the host/origin restrictions (--allowed-hosts, --allowed-origins, --blocked-origins).
Credential and token leakage — traces can contain network headers with authorization data. Never run the server against your personal or production browser; use test accounts.
Filesystem access — by default the server is restricted to workspace roots, but --allow-unrestricted-file-access widens that. That flag is a "convenience", not a security feature.
Default mode — the server starts headed (with a visible window). Use --headless for CI and servers.

Recommendations: keep it on stdio (local), constrain allowed-origins, test with isolated accounts, never attach a prod browser, and treat browser_run_code_unsafe with the respect it deserves (it is effectively RCE inside the server process).

Chrome DevTools MCP

Google issues similar warnings:

The server exposes browser content to MCP clients: "avoid sharing sensitive or personal information that you do not want to expose to MCP clients".
Only Google Chrome and Chrome for Testing are officially supported.
Google collects usage statistics by default (disable with --no-usage-statistics).
Performance traces may go to the CrUX API for field/lab comparison (disable with --no-performance-crux).

The general rule for both servers: connect a browser MCP only when the task truly requires browser automation, and never leave them enabled "just in case".

Avoiding Context Bloat in Practice

A practical checklist for keeping context lean when you run many MCP servers:

Start small. Connect the 3-5 servers you need right now. More is not better.
Use per-agent setup. Disable the heavy servers globally (tools: {"<name>_*": false}) and only enable them in the agents that need them.
Restrict the server's own tools. For GitHub MCP configure toolsets and tools; for Supabase use read_only=true and the features parameters; for Chrome DevTools use --slim.
Do not duplicate built-ins. File access, search, bash, webfetch and websearch already exist in OpenCode — do not attach MCP for them.
Use session compaction. OpenCode has a compaction option, plus the prune parameter removes stale tool outputs to save tokens. The opencode-dynamic-context-pruning plugin also trims outdated tool outputs.
Split servers by role: one "research + browser" stack (Context7, Firecrawl, Playwright, Grep.app) and separate production integrations (Sentry, Cloudflare, GitHub) for specific jobs.

Stick to the "3-6 active servers" rule of thumb for a typical session: it is the sweet spot between agent capabilities and context size.

Common Setup Mistakes

A rundown of the typical mistakes people make when wiring up MCP in OpenCode — and how to avoid them.

Wrong server type. You set type: "local" for a cloud service or vice versa. If a server publishes an HTTP URL it is remote; if it is launched by a command, it is local.
Keys leaking into config. Do not hard-code API keys. Use {env:VARIABLE_NAME} and environment variables.
Everything enabled at once. The result is a blown context window and a higher bill. Use per-agent setup.
Skipping OAuth. After adding a remote OAuth server, do not forget opencode mcp auth <name>.
Expecting magic from outdated servers. Mem0, for instance, no longer self-hosts — the project is archived, use the cloud.
Ignoring timeouts. The timeout field (default 5000 ms) bounds tool-loading wait. Raise it for slow servers.
Running browser MCPs in production sessions without limits. Always configure allowed-origins, headless mode and test accounts.

How to Pick Your Server Set

Your ideal set depends on the kind of work you do. A few typical profiles:

The universal web-dev minimum: Context7 + Playwright + Chrome DevTools + GitHub MCP + Sentry. Docs, browser, code and monitoring in one place.
The research profile: Context7 + Grep.app + Firecrawl + Playwright. For studying other projects, hunting examples and deep crawling.
The infrastructure profile: Cloudflare MCP + GitHub MCP + Vercel MCP + Sentry. For people who deploy and run production.
Backend/data: Supabase MCP + GitHub MCP + Context7. For database and platform work.
The minimal start for beginners: Context7 + Playwright. Two servers that give the most value for the least setup effort.

Remember: MCP is an extensible system, and the best set is the one that solves your actual problems, not a "trendy list". Start small, experiment, and watch your context spend.

MCP vs ACP: Two Protocols

People sometimes mix up MCP and ACP (Agent Client Protocol). They are different protocols solving different problems.

MCP is how external tools connect to OpenCode. The MCP client (OpenCode) gains access to tools provided by MCP servers.

ACP is how external editors and IDEs connect to OpenCode as an AI agent. OpenCode's docs define it: "OpenCode supports the Agent Client Protocol (ACP) so you can use it directly in compatible editors and IDEs" (https://opencode.ai/docs/acp/). The editor runs opencode acp, and OpenCode works as an ACP-compatible subprocess speaking JSON-RPC over stdio.

The key point: everything OpenCode supports — including the MCP servers in your config — works over ACP too. Think of them as two perpendicular axes of integration:

MCP is inbound tooling: how OpenCode reaches external services.
ACP is outbound availability: how external editors reach OpenCode.

When you plan your stack, do not confuse them: MCP servers plug into OpenCode's config no matter whether you work through the terminal, the web UI, or an ACP-compatible editor.

Quick-Start Checklist

A short step-by-step plan to get a working MCP stack up in one evening.

Step 1. Install OpenCode and confirm the basics work (file reads, bash, websearch). Check your model provider.
Step 2. Connect Context7 with the official config from this article and run a test prompt like "use context7 — check the current OpenAI SDK API".
Step 3. Add Playwright MCP (or Chrome DevTools MCP), open a test site and verify the agent can read the page and take a screenshot.
Step 4. Connect Grep.app or GitHub MCP and try searching for a code example in public repos.
Step 5. Set up per-agent control: disable the heavy servers globally and enable them only in the agents that need them via the agent section.
Step 6. For cloud servers (Sentry, Cloudflare, Supabase, Vercel), run opencode mcp auth <name> and confirm the tokens were saved.
Step 7. Make sure no secrets live in the config: every key should come through environment variables ({env:NAME}).
Step 8. Estimate your context spend: run a session with servers on, look at how much tool descriptions occupy, and trim or prune as needed.

After that you have a working stack you can grow project by project.

Summary

To wrap up.

In 2026 MCP is the standard way to plug tools into AI agents, and OpenCode supports it fully: local servers over subprocess, remote HTTP servers with automatic OAuth. The best connections for most developers remain:

Context7 — up-to-date docs instead of the model's stale knowledge (official OpenCode example);
Playwright MCP — cross-browser automation from Microsoft;
Chrome DevTools MCP — deep Chrome diagnostics: performance, memory, Lighthouse, network;
GitHub MCP — all of GitHub in the agent's hands, with mandatory toolsets tuning because of the server's weight;
Grep.app — real code examples across all of GitHub (official OpenCode example);
Firecrawl — deep scraping, crawling and extraction;
Sentry MCP — errors and stack traces from production (official OpenCode example);
Memory / Sequential Thinking — reference servers for memory and reasoning;
Cloudflare, Supabase, Vercel MCP — official vendor integrations for infrastructure work.

The main practical takeaways:

Do not connect every server at once — each costs context tokens.
Use per-agent setup and toolsets for the heavy servers.
Configure OAuth properly and keep secrets in environment variables.
Treat browser servers with caution: they are not a security boundary.
Watch the ecosystem: projects move and get archived (Mem0 is the latest example).

Happy building with OpenCode!

Links

×

← В главную