MCP: A Standardized, Two-Way Protocol

MCP is purpose-built for exactly the gap both traditional APIs and function calling leave open: APIs are general-purpose interfaces with fixed contracts, and function calling ties tools tightly to one specific application — MCP instead offers a standardized protocol for integrating LLMs with external tools and data sources, decoupling tool implementation from consumption entirely, which enables more modular and scalable AI systems.

MCP's design directly solves the parameter-change problem the traditional-API subtopic walked through. When an MCP client (say, an AI application) connects to an MCP server (say, a weather service), it sends an initial request specifically to learn the server's current capabilities. The server responds with details about its available tools, resources, prompts, and parameters — dynamically, at connection time, rather than the client needing these hardcoded in advance. If the weather server later adds a new required unit parameter, the MCP server can dynamically update its capability description during the next exchange — the client doesn't need to hardcode or predefine the parameters ahead of time, it simply queries the server's current capabilities and adapts accordingly, adjusting its behavior on the fly without needing to rewrite or redeploy any code.

This is also what distinguishes MCP from simple function calling, beyond just the dynamic-capability-discovery piece: MCP creates a genuinely two-way communication channel between AI apps and servers, not just a one-way 'call this function, get a result' interaction. This shows up concretely in MCP's primitives — Tools, Resources, and Prompts on the server side (model-controlled, app-controlled, and user-controlled respectively), plus Sampling, Roots, and Elicitation on the client side, which let a server actually request things FROM the client (asking the client's LLM to generate a completion, or asking the user for mid-task input) — something a traditional one-directional function call simply can't do.

The practical upshot: MCP aims to standardize how AI agents interact with tools (where traditional APIs vary greatly in implementation), is specifically designed to manage dynamic, evolving context including data resources, executable tools, and workflow prompts, and is particularly well suited for AI agents that need to adapt to new capabilities and tools without pre-programming — precisely the M×N and tight-coupling problems function calling struggles with at scale.

# Illustrating MCP's dynamic capability discovery — the client
# queries the server's CURRENT capabilities rather than needing
# them hardcoded, unlike traditional API/function-calling integration.
from mcp import ClientSession
from mcp.client.stdio import stdio_client

async def discover_and_use_mcp_server(server_params) -> None:
    async with stdio_client(server_params) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()

            # Dynamic discovery — no hardcoded assumptions about
            # what this server offers or what parameters it expects
            tools = await session.list_tools()
            for tool in tools.tools:
                print(f"Discovered tool: {tool.name} — {tool.description}")
                print(f"  Current parameters: {tool.inputSchema}")

            # If the server adds a new parameter later, the NEXT call to
            # list_tools() reflects it automatically — no client code
            # changes needed, unlike the hardcoded API/function-calling case
            result = await session.call_tool("get_weather", {"city": "Tokyo"})
            print(result)