MCP — Connecting Agents to Tools & Data

MCP stands for Model Context Protocol. It is an open standard, supported by many companies, that lets any AI app talk to any tool that speaks it. This lesson replaces the habit of writing a custom link for every service with one shared way of connecting.

The problem it solves

Imagine you have N agents and M tools. Without a shared standard, you need N times M custom links. Each one has its own login, its own error format and its own way of describing itself. MCP fixes the tool side. You build one MCP server for a capability. Then any MCP-ready agent can use it with no custom work.

Host, client and server

• Host: the app that runs or manages the model. For example, a coding assistant, or the agent you are building.
• Client: a part inside the host that speaks MCP and looks after the connections to servers.
• Server: a small program that offers one set of abilities, such as reading files, using a database, calling an API or running code.

There are two common ways to connect. Stdio is for a server on the same computer. It is fast and needs no network, so it is the usual choice for local tools. Streamable HTTP is for remote servers. It uses ordinary web requests and normal web login. The standard keeps changing, so always check the current specification.

const client = new MCPClient({ transport: "stdio", command: "npx", args: ["my-mcp-server"] });
await client.connect();

const tools = await client.listTools();          // discover what this server exposes
const result = await client.callTool("search_docs", { query: "context window" });

Security: an MCP server is still an untrusted tool

This is where least privilege starts in practice. A server that reads customer records should not also be able to change them, unless the task truly needs that.

Going deeper: what a server offers, and how to build one

An MCP server can offer three kinds of things. Tools are functions the model can call, and they may change things. Resources are data the app can read into context, such as files or records. Prompts are ready-made prompt templates that users can pick. The standard also has features on the client side. Check the current specification for the full list.

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("orders")

@mcp.tool()
def get_order(order_id: str) -> dict:
    """Look up one order by id (format ORD-12345). Read-only. Returns status, total_cents, items."""
    order = db.fetch_order(order_id)
    if not order:
        return {"error": "order_not_found", "hint": "ids look like ORD-12345"}
    return order.public_fields()          # never return internal columns or other customers' data

@mcp.resource("orders://{order_id}/receipt")
def receipt(order_id: str) -> str:
    """Plain-text receipt for an order."""
    return render_receipt(order_id)

if __name__ == "__main__":
    mcp.run()                              # stdio by default; use an HTTP transport for remote servers

# Check the SDK docs for current decorators/transports - APIs evolve.

Design rules for servers you write

• Offer a few well-described tools built around what users want to do. Do not copy every web endpoint one for one.
• Limit the size of every response and add pages. Remember that results go into the model's context.
• Keep tools that read apart from tools that change things. Mark which ones need approval in the host app.
• Check every input on the server. Never assume the model sent safe values.
• Make remote servers log users in. OAuth is the usual way. Give each token the least access it needs, and never share one login between users.
• Log every call: who called, which tool and with what inputs. You will want this for audits.

Security: tool descriptions can be attacked

A tool's name and description are text the model reads and trusts. A bad or hacked server can hide instructions inside a description. This is called tool poisoning. It can also change what a tool does after you approved it. Or it can copy the name of a trusted tool. To protect yourself, do these things. Pin server versions. Review any change to descriptions. Allow only servers you trust. Keep each server's logins separate. And never connect a server that reads untrusted content to one that holds sensitive access, unless a person approves.