MCP (Model Context Protocol) explained for developers

The problem MCP solves

Every useful AI application needs to reach real data and real actions: a database, a ticketing system, a file store, an internal API. Before MCP (Model Context Protocol), each AI app integrated each tool its own way. Ten apps and ten tools meant up to a hundred custom integrations.

MCP is an open protocol that standardises this connection. A tool is exposed once, as an MCP server, and any MCP-capable application (a chat assistant, an IDE, your own agent) can use it. Think of it as a common plug between AI applications and the systems they need.

The moving parts

Part	What it is	Example
Host	The AI application the user works in	A desktop assistant, an IDE, your own app
Client	The connector inside the host that speaks MCP	One client per connected server
Server	A small program that exposes capabilities	An "orders" server, a "policies" server

An MCP server can expose three kinds of things:

• Tools: actions the model can call, with a name, a description and typed inputs (for example get_order(order_id)).
• Resources: data the application can read (for example a policy document).
• Prompts: reusable prompt templates the user can pick.

Servers run either locally (communicating over standard input/output) or remotely (over HTTP), so the same idea works on a laptop and in production.

A tiny MCP server in Python

Using the official Python SDK, a server with one tool looks like this:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("orders")

@mcp.tool()
def get_order(order_id: str) -> dict:
    """Look up an order's status, items and delivery date by its ID."""
    return orders_db.find(order_id)   # your own data access

if __name__ == "__main__":
    mcp.run()

The docstring and type hints matter: they become the description and schema the model sees. A clear description ("Look up an order's status… by its ID") is what lets the model choose the tool correctly.

How a request flows

1. The user asks: "Where is my order 8841?"
2. The host lists the tools available from connected MCP servers and passes them to the model.
3. The model decides to call get_order with order_id="8841".
4. The client sends the call to the orders server, which runs your function and returns the result.
5. The model writes the answer using that result.

Your function never had to know which AI application called it.

MCP vs plain function calling

Function calling (tool calling) is the model's ability to request a function. MCP does not replace it; it standardises where the functions live and how they are described and transported.

• Use plain function calling for a single app with a few internal functions.
• Use MCP when the same tools should be reused across several AI apps or teams, when tools are owned by different teams, or when you want to plug into existing MCP-capable hosts.

Security: treat every server like an API with power

MCP makes it easy to give a model real capabilities, which is exactly why it needs care:

• Least privilege. Read-only tools by default; separate write tools; scoped credentials per server.
• Confirm consequential actions. Payments, emails and deletions should require explicit user approval.
• Validate inputs inside the tool, as you would for any API.
• Be careful with untrusted content. Text returned by a tool (a web page, an email) can contain instructions aimed at the model. Do not let tool output silently trigger other actions.
• Log tool calls with inputs and results for audit.
• Only connect servers you trust, and pin their versions.

Where to start

1. Pick one internal capability people ask about often (orders, tickets, policies).
2. Expose it as a read-only MCP server with two or three well-described tools.
3. Connect it to an MCP-capable host and try real questions.
4. Add evaluation cases: does the model call the right tool with the right arguments?
5. Only then add write actions, with confirmation.

MCP is quickly becoming the standard way to connect AI to the systems a business already runs. Learning to design small, safe, well-described servers is one of the most practical skills for an AI engineer today.