MCP Fundamentals: How AI Agents Connect to the World
The Model Context Protocol is the open standard that gives AI models a consistent way to call tools, read live data, and reuse prompt templates — across any provider, any runtime.
Every AI agent eventually needs to do something beyond generating text. It needs to search the web, read a file, call an API, query a database. The question is: how?
Before MCP, every team solved this differently. One agent framework had its own plugin format. Another had its own tool-calling spec. Switching models or runtimes often meant rewriting all your integrations.
MCP is the fix. It is an open protocol — maintained by Anthropic, adopted by OpenAI, Google, and dozens of tool vendors — that defines a single standard for how AI models connect to external capabilities.
The Three Roles: Host, Client, Server
MCP has three actors:
The flow is always: Host → Client → Server → Client → Host → Model. The model never talks directly to a server. The client is the intermediary.
This separation matters. Hosts can enforce security policies (what servers are allowed), clients can handle auth, and servers stay focused on exposing capabilities.
The Three Primitives: Tools, Resources, Prompts
Every MCP server exposes its capabilities through exactly three primitives:
Functions the model can call. Each tool has a name, a description (used by the model to decide when to call it), and a JSON Schema for its input. Examples: search_web, run_sql_query, create_github_issue.
Tools are the most commonly used primitive. When the model decides to call a tool, the client executes it and returns the result as context for the model's next step.
Static or live data that the host can attach to context. Resources are identified by URIs (e.g., file:///path/to/file.txt, postgres://db/schema). Unlike tools, resources are read — they don't execute code.
The host (not the model) decides which resources to include. This is important for security: the model can request resources, but the host approves the read.
Pre-built prompt templates that can accept arguments and generate structured messages. Users can invoke them explicitly (like slash commands in Claude Desktop). Example: a /summarize-pr prompt that accepts a PR URL and produces a review template.
The split between Tools (model-controlled), Resources (app-controlled), and Prompts (user-controlled) is intentional. It maps cleanly to who should be making each decision — and makes it easier to reason about permissions and trust.
The Protocol: JSON-RPC 2.0
Under the hood, MCP uses JSON-RPC 2.0 — a simple request/response format where every message has a method, params, and an id:
// Client asks server what tools are available
{ "jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {} }
// Server responds
{
"jsonrpc": "2.0", "id": 1,
"result": {
"tools": [
{
"name": "search_web",
"description": "Search the web for current information",
"inputSchema": {
"type": "object",
"properties": { "query": { "type": "string" } },
"required": ["query"]
}
}
]
}
}
// Client calls the tool
{
"jsonrpc": "2.0", "id": 2,
"method": "tools/call",
"params": { "name": "search_web", "arguments": { "query": "MCP protocol 2025" } }
}JSON-RPC 2.0 also supports notifications — one-way messages with no id that don't require a response. Servers use these to push progress updates during long-running operations (e.g., streaming partial results while a search completes).
Two Transports: Local and Remote
MCP works over two transport mechanisms:
The client spawns a local process (e.g., a Python or Node.js script) and communicates via stdin/stdout. All messages are newline-delimited JSON. Used for local tools: filesystem access, running shell commands, reading local databases. No network needed.
The client sends HTTP POST requests to a remote server. Responses can be plain JSON or server-sent events (SSE) for streaming. Used for remote servers: SaaS tools, shared team servers, cloud APIs. Supports stateless and stateful modes.
In practice: local developer tools use STDIO because it's simpler and doesn't require network config. Production agent systems use Streamable HTTP so multiple clients can share one server.
How Discovery Works
When a client connects to a server, the first thing it does is initialize — exchanging protocol versions and capabilities:
- Client sends
initializewith its supported protocol version - Server responds with its version and capability flags (does it support resources? prompts? streaming?)
- Client sends
initializednotification to complete the handshake - Client calls
tools/list,resources/list,prompts/listto discover what the server exposes - The host injects the tool list into the model's system prompt so it knows what it can call
From here, the model can call any tool at any point in the conversation. The client handles execution and returns results as new context. The model sees tool results and decides what to do next.
Why This Matters for FDEs
As a Forward Deployed Engineer, you will be asked to build AI-powered workflows on top of customer systems. MCP directly shapes how you approach that:
- Tool design — when you expose a customer's API as MCP tools, how you write tool descriptions determines whether the model uses them correctly. Vague descriptions lead to wrong calls.
- Security boundaries — tools can have side effects (write to databases, send emails). You need to think about which tools to expose, what approval flows to add, and how to prevent the model from taking destructive actions.
- Transport choice — a local STDIO server is simpler but can't be shared. A remote Streamable HTTP server scales to teams but needs auth and reliability considerations.
- Debugging — when an agent fails, it's often because a tool returned an unexpected schema, or the model chose the wrong tool. Understanding the JSON-RPC trace is essential for debugging.
MCP is also increasingly required as a standard output in customer engagements. When a customer asks you to "integrate with their internal tools," building an MCP server is often the cleanest answer — it works with Claude, Cursor, and any other MCP-compatible host without vendor lock-in.