{"title":"What is MCP?","description":"","content":"Most useful AI applications eventually need more than a model call. They need to read files, query databases, inspect logs, call internal APIs, create tickets, update code, or retrieve domain-specific context at the right point in a conversation.\n\nThe **Model Context Protocol (MCP)** standardizes how an AI application connects to those external capabilities.\n\nStrictly speaking, the language model does not speak MCP directly. The host application does. The host runs one or more MCP clients, connects those clients to MCP servers, converts server capabilities into whatever the model API expects, and decides when user approval or policy checks are required.\n\nThat distinction matters. MCP is not a reasoning framework, an agent runtime, or a replacement for function calling. It is an integration protocol for exposing tools, resources, and prompts to AI applications in a consistent way.\n\n---\n\n# Why MCP Exists\n\nBefore MCP, every serious AI product had to build its own tool integration layer. A coding assistant needed one GitHub wrapper, one filesystem wrapper, one database wrapper, one Slack wrapper, and so on. Another assistant needed its own versions of the same integrations. The tool code, schema format, authentication path, approval flow, and error handling were all application-specific.\n\nThe engineering problem is an N x M integration problem: N AI applications multiplied by M external systems.\n\nMCP changes the shape of that problem. A tool team can expose its capability once as an MCP server. An AI application can implement MCP client support once, then connect to compatible servers without writing a custom adapter for each one. Compatibility is not guaranteed; clients still differ in transport support, authentication support, approval UX, and feature coverage. But the protocol gives both sides a shared contract.\n\n\n```mermaid\nflowchart LR\n subgraph Before[\"BEFORE: N x M Custom Integrations\"]\n A1[AI App 1]:::primary --> T1[GitHub Wrapper v1]:::red\n A1 --> T2[Slack Wrapper v1]:::red\n A1 --> T3[DB Wrapper v1]:::red\n A2[AI App 2]:::primary --> T4[GitHub Wrapper v2]:::red\n A2 --> T5[Slack Wrapper v2]:::red\n A2 --> T6[DB Wrapper v2]:::red\n A3[AI App 3]:::primary --> T7[GitHub Wrapper v3]:::red\n A3 --> T8[Slack Wrapper v3]:::red\n A3 --> T9[DB Wrapper v3]:::red\n end\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\n\n```mermaid\nflowchart TD\n subgraph After[\"AFTER: N + M with MCP\"]\n B1[AI App 1]:::primary --> MCP[\"MCP Standard\"]:::orange\n B2[AI App 2]:::primary --> MCP\n B3[AI App 3]:::primary --> MCP\n MCP --> S1[GitHub Server]:::green\n MCP --> S2[Slack Server]:::green\n MCP --> S3[DB Server]:::green\n end\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThree apps connecting to three systems without MCP require nine custom integrations. With MCP, you need three client implementations and three server implementations. At ten apps and twenty systems, that is the difference between 200 custom adapters and 30 protocol implementations.\n\nMCP was introduced by Anthropic in late 2024 and is now an open protocol maintained through the Model Context Protocol project. It is not tied to Claude or to any specific model provider. The current specification is versioned, and production systems should treat the spec version as part of their compatibility surface.\n\n---\n\n# MCP Architecture\n\nMCP defines three roles: host, client, and server. These three roles are easy to conflate, so keep the boundary between them clear.\n\n\n```mermaid\nflowchart LR\n subgraph Host[\"HOST (e.g., Claude Desktop)\"]\n LLM[\"LLM\"]:::primary\n C1[\"MCP Client 1\"]:::orange\n C2[\"MCP Client 2\"]:::orange\n LLM --- C1\n LLM --- C2\n end\n\n C1 --> S1[\"MCP Server A
File System\"]:::green\n C2 --> S2[\"MCP Server B
GitHub\"]:::green\n C2 --> S3[\"MCP Server C
Database\"]:::teal\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\n### Host\n\nThe host is the AI application the user interacts with: a desktop assistant, an IDE extension, a CLI agent, or your own product. It owns the conversation, the model calls, the user interface, and the safety policy. The host is responsible for:\n\n- Managing user conversations and the overall application lifecycle\n- Enforcing security policies (which servers to connect to, which tools to allow)\n- Translating model tool requests into MCP calls\n- Routing those calls to the correct MCP client\n- Presenting results back to the user\n\nA single host usually manages multiple MCP clients. For example, a coding assistant might maintain separate clients for filesystem access, GitHub, package documentation, and a database schema server.\n\n### Client\n\nThe client is the protocol handler inside the host. In the standard architecture, one client manages one connection to one MCP server. Its job is deliberately narrow:\n\n- Establishing the connection to a server (via stdio or HTTP)\n- Performing capability discovery (asking the server what tools, resources, and prompts it offers)\n- Sending requests when the host decides to use a server capability\n- Receiving responses and passing them back to the host\n\nThe 1:1 relationship keeps failures and permissions easier to reason about. If one server crashes or becomes unresponsive, the host can degrade that connection without tearing down every other integration.\n\n### Server\n\nThe server is where the external capability is exposed. It may wrap a local command, a SaaS API, a database, a document store, an internal service, or a workflow. Servers expose capabilities through MCP primitives:\n\n- A file system server that reads, writes, and searches local files\n- A GitHub server that lists repos, reads code, and creates pull requests\n- A PostgreSQL server that executes queries and exposes schema information\n- A Slack server that sends messages and reads channels\n\nServers can run locally as subprocesses of the host, or remotely behind an HTTP endpoint. Good servers tend to have a clear domain boundary: one server for GitHub, one for database metadata, one for incident-management operations. A server that exposes every internal system through one huge tool surface is harder to secure, test, and explain to a model.\n\n### How a Request Flows\n\nWhen a user asks a question that requires external data, here is the full sequence:\n\n\n```mermaid\nsequenceDiagram\n participant User\n participant Host\n participant LLM\n participant Client as MCP Client\n participant Server as MCP Server\n\n User->>Host: \"What's in my project README?\"\n Host->>LLM: User message + available tool descriptions\n LLM->>Host: Tool call: read_file(\"README.md\")\n Host->>Client: Route tool call to file system client\n Client->>Server: MCP request: read_file(\"README.md\")\n Server->>Server: Read file from disk\n Server->>Client: MCP response: file contents\n Client->>Host: Return tool result\n Host->>LLM: User message + tool result\n LLM->>Host: \"Your README contains...\"\n Host->>User: Display response\n```\n\n\nThis is the standard tool-calling loop, with a standardized protocol between the application and the external capability. The model may propose a tool call. The host still decides how to expose tools, whether to require approval, and how to route the request.\n\n---\n\n# The Three Primitives\n\nMCP servers expose three main server-side primitives: resources, tools, and prompts. Each has a different control model. Modeling every capability as a tool is a common way to end up with a server that is hard to secure and awkward for a model to use.\n\n\n```mermaid\nflowchart TB\n Server[\"MCP Server\"]:::primary --> R[\"Resources
(Data)\"]:::teal\n Server --> T[\"Tools
(Actions)\"]:::orange\n Server --> P[\"Prompts
(Templates)\"]:::green\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\n### Resources: Exposing Data\n\nResources represent data a client can read and provide as context. Think of them as documents with stable URIs. A filesystem server might expose files. A database server might expose schemas. An API documentation server might expose endpoint specs.\n\nResources are identified by URIs, like `file:///home/user/notes.txt` or `db://products/schema`. Clients can list available resources, read their contents, and optionally subscribe to changes (for resources that update over time).\n\nThe design intent is that resources are **read-oriented and side-effect-free**. Reading a resource should not modify business state. That makes resources safer to preload, cache, display in a picker, or inject into the model context under host control.\n\n\n**main.py**\n\n```python\nfrom mcp.server.fastmcp import FastMCP\n\nmcp = FastMCP(\"docs-server\")\n\n@mcp.resource(\"docs://api/endpoints\")\ndef get_api_docs() -> str:\n \"\"\"Return the current API endpoint documentation.\"\"\"\n return load_api_documentation()\n\n@mcp.resource(\"docs://changelog/{version}\")\ndef get_changelog(version: str) -> str:\n \"\"\"Return the changelog for a specific API version.\"\"\"\n return load_changelog(version)\n```\n\n\n### Tools: Performing Actions\n\nTools are callable operations. They might search files, execute a query, send a message, create a pull request, or run a calculation. Each tool has a name, description, and input schema.\n\nTools are **model-visible and may have side effects**. Writing a file, sending an email, or deleting a record should be modeled as a tool, not a resource. Hosts should show which tools are available and require confirmation for sensitive operations. The protocol recommends human control; the host enforces it.\n\n\n**main.py**\n\n```python\n@mcp.tool()\ndef search_codebase(query: str, file_type: str = \"\") -> str:\n \"\"\"Search the codebase for files matching a query.\n\n Args:\n query: Search term to look for in file contents.\n file_type: Optional file extension filter (e.g., '.py', '.js').\n \"\"\"\n results = perform_search(query, file_type)\n return format_results(results)\n\n@mcp.tool()\ndef create_github_issue(title: str, body: str, labels: list[str] = []) -> str:\n \"\"\"Create a new issue in the GitHub repository.\n\n Args:\n title: Issue title.\n body: Issue description in markdown.\n labels: Optional list of labels to apply.\n \"\"\"\n issue = github_client.create_issue(title=title, body=body, labels=labels)\n return f\"Created issue #{issue.number}: {issue.html_url}\"\n```\n\n\n### Prompts: Reusable Templates\n\nPrompts are reusable prompt templates that a server offers to clients. A code review server might provide a \"review this pull request\" prompt. A database server might provide an \"optimize this query\" prompt with the right diagnostic sequence.\n\nPrompts are normally **user-controlled**. They are often exposed as slash commands, menu items, or workflow templates. They shape how the model approaches a task; they do not execute work by themselves.\n\n\n**main.py**\n\n```python\n@mcp.prompt()\ndef code_review(language: str, code: str) -> str:\n \"\"\"Guide the AI through a structured code review.\n\n Args:\n language: Programming language of the code.\n code: The code to review.\n \"\"\"\n return f\"\"\"Review the following {language} code. Analyze it for:\n1. Correctness: Are there any bugs or logic errors?\n2. Performance: Are there any obvious inefficiencies?\n3. Readability: Is the code clear and well-structured?\n4. Security: Are there any security vulnerabilities?\n\nCode to review:\n{code}\nProvide specific, actionable feedback for each category.\"\"\"\n```\n\n\n### Comparing the Primitives\n\n\n| Primitive | Purpose | Who controls it | Side effects | Example |\n|-----------|---------|----------------|--------------|---------|\n| **Resources** | Expose data for reading | Application (client decides when) | None | File contents, DB schemas, API docs |\n| **Tools** | Perform actions and computations | Model-visible, host-approved | Yes, may modify state | File search, DB query, API calls |\n| **Prompts** | Provide interaction templates | User (user selects from menu) | None | Code review guide, debug workflow |\n\n\nIn practice, many servers start with tools because tool calls are easy to wire into an LLM loop. Mature servers usually add resources for stable context and prompts for common workflows.\n\n---\n\n# Transport Mechanisms\n\nEvery MCP message is a JSON-RPC 2.0 message: a lightweight format that pairs each request with a matching response, plus one-way notifications. The transport does not change the message format; it only changes how those messages travel between client and server.\n\nThe current MCP specification defines two standard transports: stdio and Streamable HTTP. The JSON-RPC messages are the same in both; the transport changes how those messages move between client and server.\n\n### stdio: Local Communication\n\nWith stdio transport, the MCP server runs as a child process of the host application. The client spawns the server process and communicates with it by writing JSON-RPC messages to the server's standard input and reading responses from its standard output.\n\n\n```mermaid\nflowchart LR\n Host[\"Host Application\"]:::primary --> |\"stdin/stdout
(JSON-RPC)\"| Server[\"MCP Server
(subprocess)\"]:::green\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThis is the simplest transport. There is no port to expose and no remote authentication flow to configure. The server starts when the host starts and stops when the host stops. It is a good fit for local tools: filesystem access, local database queries, CLI utilities, and developer-machine workflows.\n\nThe downside is that stdio servers are tied to a single host process. You cannot share a stdio server across multiple users or applications. If the host restarts, the server restarts too, losing any in-memory state.\n\n### Streamable HTTP: Remote Communication\n\nWith Streamable HTTP, the server runs as an independent HTTP service. The server exposes a single MCP endpoint that accepts POST requests for JSON-RPC messages. It can also use GET and Server-Sent Events (SSE) for server-to-client streaming, progress updates, and notifications.\n\n\n```mermaid\nflowchart LR\n Host[\"Host Application\"]:::primary --> |\"HTTP POST
+ SSE\"| Server[\"MCP Server
(web service)\"]:::orange\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nStreamable HTTP enables several patterns that stdio cannot support:\n\n- **Remote servers**: The server runs on a different machine, in the cloud, or behind a corporate firewall.\n- **Shared servers**: Multiple hosts and users connect to the same server instance.\n- **Persistent state**: The server keeps running even when clients disconnect.\n- **Authorization**: HTTP deployments can protect the endpoint with bearer tokens and the OAuth 2.1-based authorization flow defined by the MCP specification.\n\nThe trade-off is operational complexity. You need a URL, TLS, origin validation, authorization, session handling, timeouts, and observability. For many local tools, that overhead is unnecessary.\n\n### Choosing a Transport\n\n\n| Factor | stdio | Streamable HTTP |\n|--------|-------|----------------|\n| **Setup complexity** | Minimal, just spawn a process | Requires URL, auth, network config |\n| **Best for** | Local tools, single-user, development | Remote services, shared access, production |\n| **Latency** | Very low (IPC) | Network dependent |\n| **Sharing** | One host only | Multiple hosts and users |\n| **State persistence** | Lost on restart | Server persists independently |\n| **Security model** | OS process isolation, local permissions | TLS, origin checks, bearer tokens/OAuth, network policy |\n\n\nA common pattern is to develop a server locally over stdio, then expose the same capability over Streamable HTTP when it needs to be shared. The tool and resource definitions often stay the same, but production deployment adds authentication, authorization, logging, rate limiting, and health checks.\n\n\n**main.py**\n\n```python\nfrom mcp.server.fastmcp import FastMCP\n\nmcp = FastMCP(\"my-server\")\n\n# Same server code works with either transport.\n# The transport is configured at startup, not in the server logic.\n\nif __name__ == \"__main__\":\n # For local development (stdio):\n mcp.run()\n\n # For production (HTTP), you would instead run:\n # mcp.run(transport=\"streamable-http\", host=\"0.0.0.0\", port=8080)\n```\n\n\n---\n\n# MCP in the Current Ecosystem\n\nMCP is now both a specification and an ecosystem of SDKs, clients, servers, registries, and hosted gateway products. The ecosystem is moving quickly, so treat compatibility as something to verify, not assume.\n\n### Existing MCP Clients\n\nSeveral AI applications support MCP as clients or hosts:\n\n\n| Client | Type | Notes |\n|--------|------|-------|\n| **Claude Desktop** | Desktop app | Full MCP support, stdio and HTTP |\n| **Claude Code** | CLI agent | Built-in MCP client with tool approval flows |\n| **Cursor** | Code editor | MCP integration for coding workflows |\n| **Windsurf** | Code editor | MCP support for AI-assisted development |\n| **VS Code / GitHub Copilot** | Editor and extension | MCP support for coding workflows |\n| **Continue** | Extension | Open-source coding assistant with MCP |\n| **Custom apps** | Any | Build your own with the MCP Python/TypeScript SDK |\n\n\nWhen you build an MCP server well, you can reuse it across these hosts. In practice, you still test against the clients your users care about. Some clients support only stdio, some support remote servers, some have different approval UX, and authenticated remote MCP is still an area where implementations vary.\n\n### Existing MCP Servers\n\nThe ecosystem includes many official, vendor, and community servers covering common integration points:\n\n- **File system**: Read, write, and search local files\n- **GitHub/GitLab**: Repository management, PRs, issues, code search\n- **Databases**: PostgreSQL, MySQL, SQLite, MongoDB query execution\n- **Cloud providers**: AWS, GCP, Azure resource management\n- **Communication**: Slack, Discord, email\n- **Monitoring**: Datadog, Sentry, PagerDuty\n- **Documentation**: Confluence, Notion, Google Docs\n- **Search**: Brave Search, Google Search, Exa\n\n### MCP Registries\n\nAs the number of servers grows, discovery and governance become their own problems. Registries and private catalogs help teams publish approved servers, document configuration, track ownership, and prevent users from installing arbitrary code from search results.\n\nA registry is not only a marketplace. In an enterprise setting it is often a control plane: which servers are approved, who owns them, which scopes they require, what data they can access, and which clients are allowed to connect.\n\n\n```mermaid\nflowchart TD\n Dev[\"Server Developer\"]:::primary --> |\"Publish\"| Reg[\"MCP Registry\"]:::orange\n Client[\"AI Application\"]:::primary --> |\"Discover\"| Reg\n Reg --> |\"Server metadata
+ config\"| Client\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nThis is still an active area of the ecosystem. For serious deployments, prefer curated internal registries or allowlists over open-ended dynamic installation.\n\n---\n\n# MCP vs. Function Calling\n\nFunction calling and MCP can look like competing answers to the same problem. They are not. They sit at different layers of the stack and work together.\n\n### Function Calling: The Mechanism\n\nFunction calling is a model API mechanism. You provide tool descriptions to the model, the model returns a structured request to call one of them, and your application executes the call. The tool definitions live inside your application unless you build another integration layer.\n\n### MCP: The Protocol\n\nMCP is the protocol by which tools, resources, and prompts are discovered, described, and accessed across application boundaries. It standardizes how a host connects to a capability provider.\n\nThe common integration pattern is: discover MCP tools, convert their schemas into the model provider's tool format, send them to the model, then dispatch the model's tool request back through MCP. The LLM does not need to know MCP exists. The host handles translation and policy.\n\n\n```mermaid\nflowchart LR\n subgraph MCPP[\"Function Calling (with MCP)\"]\n\t\tdirection LR\n LLM2[\"LLM\"]:::primary --> |\"Tool call\"| App2[\"Your App
+ MCP Client\"]:::orange\n App2 --> |\"MCP protocol\"| Server[\"MCP Server\"]:::green\n Server --> |\"Execute\"| Tool2[\"Tool Implementation\"]:::teal\n end\n\n subgraph FC[\"Function Calling (without MCP)\"]\n\t\tdirection LR\n LLM1[\"LLM\"]:::primary --> |\"Tool call\"| App1[\"Your App\"]:::orange\n App1 --> |\"Execute\"| Tool1[\"Your Custom Tool Code\"]:::red\n end\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\n### What MCP Adds Beyond Function Calling\n\n\n| Capability | Function Calling Alone | Function Calling + MCP |\n|-----------|----------------------|----------------------|\n| **Tool discovery** | You hardcode tool descriptions | Client discovers tools dynamically from servers |\n| **Standardization** | Each app defines its own format | Universal protocol, any client talks to any server |\n| **Reusability** | Tools are embedded in your app | Servers are shared across apps and teams |\n| **Ecosystem** | You build or import each adapter yourself | Reuse compatible servers from vendors, teams, or the community |\n| **Versioning** | Manual, per-integration | Protocol-level capability negotiation |\n| **Separation of concerns** | App code and tool code are intertwined | Tool logic lives in standalone servers |\n\n\n### When to Use Which\n\n**Use plain function calling** when you have a small number of tools tightly coupled to your application. A chatbot with three custom tools that will never be reused elsewhere does not need MCP overhead.\n\n**Use MCP** when tools should be reusable across applications, when another team owns the integration, when you want to connect to existing servers, or when discovery and capability negotiation matter. MCP becomes more valuable as the number of applications and tool providers grows.\n\nIn many production systems, you will use both. Some tools are MCP servers (shared, standardized), and some are inline function definitions (app-specific, lightweight). The two approaches coexist.\n\n---\n\n# Quiz","pageType":"ai-engineering"}

What is MCP?

Get Premium