MCP frequently asked questions

MCP (Model Context Protocol) is an open standard that lets AI applications — Claude, ChatGPT, Cursor, VS Code — connect to outside tools and data through one common interface. You write a small program called an MCP server that exposes tools ("search my database", "create an issue"), and any MCP client can discover and call them. Build the connector once, plug it into every AI app you use. The full plain-English explainer →

Function calling wires tools into one app against one provider’s API — you own the schemas, the dispatch loop, and all the plumbing. MCP standardizes that plumbing so the same server works unchanged in Claude Desktop, Claude Code, Cursor, VS Code, and ChatGPT. If you are building one tool inside one app you control, plain function calling is simpler; the moment you want reuse across clients or teams, MCP wins. The full comparison with a verdict →

Python or TypeScript — they are Tier 1 official SDKs with the most documentation, examples, and client support, alongside C# and Go. In practice, pick the language of the systems you are wrapping: your server spends its life talking to your database or API, not to the protocol. Python with FastMCP decorators is the gentlest start; TypeScript is convenient when you want npx-based distribution. Build your first server in Python →

stdio is the right default for local, personal tools: the client launches your server as a subprocess, no network setup, secrets stay on your machine. Streamable HTTP is for servers that run as an independent service — shared by a team, hosted remotely, or protected by OAuth. Start with stdio; switch transports when you deploy, not before. The transport decision in full →

Yes — the old HTTP+SSE transport from the 2024-11-05 protocol was replaced by Streamable HTTP in spec 2025-03-26. The confusing part: Streamable HTTP can still stream responses using SSE internally; what is deprecated is the separate /sse endpoint transport. Clients keep legacy flags (like Claude Code’s --transport sse) for old servers, but do not build anything new on it. Including the SSE migration path →

For stdio servers, each client simply launches its own instance from its own config — claude_desktop_config.json for Claude Desktop, .mcp.json or claude mcp add for Claude Code, .cursor/mcp.json for Cursor. Same command, different config file; there is nothing to share. If you genuinely need one running instance serving many clients or users, deploy it as a remote Streamable HTTP server and point each client at the URL. Copy-paste config blocks per client →

The usual suspects, in order: a relative path in the config (always use absolute paths), a JSON syntax error, spawn npx ENOENT on Windows (use the full path or cmd /c npx), or your server printing to stdout — which corrupts the JSON-RPC stream on stdio, so log to stderr only. Fully restart the client after any config change. Before blaming the client, open the server in MCP Inspector: if tools appear there, the problem is the config; if not, it is the server. The systematic debugging workflow →

For local stdio servers, put keys in the env block of the client config instead of hardcoding them — and Claude Code’s .mcp.json expands ${VAR} from your environment, so the file can be committed without secrets. For remote servers, do not ship long-lived keys at all: use OAuth 2.1, where your server validates tokens issued by an authorization server. Either way, never return a raw secret from a tool — anything a tool returns goes straight into the model’s context. Add OAuth to your server →

It is not Claude-only. ChatGPT supports MCP through connectors (remote servers with OAuth 2.1; developer mode unlocks full tool access), and Gemini CLI, VS Code Copilot, Cursor, Windsurf, Zed, and Cline all speak it — Windows 11 even ships OS-level MCP support. Anthropic started the protocol, but one server working across every major client is precisely the point. Per-client setup guides →

The protocol’s security model is real and maturing — OAuth 2.1 with the MCP server as a resource server, RFC 8707 resource indicators, per-client consent — but most risk lives in the servers you choose to run. The spec’s own security docs name the attacks: tool poisoning, confused deputy, token passthrough, session hijacking. Treat third-party servers like any dependency — review the code, pin versions, scope credentials — and for org-wide rollout, the Enterprise-Managed Authorization extension (stable July 2026) puts your IdP in control. The working threat model →

Every tool definition is injected into the model’s context before the conversation starts — one measured 106-tool server consumed roughly 54K tokens at initialization — and big tool menus also degrade the model’s tool selection. Aim for single-digit to low-double-digit tools per server, shaped around tasks ("search_orders") rather than mirroring every API endpoint. If the surface is genuinely large, split it into several servers users enable per job. Measure and cut token overhead →

Yes. The "MCP is dead" discourse recycles real engineering critiques — token overhead, early security incidents, "just write code" takes — but none of them is an obituary, and each has a concrete fix you can learn. Meanwhile the protocol is governed by the Agentic AI Foundation under the Linux Foundation (donated December 2025, with Anthropic, OpenAI, Block, Google, Microsoft, and AWS at the table) and every major AI client ships support. Standards with that footprint do not die; they get boring — which is exactly when learning one pays off. Pick your starting point →