MCP & AI agents cheatsheet
A one-page reference for MCP and AI agents. For agent design patterns and safety/guardrail depth, see the complete guide.
📖 Full guide: MCP & AI Agents →Architecture: host, client, server
| Component | Role |
|---|---|
| Host | user-facing AI app (Claude Code, an IDE, a custom agent) — owns the conversation |
| Client | inside the host, 1:1 stateful connection to one MCP server |
| Server | exposes tools/resources/prompts over the protocol |
One host commonly holds many client connections at once — one per configured server.
What a server exposes
| Primitive | What it is |
|---|---|
| Tools | callable functions with an input schema — the LLM decides when to invoke |
| Resources | read-only data, addressed like URIs (file://, postgres://) |
| Prompts | reusable, parameterized prompt templates |
Transport
- stdio — server runs as a local subprocess (filesystem, git servers).
- HTTP/SSE — server runs remotely (hosted/shared servers).
Protocol is JSON-RPC 2.0-based, transport-independent.
Agents vs single-shot calls
A single-shot LLM call answers once from its context. An agent loops: observe → decide → call a tool → observe the result → decide again — until the task is done or it hits a stop condition.
Safety & guardrails
- Scope tool permissions narrowly — least privilege, same as any service credential.
- Put a human-approval checkpoint before irreversible/production-impacting actions.
- Read-only/investigative tasks: lower oversight. Anything that writes: explicit approval gate.
MCP vs plain function calling
Plain tool/function calling is one host wiring its own tools by hand. MCP standardizes the protocol so any compliant host can talk to any compliant server — write the server once, use it from every MCP-compatible client.
See: Safety & Guardrail Considerations