{"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 pull in the right context at the right moment.\n\nThe **Model Context Protocol (MCP)** standardizes how an AI application connects to those external systems.\n\nThe language model does not usually speak MCP directly. The application around the model does. That application, called the host, runs one or more MCP clients, connects them to MCP servers, translates server capabilities into the model provider's tool format, and decides when 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, each AI product had to build its own integration layer. A coding assistant needed a GitHub wrapper, a filesystem wrapper, a database wrapper, a 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\nThat creates an N x M integration problem: N AI applications multiplied by M external systems.\n\nMCP changes the shape of the work. A team can expose a 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 integration.\n\nCompatibility is not automatic. Clients still differ in transport support, authentication support, approval UX, and feature coverage. But MCP 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 can mean nine custom integrations. With MCP, the work becomes closer to three client implementations and three server implementations. At ten apps and twenty systems, that is the difference between 200 custom adapters and about 30 protocol-facing 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 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. They are easy to mix up at first, so keep the boundary clear.\n\n\n\n\n\n\n```mermaid\nflowchart LR\n subgraph Host[\"HOST (e.g., Claude Desktop)\"]\n LLM[\"Model\"]:::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, model calls, user interface, and safety policy. The host is responsible for:\n\n- Managing user conversations and the overall application lifecycle\n- Enforcing security policies, such as which servers to connect to and 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 intentionally narrow:\n\n- Establishing the connection to a server, usually over stdio or Streamable HTTP\n- Discovering capabilities by 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 one-client-per-server pattern 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 exposes the external capability. 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 usually 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 the 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 Model\n participant Client as MCP Client\n participant Server as MCP Server\n\n User->>Host: \"What's in my project README?\"\n Host->>Model: User message + available tool descriptions\n Model->>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->>Model: User message + tool result\n Model->>Host: \"Your README contains...\"\n Host->>User: Display response\n```\n\n\nThis is the normal 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 one has a different purpose. If you model every capability as a tool, you often end up with a server that is harder to secure and harder for the model to use well.\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 are data the 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\nResources are meant to be **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 include in 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 can describe the capability; the host enforces the product policy.\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(\n title: str,\n body: str,\n labels: list[str] | None = None,\n) -> 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(\n title=title,\n body=body,\n labels=labels or [],\n )\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 a useful diagnostic sequence.\n\nPrompts are usually **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 a model 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. JSON-RPC is a lightweight format for requests, responses, and one-way notifications. The transport does not change the message format; it only changes how those messages travel between client and server.\n\nThe MCP specification defines two standard transports: stdio and Streamable HTTP. The JSON-RPC messages are the same in both.\n\n### stdio: Local Communication\n\nWith stdio transport, the MCP server runs as a child process of the host application. The client starts 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 OAuth-based authorization patterns.\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; start a local 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** | Tied to the host process | Server runs 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\nimport os\nfrom mcp.server.fastmcp import FastMCP\n\nmcp = FastMCP(\n \"my-server\",\n host=\"0.0.0.0\",\n port=int(os.environ.get(\"MCP_PORT\", 8080)),\n)\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 transport = os.environ.get(\"MCP_TRANSPORT\", \"stdio\")\n if transport == \"http\":\n mcp.run(transport=\"streamable-http\")\n else:\n mcp.run()\n```\n\n\n---\n\n# MCP in the Current Ecosystem\n\nMCP is both a specification and an ecosystem of SDKs, clients, servers, registries, and hosted gateway products. The ecosystem moves 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. Exact support varies by version, transport, and configuration:\n\n\n| Client | Type | Notes |\n|--------|------|-------|\n| **Claude Desktop** | Desktop app | MCP support for desktop workflows |\n| **Claude Code** | CLI agent | MCP client support with 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 is evolving across coding workflows |\n| **Continue** | Extension | Open-source coding assistant with MCP support |\n| **Custom apps** | Any | Build your own with the MCP Python/TypeScript SDK |\n\n\nWhen you build an MCP server well, you can often reuse it across multiple 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 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 point: 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 production 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 often 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. Without another integration layer, those tool definitions live inside your application.\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 model 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[\"Model\"]:::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[\"Model\"]:::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 define tool descriptions in the app | Client discovers tools dynamically from servers |\n| **Standardization** | Each app defines its own format | Shared protocol between compatible clients and servers |\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 probably does not need MCP.\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 because they are shared and standardized. Others are inline function definitions because they are app-specific and lightweight. The two approaches coexist.\n\n---\n\n# Quiz","pageType":"ai-engineering"}

Get Premium