Home › Blog › MCP Tutorial

MCP Tutorial: The Protocol Quietly Becoming the USB Port of AI, Explained From Zero

Before the Model Context Protocol, connecting an AI model to your tools meant writing custom glue code for every single pairing: this model to that database, this assistant to that API, again and again. MCP replaces all of it with one open standard, which is why Anthropic built it, why OpenAI and the major agent frameworks adopted it, and why it now shows up in almost every serious AI engineering job description. This tutorial takes you from the core idea to a working server you can build today.

The Five Words That Explain the Whole Protocol

MCP has a small vocabulary, and once these five concepts click, everything else is detail.

1. Host. The AI application the user actually touches, such as Claude, an IDE assistant, or your own agent app. The host decides what the model is allowed to reach.
2. Client. The connector living inside the host. It maintains a one to one connection with a server and relays requests and results between the model and that server.
3. Server. The program you build. It wraps a capability, a database, a file system, an internal API, and exposes it through the protocol so any client can use it.
4. Tools. Actions the model can invoke through the server: run a query, create a ticket, send a message. Each tool has a name, a description, and a typed input schema the model reads to decide when and how to call it.
5. Resources and prompts. Resources are read only context the server can provide, like a file or a record. Prompts are reusable templates the server offers for common workflows. Together with tools, they are the three things a server can serve.

The transport underneath is JSON RPC, either over standard input and output for local servers or over HTTP for remote ones. You almost never touch that layer directly, because the official SDKs handle it.

Build Your First MCP Server in Under Thirty Lines

The Python SDK makes a minimal server almost embarrassingly short. This example exposes two things: a tool that looks up an order, and a resource that serves a returns policy document.

# pip install "mcp[cli]"from mcp.server.fastmcp import FastMCPmcp = FastMCP("orders")@mcp.tool()def get_order_status(order_id: str) -> str:"""Look up the current status of an order by its id."""# in real life this queries your database or APIreturn f"Order {order_id}: shipped, arriving Thursday"@mcp.resource("policy://returns")def returns_policy() -> str:"""The current returns policy document."""return "Returns accepted within 30 days with receipt."if __name__ == "__main__":mcp.run()

That is a complete, standards compliant server. The decorator reads your function signature and docstring and turns them into the schema the model sees. Connect it to a host, ask a question about an order, and the model discovers the tool, calls it with a validated order id, and folds the result into its answer. No prompt engineering tricks, no glue code.

What Actually Happens on a Call

Understanding the flow is what separates using MCP from being able to debug it, and debugging it is what interviews and production both demand.

• On connection, the client asks the server what it offers, and the server returns its list of tools, resources and prompts with their schemas
• The host passes those tool definitions to the model as part of its context, so the model knows what it can ask for
• When the model decides a tool is needed, the client sends a call request with arguments, the server executes, and the result flows back into the model's context
• The host stays in control throughout: it can require human approval per call, filter which tools are exposed, and log everything for audit

The Production Concerns a Tutorial Should Not Hide From You

We want you to trust this guide, so here is the part most tutorials skip. Putting MCP into production raises real questions, and the engineers who can answer them are the ones who get hired.

• Security: a tool is an action the model can take, so scope permissions tightly, validate every input, and treat tool descriptions from third party servers as untrusted content
• Authentication: remote servers need real auth, and the ecosystem has settled on OAuth based flows for HTTP transports
• Reliability: design tools to be idempotent where possible, return structured errors the model can reason about, and log every call for tracing
• Context budget: every exposed tool consumes context window, so curate the toolset per task instead of exposing everything to every conversation

Adoption tells you which way this is going. Beyond Anthropic's own products, OpenAI adopted the protocol across its offerings in 2025, and agent frameworks now treat it as a first class citizen, with CrewAI shipping native MCP support. Learning it is no longer optional for serious agent work; it is the shared plumbing.

The Jobs This Knowledge Unlocks

MCP fluency is quickly becoming the dividing line in agent engineering interviews. These are the roles where being able to sketch the host, client and server flow gets you hired.

The stack behind these roles

MCPClaudePythonFastAPICrewAILangGraph