Updated June 2026

MCP (Model Context Protocol) is a standard way to plug tools and data sources into LLM applications. Anthropic created it, but it stopped being a Claude thing fast: OpenAI, Google, and most agent frameworks now support it. A service exposes an MCP server; any MCP-aware client (Claude Code, Claude.ai, ChatGPT, your own agent) can connect to it and use its tools. The pitch is “write the integration once, use it everywhere,” and unlike most integration pitches, this one mostly holds.

When MCP is the right call

  • The server already exists. GitHub, Linear, Notion, and many other major tools ship official MCP servers. Connecting to one is configuration, not code.
  • You want the same capability in multiple clients. A tool you’d otherwise build twice (once for your agent, once for your editor) is a strong MCP candidate.
  • The integration is a stable, general capability. “Query our internal wiki” belongs in an MCP server. “Validate this one form in this one app” doesn’t.

When a plain custom tool beats MCP

  • App-specific logic. If only one application will ever call it, the protocol overhead buys you nothing; define the tool directly.
  • Secrets that must stay on your side. With a custom tool, your own code executes the call and the credential never leaves your infrastructure. That control is harder to reason about once a protocol layer and a remote server are involved.
  • Tight loops. Tool calls that happen hundreds of times per session deserve the lowest-friction path you can build.

Gotchas I’d want someone to tell me

  1. MCP auth tokens are not REST API keys. Hosted MCP servers typically want OAuth bearer tokens. A service’s normal API key (a Notion ntn_ token, say) authenticates against its REST API and will not work against its MCP server. Different auth systems, despite belonging to the same product.
  2. Every connected tool costs context. Tool definitions sit in the prompt on every request. Connecting five servers with twenty tools each means the model reads a hundred schemas before your question. Connect what the task needs, not everything you have.
  3. Tool descriptions are prompt surface. The model reads them and follows them. A third-party server’s tool descriptions are effectively instructions you’re injecting into your own agent, so treat connecting an unknown server with the same suspicion as running an unknown binary.
  4. Network policy bites silently. In sandboxed or egress-restricted environments, an unreachable MCP server usually fails as “the agent never uses the tool” rather than a clean error. If a tool is mysteriously ignored, check reachability before re-writing prompts.