Model Context Protocol

Model-Context-Protocol (MCP) shifts integration responsibility from the developer to the AI agent. Instead of hardcoding system integrations inside the agent, MCP servers advertise typed, discoverable functions (tools) that an agent can call at runtime. This lets agents interact with external systems in a structured, API-like way while the agent manages the integration using the protocol definitions the server exposes. Key benefits

Reduces developer maintenance: integrations live in reusable MCP servers rather than in each agent.
Safer, typed interaction: tools include parameter and return-type metadata so agents know what inputs are required and what to expect back.
Modular ecosystem: third parties can publish MCP connectors (e.g., CRMs, databases, ticketing systems) that any MCP-aware agent can call.

How MCP works (high level)

Start an MCP server instance and register it with a name and metadata.
Register tools (functions) on the server with typed parameters and return types.
MCP clients (AI agents) discover available tools and their schemas.
When needed, an agent invokes a tool by name with appropriate inputs.
The server executes the tool and returns typed results the agent can use to compose a natural-language response.

Real-world example: Document Assistant for TechCorp

CustomerDB MCP — query orders and customer details.
SupportTicket MCP — create and update support tickets.
Inventory MCP — check stock and reservations.
Notifications MCP — send alerts or emails.

MCP Server	Purpose	Example tool
CustomerDB	Query order and customer data for user-facing answers	`get_order_status(order_id: str)`
SupportTicket	Create/update support tickets from conversations	`create_ticket(subject: str, description: str)`
Inventory	Check availability and reservations	`check_stock(sku: str, quantity: int)`
Notifications	Send emails and alerts	`send_notification(recipient: str, message: str)`

When a user asks, “What’s the status of order 1234?”, the agent can discover and call the CustomerDB MCP, pass order_id=1234, receive the status, and return a natural language answer. The agent manages the integration flow rather than the developer pre-wiring the connection.

MCP servers expose typed, discoverable functions. This gives agents the context they need to call external systems safely and accurately without hardcoding the integration into the agent itself.

Example: simple MCP customer DB server Below is a minimal illustrative MCP server implementation. It demonstrates the typical structure: a server instance, typed tool registration, and a small in-memory datastore. Replace the in-memory store with a production datastore (SQL, MongoDB, etc.) and add authentication, logging, monitoring, and rate limiting before production use.

# example_mcp_customer_db.py
from typing import Optional, Dict, Any
from fastmcp import MCPServer, mcp_tool  # hypothetical fastmcp library for illustration

# In-memory fake database for demonstration purposes
customers: Dict[str, Dict[str, Any]] = {
    "1234": {"order_id": "1234", "status": "Shipped", "items": ["widget-a", "widget-b"]},
    "5678": {"order_id": "5678", "status": "Processing", "items": ["widget-c"]},
}

# Create and start an MCP server instance named "CustomerDB"
server = MCPServer(name="CustomerDB", description="Customer and order lookup for TechCorp")

# Expose a function the AI agent can call to look up order status.
# The decorator registers the function with typed metadata that MCP clients can discover.
@mcp_tool(name="get_order_status", summary="Get order status by order_id")
def get_order_status(order_id: str) -> Optional[Dict[str, Any]]:
    """
    Look up an order by its ID and return its details.
    Returns None if the order is not found.
    """
    return customers.get(order_id)

# Register the tool and run the server (blocking call in this simplified example)
server.register_tool(get_order_status)
server.start(host="0.0.0.0", port=8080)

Explanation of the example

MCPServer — represents the MCP server process with a human-readable name and metadata. This is what agents discover.
mcp_tool decorator — registers a callable and emits parameter and return-type metadata so agents treat the function like a typed API endpoint.
get_order_status — the registered tool. It accepts order_id and returns order details or None if not found.
customers — an in-memory store used only for demonstration. In production, replace with a proper database.

Design considerations and best practices

Schema-first tools: declare clear parameter types and return schemas so agents can validate inputs and interpret outputs.
Idempotency and retry semantics: document which tools are safe to retry and which are not.
Observability: log invocations, successes, failures, latencies, and agent identities to support auditing.
Lifecycle and versioning: provide version metadata and deprecation strategies for tools as schemas evolve.

Security and access control

Authenticate agents that discover and call your MCP server.
Enforce authorization rules per tool and per agent identity.
Audit every tool invocation for forensic and compliance needs.
Apply rate limits and quotas to prevent abuse.

When exposing MCP servers, carefully design authentication, authorization, and auditing. MCP tools can expose privileged operations; ensure access controls and rate limits are in place before connecting them to agents.

Summary

MCP servers expose typed tools that agents can discover and call at runtime.
Developers build and publish MCP servers once; any MCP-aware agent can use them.
Agents select the appropriate MCP tools, pass typed inputs, and handle typed outputs — enabling dynamic capability extension without hardcoding integrations.

Links and references

Designing APIs that Agents Can Use (guide to schema-first tools)
Authentication and Authorization Patterns (recommendations for securing service-to-service calls)
Build resilient services (retries, idempotency, and circuit breaking)

AI Agents - Part 1

AI Agents - Part 2

Introduction

Model Context Protocol

Watch Video