{ "@context": "https://schema.org", "@id": "https://aggr.aymericbeaumet.com/items/philschmid-de/2025-04-03-model-context-protocol-mcp-an-overview/#webpage", "@type": [ "WebPage", "ArchiveComponent" ], "articleBody": "The [Model Context Protocol](https://modelcontextprotocol.io/introduction) (MCP) is an open standard [introduced by Anthropic](https://www.anthropic.com/news/model-context-protocol) with the goal to standardize how AI applications (chatbots, IDE assistants, or custom agents) connect with external tools, data sources, and systems.\n\n![api](https://www.philschmid.de/static/blog/mcp-introduction/api.png)\n\nThink of it like USB for AI integrations. Before standards like USB, connecting peripherals required a mess of different ports and custom drivers. Similarly, integrating AI applications with external tools and systems is/was an \"M×N problem\".\\\n If you have M different AI applications (Chat, RAG 1, custom agents, etc.) and N different tools/systems (GitHub, Slack, Asana, databases, etc.), you might need to build M×N different integrations. This leads to duplicated effort across teams, inconsistent implementations.\n\nMCP aims to simplify this by providing a common API and transforming this into an \"M+N problem\". Tool creators build N MCP servers (one for each system), while application developers build M MCP clients (one for each AI application). MCP defines a client-server architecture where:\n\n- **Hosts:** Applications the user interacts with (e.g., Claude Desktop, an IDE like Cursor, a custom agent).\n- **Clients:** Live within the Host application and manage the connection to one specific MCP server. Maintain a 1:1 to connection.\n- **Servers:** External programs that expose Tools, Resources and Prompts via standard API to the AI model via the client.\n\nThe current components of MCP servers include:\n\n1. **Tools (Model-controlled):** These are functions (tools) that LLMs can call to perform specific actions, e.g. weather API, basically function calling\n2. **Resources (Application-controlled):** These are data sources that LLMs can access, similar to GET endpoints in a REST API. Resources provide data without performing significant computation, no side effects. Part of the context/request\n3. **Prompts (User-controlled):** These are pre-defined templates to use tools or resources in the most optimal way. Selected before running inference\n\n![overview](https://www.philschmid.de/static/blog/mcp-introduction/overview.png)\n\n## How does MCP work?\n\nMCP operates on the client-server model described earlier. Here’s a simplified flow:\n\n![architecture](https://www.philschmid.de/static/blog/mcp-introduction/architecture.png)\n\n1. **Initialization:** When a Host application starts it creates N MCP Clients, which exchange information about capabilities and protocol versions via a handshake.\n2. **Discovery:** Clients requests what capabilities (Tools, Resources, Prompts) the server offers. The Server responds with a list and descriptions.\n3. **Context Provision:** The Host application can now make resources and prompts available to the user or parses the tools into a LLM compatible format, e.g. JSON Function calling\n4. **Invocation:** If the LLM determines it needs to use a Tool (e.g., based on the user's request like \"What are the open issues in the 'X' repo?\"), the Host directs the Client to send an invocation request to the appropriate Server.\n5. **Execution:** The Server receives the request (e.g., fetch\\_github\\_issues with repo 'X'), executes the underlying logic (calls the GitHub API), and gets the result.\n6. **Response:** The Server sends the result back to the Client.\n7. **Completion:** The Client relays the result to the Host, which incorporates it into the LLM's context, allowing the LLM to generate a final response for the user based on the fresh, external information.\n\n### MCP servers\n\nMCP Servers are the bridge/API between the MCP world and the specific functionality of an external system (an API, a database, local files, etc.). They are essentially wrappers that expose these external capabilities according to the MCP specification.\n\nServers can be built in various languages (Python, TypeScript, Java, Rust, etc.) as long as they can communicate over the supported transports. Servers communicate with clients primarily via two methods:\n\n- **stdio (Standard Input/Output):** Used when Client and Server run on the same machines. This is simple and effective for local integrations (e.g., accessing local files or running a local script).\n- **HTTP via SSE (Server-Sent Events):** The Client connects to the Server via HTTP. After an initial setup, the Server can push messages (events) to the Client over a persistent connection using the SSE standard.\n\nExample of how to build an MCP server with Python and [FastMCP](https://github.com/jlowin/fastmcp/tree/main):\n\nPython\n\n```py\nfrom fastmcp import FastMCP\n \n# Create an MCP server\nmcp = FastMCP(\"Demo\")\n \n# Add a tool, will be converted into JSON spec for function calling\n@mcp.tool()\ndef add(a: int, b: int) -> int:\n \"\"\"Add two numbers\"\"\"\n return a + b\n \n# Add a data resource, e.g. displayed on new chats\n@mcp.resource(\"greeting://{name}\")\ndef get_greeting(name: str) -> str:\n \"\"\"Get a personalized greeting\"\"\"\n return f\"Hello, {name}!\"\n \n# Specific prompt templates for better use\n@mcp.prompt()\ndef review_code(code: str) -> str:\n return f\"Please review this code:\\n\\n{code}\"\n```\n\nList of pre-build and community build MCP servers:\n\n- [https://github.com/punkpeye/awesome-mcp-servers](https://github.com/punkpeye/awesome-mcp-servers)\n- [https://github.com/modelcontextprotocol/servers](https://github.com/modelcontextprotocol/servers)\n- [https://mcp.composio.dev/](https://mcp.composio.dev/)\n\n### MCP Clients\n\nMCP Clients are part of Host applications (the IDE, chatbot, etc.) that manage the communication with a specific MCP Server.\n\n- **Role:** Handle connection management, capability discovery, request forwarding, and response handling according to the MCP spec.\n- **Examples of Hosts/Clients:**\n - UI Apps: Claude Desktop, Microsoft Copilot Studio, LibreChat, Claude Code\n - IDEs: Cursor, Windsurf, Continue, Zed, Cline\n - Custom Agents (Python/TypeScript):\n - Firebase Genkit\n - LangGraph\n - OpenAI agents sdk\n - ….\n\nExample of how to build an MCP client with Python and mcp.\n\nPython\n\n```py\nfrom mcp import ClientSession, StdioServerParameters, types\nfrom mcp.client.stdio import stdio_client\n \n# Commands for running/connecting to MCP Server\nserver_params = StdioServerParameters(\n command=\"python\", # Executable\n args=[\"example_server.py\"], # Optional command line arguments\n env=None, # Optional environment variables\n)\n \nasync with stdio_client(server_params) as (read, write):\n async with ClientSession(\n read, write, sampling_callback=handle_sampling_message\n ) as session:\n # Initialize the connection\n await session.initialize()\n \n # List available prompts\n prompts = await session.list_prompts()\n \n # Get a prompt\n prompt = await session.get_prompt(\n \"example-prompt\", arguments={\"arg1\": \"value\"}\n )\n \n # List available resources\n resources = await session.list_resources()\n \n # List available tools\n tools = await session.list_tools()\n \n # Read a resource\n content, mime_type = await session.read_resource(\"file://some/path\")\n \n # Call a tool\n result = await session.call_tool(\"tool-name\", arguments={\"arg1\": \"value\"})\n \n```\n\n## Why is there so much hype? Did MCP win?\n\nWhile Anthropic announced MCP in late 2024, its momentum significantly accelerated in early 2025. This isn't just random hype; several factors converged:\n\n- **\"AI-Native\"** while older standards like OpenAPI, GraphQL, or SOAP exist for API interaction, MCP was designed specifically for the needs of modern AI agents. MCP refines patterns seen in agent development:\n - Tools (Model-controlled): Actions the AI decides to take.\n - Resources (Application-controlled): Context provided to the AI.\n - Prompts (User-controlled): Specific user-invoked interactions.\n- **\"Open Standard\" with a Big Backer:** Any \"open standard” should have a spec, and [MCP has a VERY good spec](https://spec.modelcontextprotocol.io/specification/2024-11-05/). The spec alone defeats a lot of contenders, who do not provide such detailed specs.\n- **Built on Proven Foundations:** Instead of re-inventing everything from scratch, Anthropic adapted from Language Server Protocol (LSP), e.g. [JSON-RPC 2.0](https://www.jsonrpc.org/)\n- **Strong Initial Ecosystem & Dogfooding:** MCP didn't launch as just a spec. Anthropic \"dogfooded\" it extensively and released it with a comprehensive initial set:\n - Client: Claude Desktop.\n - Servers: Numerous reference implementations (filesystem, git, Slack, etc.).\n - Tooling: MCP Inspector for testing, great documentation\n - SDKs: Python and TypeScript libraries, now Java, Kotlin C#\n- **Network Effects:** The open nature fostered a community. Tools like Cursor and Windsurf integrated MCP. Companies like Composio provided pre-built servers for hundreds of integrations. OpenAI announced support for MCP. Developers built thousands of community MCP servers (GitHub, Slack, databases, Docker, etc.).\n\n## Practical Example with Gemini and Python uSDK\n\nPython\n\n```py\nfrom typing import List\nfrom google import genai\nfrom google.genai import types\nfrom mcp import ClientSession, StdioServerParameters\nfrom mcp.client.stdio import stdio_client\nimport os\n \nclient = genai.Client(api_key=os.getenv(\"GEMINI_API_KEY\"))\nmodel = \"gemini-2.0-flash\"\n \n# Create server parameters for stdio connection\nserver_params = StdioServerParameters(\n command=\"npx\", # Executable\n args=[\n \"-y\",\n \"@openbnb/mcp-server-airbnb\",\n ], # Optional command line arguments\n env=None, # Optional environment variables\n)\n \nasync def agent_loop(prompt: str, client: genai.Client, session: ClientSession):\n contents = [types.Content(role=\"user\", parts=[types.Part(text=prompt)])]\n # Initialize the connection\n await session.initialize()\n \n # --- 1. Get Tools from Session and convert to Gemini Tool objects ---\n mcp_tools = await session.list_tools()\n tools = types.Tool(function_declarations=[\n {\n \"name\": tool.name,\n \"description\": tool.description,\n \"parameters\": tool.inputSchema,\n }\n for tool in mcp_tools.tools\n ])\n \n # --- 2. Initial Request with user prompt and function declarations ---\n response = await client.aio.models.generate_content(\n model=model, # Or your preferred model supporting function calling\n contents=contents,\n config=types.GenerateContentConfig(\n temperature=0,\n tools=[tools],\n ), # Example other config\n )\n \n # --- 3. Append initial response to contents ---\n contents.append(response.candidates[0].content)\n \n # --- 4. Tool Calling Loop --- \n turn_count = 0\n max_tool_turns = 5\n while response.function_calls and turn_count < max_tool_turns:\n turn_count += 1\n tool_response_parts: List[types.Part] = []\n \n # --- 4.1 Process all function calls in order and return in this turn ---\n for fc_part in response.function_calls:\n tool_name = fc_part.name\n args = fc_part.args or {} # Ensure args is a dict\n print(f\"Attempting to call MCP tool: '{tool_name}' with args: {args}\")\n \n tool_response: dict\n try:\n # Call the session's tool executor\n tool_result = await session.call_tool(tool_name, args)\n print(f\"MCP tool '{tool_name}' executed successfully.\")\n if tool_result.isError:\n tool_response = {\"error\": tool_result.content[0].text}\n else:\n tool_response = {\"result\": tool_result.content[0].text}\n except Exception as e:\n tool_response = {\"error\": f\"Tool execution failed: {type(e).__name__}: {e}\"}\n \n # Prepare FunctionResponse Part\n tool_response_parts.append(\n types.Part.from_function_response(\n name=tool_name, response=tool_response\n )\n )\n \n # --- 4.2 Add the tool response(s) to history ---\n contents.append(types.Content(role=\"user\", parts=tool_response_parts))\n print(f\"Added {len(tool_response_parts)} tool response parts to history.\")\n \n # --- 4.3 Make the next call to the model with updated history ---\n print(\"Making subsequent API call with tool responses...\")\n response = await client.aio.models.generate_content(\n model=model,\n contents=contents, # Send updated history\n config=types.GenerateContentConfig(\n temperature=1.0,\n tools=[tools],\n ), # Keep sending same config\n )\n contents.append(response.candidates[0].content)\n \n if turn_count >= max_tool_turns and response.function_calls:\n print(f\"Maximum tool turns ({max_tool_turns}) reached. Exiting loop.\")\n \n print(\"MCP tool calling loop finished. Returning final response.\")\n # --- 5. Return Final Response ---\n return response\n \nasync def run():\n async with stdio_client(server_params) as (read, write):\n async with ClientSession(\n read,\n write,\n ) as session:\n # Test prompt\n prompt = \"I want to book an apartment in Paris for 2 nights. 03/28 - 03/30\"\n print(f\"Running agent loop with prompt: {prompt}\")\n # Run agent loop\n res = await agent_loop(prompt, client, session)\n return res\nres = await run()\nprint(res.text)\n```\n\n## What about Security, Updates, Authentication?\n\nMCP is a living protocol. The specification is actively maintained on GitHub, last update from 03/26 improves security, scalability, and usability.\n\n- **Authentication & Security (OAuth 2.1):** The protocol now mandates the OAuth 2.1 framework for authenticating remote HTTP servers\n- **Improved Transport & Efficiency:** The previous HTTP+SSE transport will be replaced with a more flexible Streamable HTTP transport and support for JSON-RPC batching.\n- **Richer Context & Control:** New tool annotations provide more metadata about a tool's behavior (e.g., read-only vs. destructive)\n\n## Acknowledgements\n\nThis overview was compiled with the help of deep and manual research, drawing inspiration and information from several excellent resources, including:\n\n- [What Is MCP, and Why Is Everyone – Suddenly!– Talking About It?](https://huggingface.co/blog/Kseniase/mcp)\n- [What is MCP](https://python.useinstructor.com/blog/2025/03/27/understanding-model-context-protocol-mcp/#conclusion)\n- [I gave Claude root access to my server... Model Context Protocol explained](https://www.youtube.com/watch?v=HyzlYwjoXOQ)\n- [Why MCP Won](https://www.latent.space/p/why-mcp-won)\n- [Building Agents with Model Context Protocol - Full Workshop with Mahesh Murag of Anthropic](https://www.youtube.com/watch?v=kQmXtrmQ5Zg)\n\n* * *\n\nIf you have any questions, feedback, or ideas, please dm me on [X](https://x.com/_philschmid) or [LinkedIn](https://www.linkedin.com/in/philipp-schmid-a6a2bb196/). I am excited to hear about how you are experimenting and pushing the boundaries of AI agents.\n", "authors": [], "captured_at": "2026-09-27T19:29:15.293681927+00:00", "category": "programming", "content_html": "

The Model Context Protocol (MCP) is an open standard introduced by Anthropic with the goal to standardize how AI applications (chatbots, IDE assistants, or custom agents) connect with external tools, data sources, and systems.

\n

\"api\"

\n

Think of it like USB for AI integrations. Before standards like USB, connecting peripherals required a mess of different ports and custom drivers. Similarly, integrating AI applications with external tools and systems is/was an "M×N problem".
\nIf you have M different AI applications (Chat, RAG 1, custom agents, etc.) and N different tools/systems (GitHub, Slack, Asana, databases, etc.), you might need to build M×N different integrations. This leads to duplicated effort across teams, inconsistent implementations.

\n

MCP aims to simplify this by providing a common API and transforming this into an "M+N problem". Tool creators build N MCP servers (one for each system), while application developers build M MCP clients (one for each AI application). MCP defines a client-server architecture where:

\n\n

The current components of MCP servers include:

\n
    \n
  1. Tools (Model-controlled): These are functions (tools) that LLMs can call to perform specific actions, e.g. weather API, basically function calling
    2. \n
  2. Resources (Application-controlled): These are data sources that LLMs can access, similar to GET endpoints in a REST API. Resources provide data without performing significant computation, no side effects. Part of the context/request
    3. \n
  3. Prompts (User-controlled): These are pre-defined templates to use tools or resources in the most optimal way. Selected before running inference
    4. \n
\n

\"overview\"

\n

How does MCP work?

\n

MCP operates on the client-server model described earlier. Here’s a simplified flow:

\n

\"architecture\"

\n
    \n
  1. Initialization: When a Host application starts it creates N MCP Clients, which exchange information about capabilities and protocol versions via a handshake.
    2. \n
  2. Discovery: Clients requests what capabilities (Tools, Resources, Prompts) the server offers. The Server responds with a list and descriptions.
    3. \n
  3. Context Provision: The Host application can now make resources and prompts available to the user or parses the tools into a LLM compatible format, e.g. JSON Function calling
    4. \n
  4. Invocation: If the LLM determines it needs to use a Tool (e.g., based on the user's request like "What are the open issues in the 'X' repo?"), the Host directs the Client to send an invocation request to the appropriate Server.
    5. \n
  5. Execution: The Server receives the request (e.g., fetch_github_issues with repo 'X'), executes the underlying logic (calls the GitHub API), and gets the result.
    6. \n
  6. Response: The Server sends the result back to the Client.
    7. \n
  7. Completion: The Client relays the result to the Host, which incorporates it into the LLM's context, allowing the LLM to generate a final response for the user based on the fresh, external information.
    8. \n
\n

MCP servers

\n

MCP Servers are the bridge/API between the MCP world and the specific functionality of an external system (an API, a database, local files, etc.). They are essentially wrappers that expose these external capabilities according to the MCP specification.

\n

Servers can be built in various languages (Python, TypeScript, Java, Rust, etc.) as long as they can communicate over the supported transports. Servers communicate with clients primarily via two methods:

\n\n

Example of how to build an MCP server with Python and FastMCP:

\n

Python

\n
from fastmcp import FastMCP\n \n# Create an MCP server\nmcp = FastMCP("Demo")\n \n# Add a tool, will be converted into JSON spec for function calling\n@mcp.tool()\ndef add(a: int, b: int) -> int:\n    """Add two numbers"""\n    return a + b\n \n# Add a data resource, e.g. displayed on new chats\n@mcp.resource("greeting://{name}")\ndef get_greeting(name: str) -> str:\n    """Get a personalized greeting"""\n    return f"Hello, {name}!"\n \n# Specific prompt templates for better use\n@mcp.prompt()\ndef review_code(code: str) -> str:\n    return f"Please review this code:\\n\\n{code}"\n
\n

List of pre-build and community build MCP servers:

\n\n

MCP Clients

\n

MCP Clients are part of Host applications (the IDE, chatbot, etc.) that manage the communication with a specific MCP Server.

\n\n

Example of how to build an MCP client with Python and mcp.

\n

Python

\n
from mcp import ClientSession, StdioServerParameters, types\nfrom mcp.client.stdio import stdio_client\n \n# Commands for running/connecting to MCP Server\nserver_params = StdioServerParameters(\n    command="python",  # Executable\n    args=["example_server.py"],  # Optional command line arguments\n    env=None,  # Optional environment variables\n)\n \nasync with stdio_client(server_params) as (read, write):\n    async with ClientSession(\n        read, write, sampling_callback=handle_sampling_message\n    ) as session:\n        # Initialize the connection\n        await session.initialize()\n \n        # List available prompts\n        prompts = await session.list_prompts()\n \n        # Get a prompt\n        prompt = await session.get_prompt(\n            "example-prompt", arguments={"arg1": "value"}\n        )\n \n        # List available resources\n        resources = await session.list_resources()\n \n        # List available tools\n        tools = await session.list_tools()\n \n        # Read a resource\n        content, mime_type = await session.read_resource("file://some/path")\n \n        # Call a tool\n        result = await session.call_tool("tool-name", arguments={"arg1": "value"})\n \n
\n

Why is there so much hype? Did MCP win?

\n

While Anthropic announced MCP in late 2024, its momentum significantly accelerated in early 2025. This isn't just random hype; several factors converged:

\n\n

Practical Example with Gemini and Python uSDK

\n

Python

\n
from typing import List\nfrom google import genai\nfrom google.genai import types\nfrom mcp import ClientSession, StdioServerParameters\nfrom mcp.client.stdio import stdio_client\nimport os\n \nclient = genai.Client(api_key=os.getenv("GEMINI_API_KEY"))\nmodel = "gemini-2.0-flash"\n \n# Create server parameters for stdio connection\nserver_params = StdioServerParameters(\n    command="npx",  # Executable\n    args=[\n        "-y",\n        "@openbnb/mcp-server-airbnb",\n    ],  # Optional command line arguments\n    env=None,  # Optional environment variables\n)\n \nasync def agent_loop(prompt: str, client: genai.Client, session: ClientSession):\n    contents = [types.Content(role="user", parts=[types.Part(text=prompt)])]\n    # Initialize the connection\n    await session.initialize()\n    \n    # --- 1. Get Tools from Session and convert to Gemini Tool objects ---\n    mcp_tools = await session.list_tools()\n    tools = types.Tool(function_declarations=[\n        {\n            "name": tool.name,\n            "description": tool.description,\n            "parameters": tool.inputSchema,\n        }\n        for tool in mcp_tools.tools\n    ])\n    \n    # --- 2. Initial Request with user prompt and function declarations ---\n    response = await client.aio.models.generate_content(\n        model=model,  # Or your preferred model supporting function calling\n        contents=contents,\n        config=types.GenerateContentConfig(\n            temperature=0,\n            tools=[tools],\n        ),  # Example other config\n    )\n    \n    # --- 3. Append initial response to contents ---\n    contents.append(response.candidates[0].content)\n \n    # --- 4. Tool Calling Loop ---            \n    turn_count = 0\n    max_tool_turns = 5\n    while response.function_calls and turn_count < max_tool_turns:\n        turn_count += 1\n        tool_response_parts: List[types.Part] = []\n \n        # --- 4.1 Process all function calls in order and return in this turn ---\n        for fc_part in response.function_calls:\n            tool_name = fc_part.name\n            args = fc_part.args or {}  # Ensure args is a dict\n            print(f"Attempting to call MCP tool: '{tool_name}' with args: {args}")\n \n            tool_response: dict\n            try:\n                # Call the session's tool executor\n                tool_result = await session.call_tool(tool_name, args)\n                print(f"MCP tool '{tool_name}' executed successfully.")\n                if tool_result.isError:\n                    tool_response = {"error": tool_result.content[0].text}\n                else:\n                    tool_response = {"result": tool_result.content[0].text}\n            except Exception as e:\n                tool_response = {"error":  f"Tool execution failed: {type(e).__name__}: {e}"}\n            \n            # Prepare FunctionResponse Part\n            tool_response_parts.append(\n                types.Part.from_function_response(\n                    name=tool_name, response=tool_response\n                )\n            )\n \n        # --- 4.2 Add the tool response(s) to history ---\n        contents.append(types.Content(role="user", parts=tool_response_parts))\n        print(f"Added {len(tool_response_parts)} tool response parts to history.")\n \n        # --- 4.3 Make the next call to the model with updated history ---\n        print("Making subsequent API call with tool responses...")\n        response = await client.aio.models.generate_content(\n            model=model,\n            contents=contents,  # Send updated history\n            config=types.GenerateContentConfig(\n                temperature=1.0,\n                tools=[tools],\n            ),  # Keep sending same config\n        )\n        contents.append(response.candidates[0].content)\n \n    if turn_count >= max_tool_turns and response.function_calls:\n        print(f"Maximum tool turns ({max_tool_turns}) reached. Exiting loop.")\n \n    print("MCP tool calling loop finished. Returning final response.")\n    # --- 5. Return Final Response ---\n    return response\n        \nasync def run():\n    async with stdio_client(server_params) as (read, write):\n        async with ClientSession(\n            read,\n            write,\n        ) as session:\n            # Test prompt\n            prompt = "I want to book an apartment in Paris for 2 nights. 03/28 - 03/30"\n            print(f"Running agent loop with prompt: {prompt}")\n            # Run agent loop\n            res = await agent_loop(prompt, client, session)\n            return res\nres = await run()\nprint(res.text)\n
\n

What about Security, Updates, Authentication?

\n

MCP is a living protocol. The specification is actively maintained on GitHub, last update from 03/26 improves security, scalability, and usability.

\n\n

Acknowledgements

\n

This overview was compiled with the help of deep and manual research, drawing inspiration and information from several excellent resources, including:

\n\n
\n

If you have any questions, feedback, or ideas, please dm me on X or LinkedIn. I am excited to hear about how you are experimenting and pushing the boundaries of AI agents.

\n", "content_markdown": "The [Model Context Protocol](https://modelcontextprotocol.io/introduction) (MCP) is an open standard [introduced by Anthropic](https://www.anthropic.com/news/model-context-protocol) with the goal to standardize how AI applications (chatbots, IDE assistants, or custom agents) connect with external tools, data sources, and systems.\n\n![api](https://www.philschmid.de/static/blog/mcp-introduction/api.png)\n\nThink of it like USB for AI integrations. Before standards like USB, connecting peripherals required a mess of different ports and custom drivers. Similarly, integrating AI applications with external tools and systems is/was an \"M×N problem\".\\\n If you have M different AI applications (Chat, RAG 1, custom agents, etc.) and N different tools/systems (GitHub, Slack, Asana, databases, etc.), you might need to build M×N different integrations. This leads to duplicated effort across teams, inconsistent implementations.\n\nMCP aims to simplify this by providing a common API and transforming this into an \"M+N problem\". Tool creators build N MCP servers (one for each system), while application developers build M MCP clients (one for each AI application). MCP defines a client-server architecture where:\n\n- **Hosts:** Applications the user interacts with (e.g., Claude Desktop, an IDE like Cursor, a custom agent).\n- **Clients:** Live within the Host application and manage the connection to one specific MCP server. Maintain a 1:1 to connection.\n- **Servers:** External programs that expose Tools, Resources and Prompts via standard API to the AI model via the client.\n\nThe current components of MCP servers include:\n\n1. **Tools (Model-controlled):** These are functions (tools) that LLMs can call to perform specific actions, e.g. weather API, basically function calling\n2. **Resources (Application-controlled):** These are data sources that LLMs can access, similar to GET endpoints in a REST API. Resources provide data without performing significant computation, no side effects. Part of the context/request\n3. **Prompts (User-controlled):** These are pre-defined templates to use tools or resources in the most optimal way. Selected before running inference\n\n![overview](https://www.philschmid.de/static/blog/mcp-introduction/overview.png)\n\n## How does MCP work?\n\nMCP operates on the client-server model described earlier. Here’s a simplified flow:\n\n![architecture](https://www.philschmid.de/static/blog/mcp-introduction/architecture.png)\n\n1. **Initialization:** When a Host application starts it creates N MCP Clients, which exchange information about capabilities and protocol versions via a handshake.\n2. **Discovery:** Clients requests what capabilities (Tools, Resources, Prompts) the server offers. The Server responds with a list and descriptions.\n3. **Context Provision:** The Host application can now make resources and prompts available to the user or parses the tools into a LLM compatible format, e.g. JSON Function calling\n4. **Invocation:** If the LLM determines it needs to use a Tool (e.g., based on the user's request like \"What are the open issues in the 'X' repo?\"), the Host directs the Client to send an invocation request to the appropriate Server.\n5. **Execution:** The Server receives the request (e.g., fetch\\_github\\_issues with repo 'X'), executes the underlying logic (calls the GitHub API), and gets the result.\n6. **Response:** The Server sends the result back to the Client.\n7. **Completion:** The Client relays the result to the Host, which incorporates it into the LLM's context, allowing the LLM to generate a final response for the user based on the fresh, external information.\n\n### MCP servers\n\nMCP Servers are the bridge/API between the MCP world and the specific functionality of an external system (an API, a database, local files, etc.). They are essentially wrappers that expose these external capabilities according to the MCP specification.\n\nServers can be built in various languages (Python, TypeScript, Java, Rust, etc.) as long as they can communicate over the supported transports. Servers communicate with clients primarily via two methods:\n\n- **stdio (Standard Input/Output):** Used when Client and Server run on the same machines. This is simple and effective for local integrations (e.g., accessing local files or running a local script).\n- **HTTP via SSE (Server-Sent Events):** The Client connects to the Server via HTTP. After an initial setup, the Server can push messages (events) to the Client over a persistent connection using the SSE standard.\n\nExample of how to build an MCP server with Python and [FastMCP](https://github.com/jlowin/fastmcp/tree/main):\n\nPython\n\n```py\nfrom fastmcp import FastMCP\n \n# Create an MCP server\nmcp = FastMCP(\"Demo\")\n \n# Add a tool, will be converted into JSON spec for function calling\n@mcp.tool()\ndef add(a: int, b: int) -> int:\n \"\"\"Add two numbers\"\"\"\n return a + b\n \n# Add a data resource, e.g. displayed on new chats\n@mcp.resource(\"greeting://{name}\")\ndef get_greeting(name: str) -> str:\n \"\"\"Get a personalized greeting\"\"\"\n return f\"Hello, {name}!\"\n \n# Specific prompt templates for better use\n@mcp.prompt()\ndef review_code(code: str) -> str:\n return f\"Please review this code:\\n\\n{code}\"\n```\n\nList of pre-build and community build MCP servers:\n\n- [https://github.com/punkpeye/awesome-mcp-servers](https://github.com/punkpeye/awesome-mcp-servers)\n- [https://github.com/modelcontextprotocol/servers](https://github.com/modelcontextprotocol/servers)\n- [https://mcp.composio.dev/](https://mcp.composio.dev/)\n\n### MCP Clients\n\nMCP Clients are part of Host applications (the IDE, chatbot, etc.) that manage the communication with a specific MCP Server.\n\n- **Role:** Handle connection management, capability discovery, request forwarding, and response handling according to the MCP spec.\n- **Examples of Hosts/Clients:**\n - UI Apps: Claude Desktop, Microsoft Copilot Studio, LibreChat, Claude Code\n - IDEs: Cursor, Windsurf, Continue, Zed, Cline\n - Custom Agents (Python/TypeScript):\n - Firebase Genkit\n - LangGraph\n - OpenAI agents sdk\n - ….\n\nExample of how to build an MCP client with Python and mcp.\n\nPython\n\n```py\nfrom mcp import ClientSession, StdioServerParameters, types\nfrom mcp.client.stdio import stdio_client\n \n# Commands for running/connecting to MCP Server\nserver_params = StdioServerParameters(\n command=\"python\", # Executable\n args=[\"example_server.py\"], # Optional command line arguments\n env=None, # Optional environment variables\n)\n \nasync with stdio_client(server_params) as (read, write):\n async with ClientSession(\n read, write, sampling_callback=handle_sampling_message\n ) as session:\n # Initialize the connection\n await session.initialize()\n \n # List available prompts\n prompts = await session.list_prompts()\n \n # Get a prompt\n prompt = await session.get_prompt(\n \"example-prompt\", arguments={\"arg1\": \"value\"}\n )\n \n # List available resources\n resources = await session.list_resources()\n \n # List available tools\n tools = await session.list_tools()\n \n # Read a resource\n content, mime_type = await session.read_resource(\"file://some/path\")\n \n # Call a tool\n result = await session.call_tool(\"tool-name\", arguments={\"arg1\": \"value\"})\n \n```\n\n## Why is there so much hype? Did MCP win?\n\nWhile Anthropic announced MCP in late 2024, its momentum significantly accelerated in early 2025. This isn't just random hype; several factors converged:\n\n- **\"AI-Native\"** while older standards like OpenAPI, GraphQL, or SOAP exist for API interaction, MCP was designed specifically for the needs of modern AI agents. MCP refines patterns seen in agent development:\n - Tools (Model-controlled): Actions the AI decides to take.\n - Resources (Application-controlled): Context provided to the AI.\n - Prompts (User-controlled): Specific user-invoked interactions.\n- **\"Open Standard\" with a Big Backer:** Any \"open standard” should have a spec, and [MCP has a VERY good spec](https://spec.modelcontextprotocol.io/specification/2024-11-05/). The spec alone defeats a lot of contenders, who do not provide such detailed specs.\n- **Built on Proven Foundations:** Instead of re-inventing everything from scratch, Anthropic adapted from Language Server Protocol (LSP), e.g. [JSON-RPC 2.0](https://www.jsonrpc.org/)\n- **Strong Initial Ecosystem & Dogfooding:** MCP didn't launch as just a spec. Anthropic \"dogfooded\" it extensively and released it with a comprehensive initial set:\n - Client: Claude Desktop.\n - Servers: Numerous reference implementations (filesystem, git, Slack, etc.).\n - Tooling: MCP Inspector for testing, great documentation\n - SDKs: Python and TypeScript libraries, now Java, Kotlin C#\n- **Network Effects:** The open nature fostered a community. Tools like Cursor and Windsurf integrated MCP. Companies like Composio provided pre-built servers for hundreds of integrations. OpenAI announced support for MCP. Developers built thousands of community MCP servers (GitHub, Slack, databases, Docker, etc.).\n\n## Practical Example with Gemini and Python uSDK\n\nPython\n\n```py\nfrom typing import List\nfrom google import genai\nfrom google.genai import types\nfrom mcp import ClientSession, StdioServerParameters\nfrom mcp.client.stdio import stdio_client\nimport os\n \nclient = genai.Client(api_key=os.getenv(\"GEMINI_API_KEY\"))\nmodel = \"gemini-2.0-flash\"\n \n# Create server parameters for stdio connection\nserver_params = StdioServerParameters(\n command=\"npx\", # Executable\n args=[\n \"-y\",\n \"@openbnb/mcp-server-airbnb\",\n ], # Optional command line arguments\n env=None, # Optional environment variables\n)\n \nasync def agent_loop(prompt: str, client: genai.Client, session: ClientSession):\n contents = [types.Content(role=\"user\", parts=[types.Part(text=prompt)])]\n # Initialize the connection\n await session.initialize()\n \n # --- 1. Get Tools from Session and convert to Gemini Tool objects ---\n mcp_tools = await session.list_tools()\n tools = types.Tool(function_declarations=[\n {\n \"name\": tool.name,\n \"description\": tool.description,\n \"parameters\": tool.inputSchema,\n }\n for tool in mcp_tools.tools\n ])\n \n # --- 2. Initial Request with user prompt and function declarations ---\n response = await client.aio.models.generate_content(\n model=model, # Or your preferred model supporting function calling\n contents=contents,\n config=types.GenerateContentConfig(\n temperature=0,\n tools=[tools],\n ), # Example other config\n )\n \n # --- 3. Append initial response to contents ---\n contents.append(response.candidates[0].content)\n \n # --- 4. Tool Calling Loop --- \n turn_count = 0\n max_tool_turns = 5\n while response.function_calls and turn_count < max_tool_turns:\n turn_count += 1\n tool_response_parts: List[types.Part] = []\n \n # --- 4.1 Process all function calls in order and return in this turn ---\n for fc_part in response.function_calls:\n tool_name = fc_part.name\n args = fc_part.args or {} # Ensure args is a dict\n print(f\"Attempting to call MCP tool: '{tool_name}' with args: {args}\")\n \n tool_response: dict\n try:\n # Call the session's tool executor\n tool_result = await session.call_tool(tool_name, args)\n print(f\"MCP tool '{tool_name}' executed successfully.\")\n if tool_result.isError:\n tool_response = {\"error\": tool_result.content[0].text}\n else:\n tool_response = {\"result\": tool_result.content[0].text}\n except Exception as e:\n tool_response = {\"error\": f\"Tool execution failed: {type(e).__name__}: {e}\"}\n \n # Prepare FunctionResponse Part\n tool_response_parts.append(\n types.Part.from_function_response(\n name=tool_name, response=tool_response\n )\n )\n \n # --- 4.2 Add the tool response(s) to history ---\n contents.append(types.Content(role=\"user\", parts=tool_response_parts))\n print(f\"Added {len(tool_response_parts)} tool response parts to history.\")\n \n # --- 4.3 Make the next call to the model with updated history ---\n print(\"Making subsequent API call with tool responses...\")\n response = await client.aio.models.generate_content(\n model=model,\n contents=contents, # Send updated history\n config=types.GenerateContentConfig(\n temperature=1.0,\n tools=[tools],\n ), # Keep sending same config\n )\n contents.append(response.candidates[0].content)\n \n if turn_count >= max_tool_turns and response.function_calls:\n print(f\"Maximum tool turns ({max_tool_turns}) reached. Exiting loop.\")\n \n print(\"MCP tool calling loop finished. Returning final response.\")\n # --- 5. Return Final Response ---\n return response\n \nasync def run():\n async with stdio_client(server_params) as (read, write):\n async with ClientSession(\n read,\n write,\n ) as session:\n # Test prompt\n prompt = \"I want to book an apartment in Paris for 2 nights. 03/28 - 03/30\"\n print(f\"Running agent loop with prompt: {prompt}\")\n # Run agent loop\n res = await agent_loop(prompt, client, session)\n return res\nres = await run()\nprint(res.text)\n```\n\n## What about Security, Updates, Authentication?\n\nMCP is a living protocol. The specification is actively maintained on GitHub, last update from 03/26 improves security, scalability, and usability.\n\n- **Authentication & Security (OAuth 2.1):** The protocol now mandates the OAuth 2.1 framework for authenticating remote HTTP servers\n- **Improved Transport & Efficiency:** The previous HTTP+SSE transport will be replaced with a more flexible Streamable HTTP transport and support for JSON-RPC batching.\n- **Richer Context & Control:** New tool annotations provide more metadata about a tool's behavior (e.g., read-only vs. destructive)\n\n## Acknowledgements\n\nThis overview was compiled with the help of deep and manual research, drawing inspiration and information from several excellent resources, including:\n\n- [What Is MCP, and Why Is Everyone – Suddenly!– Talking About It?](https://huggingface.co/blog/Kseniase/mcp)\n- [What is MCP](https://python.useinstructor.com/blog/2025/03/27/understanding-model-context-protocol-mcp/#conclusion)\n- [I gave Claude root access to my server... Model Context Protocol explained](https://www.youtube.com/watch?v=HyzlYwjoXOQ)\n- [Why MCP Won](https://www.latent.space/p/why-mcp-won)\n- [Building Agents with Model Context Protocol - Full Workshop with Mahesh Murag of Anthropic](https://www.youtube.com/watch?v=kQmXtrmQ5Zg)\n\n* * *\n\nIf you have any questions, feedback, or ideas, please dm me on [X](https://x.com/_philschmid) or [LinkedIn](https://www.linkedin.com/in/philipp-schmid-a6a2bb196/). I am excited to hear about how you are experimenting and pushing the boundaries of AI agents.\n", "dateCreated": "2026-09-27T19:29:15.293681927+00:00", "date_created": "2025-04-03T00:00:00+00:00", "date_modified": "2025-04-03T00:00:00+00:00", "date_published": "2025-04-03T00:00:00+00:00", "description": "Overview of the Model Context Protocol (MCP) how it works, what are MCP servers and clients, and how to use it.", "external_url": "https://www.philschmid.de/mcp-introduction", "git": { "commit": "ebb0941c5c06a2ab2377342d607535262a3e969e", "path": "items/philschmid-de/2025/04/2025-04-03-model-context-protocol-mcp-an-overview.md", "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/ebb0941c5c06a2ab2377342d607535262a3e969e/items/philschmid-de/2025/04/2025-04-03-model-context-protocol-mcp-an-overview.md" }, "id": "urn:aggr:item:5d5acca170afcab85f00fd3dc3e7e4b4516f44fe", "isBasedOn": { "@id": "https://www.philschmid.de/mcp-introduction" }, "mainEntity": { "@id": "https://www.philschmid.de/mcp-introduction", "@type": "CreativeWork", "archivedAt": { "@id": "https://aggr.aymericbeaumet.com/items/philschmid-de/2025-04-03-model-context-protocol-mcp-an-overview/#webpage" }, "dateModified": "2025-04-03T00:00:00+00:00", "datePublished": "2025-04-03T00:00:00+00:00", "headline": "Model Context Protocol (MCP) an overview", "timeRequired": "PT8M", "url": "https://www.philschmid.de/mcp-introduction", "wordCount": 1774 }, "name": "Archived snapshot: Model Context Protocol (MCP) an overview", "preview": null, "reading_minutes": 8, "replicated_at": null, "source": "philschmid-de", "source_name": "philschmid.de - RSS feed", "summary": "Overview of the Model Context Protocol (MCP) how it works, what are MCP servers and clients, and how to use it.", "tags": [], "temporalCoverage": "2026-09-27T19:29:15.293681927+00:00", "title": "Model Context Protocol (MCP) an overview", "url": "https://aggr.aymericbeaumet.com/items/philschmid-de/2025-04-03-model-context-protocol-mcp-an-overview/", "word_count": 1774 }