In Lesson 14, we introduced MCP (Model Context Protocol) and A2A at a high level. This lesson goes deeper on MCP specifically - how it actually works under the hood, when it adds real value, when simpler approaches are better, and how to think about security.
We also tackle one of the most debated questions in the AI engineering community: when should you use MCP servers vs. just letting your agent use CLI tools directly?
Your laptop can plug directly into a wall outlet. That works fine at home. But in an office with 50 devices, you want a power strip with surge protection, individual switches, and a circuit breaker. MCP is that power strip - it adds a layer of management between the agent and the tools it uses. Whether you need that layer depends on how many tools you have, who is using them, and how much control you need.
Key takeaway: MCP is a powerful protocol for connecting agents to external tools and data, but it has real trade-offs in cost and complexity. Understanding when MCP adds value versus when simpler approaches work better is a critical skill for agent builders.
MCP follows a client-server architecture with three roles:
+------------------+ +------------------+ +------------------+
| | | | | |
| MCP Host | | MCP Client | | MCP Server |
| (Your app) |---->| (Protocol |---->| (Tool |
| | | handler) | | provider) |
| | | | | |
+------------------+ +------------------+ +------------------+
All messages use JSON-RPC 2.0. The protocol supports two transport mechanisms:
| Transport | Use Case | How It Works |
|---|---|---|
| stdio | Local tools | Server runs as a subprocess, communicates over stdin/stdout. Simple, fast, no network overhead. |
| Streamable HTTP | Remote tools | Uses a single HTTP endpoint with bidirectional communication. Supports serverless deployment (Lambda, Cloud Functions). |
Note: The original SSE (Server-Sent Events) transport was deprecated in the March 2025 spec revision. SSE was one-directional and required two endpoints. Streamable HTTP replaced it with a single-endpoint, bidirectional design.
MCP servers can expose three types of capabilities:
| Primitive | What It Is | Who Controls It | Example |
|---|---|---|---|
| Tools | Functions the agent can call | The model decides when to use them | query_database, send_email, create_file |
| Resources | Data the agent can read | The application or user selects them | Database schemas, file contents, API documentation |
| Prompts | Reusable prompt templates | The user invokes them | “Summarize this codebase”, “Review this PR” |
In practice, Tools are by far the most widely used primitive. As of late 2025, 99% of MCP clients support Tools, while Resources and Prompts have around 30-35% adoption.
This is one of the most actively discussed topics in AI engineering right now. The core question: if an AI agent can run shell commands, why does it need MCP?
Many MCP servers are thin wrappers around tools that already have excellent CLIs. The GitHub MCP Server reimplements functionality available through gh. The Docker MCP Server wraps docker commands. The Kubernetes MCP Server wraps kubectl.
LLMs already know how to use these CLIs. They were trained on millions of man pages, Stack Overflow answers, and GitHub repositories. When an agent uses gh pr list, it uses knowledge it already has. When it uses an MCP server, it needs to load the tool schema into its context window first.
The numbers are stark:
| Metric | CLI Approach | MCP Approach |
|---|---|---|
| Token cost (simple query) | ~1,400 tokens | ~44,000 tokens (32x more) |
| Initialization cost | Near zero | Can be 50,000+ tokens for schema loading |
| Reliability (benchmark) | 100% | 72% |
| Setup required | None (tools already installed) | Install and configure MCP server |
The token cost difference comes from MCP needing to load full tool schemas (names, descriptions, parameter types, return types) into the context window. A database MCP server with 106 tools consumed 54,600 tokens just to initialize - before any actual work happened.
The properties that make MCP expensive are the same properties that make it governable:
Security and authentication. CLI tools run with the user’s ambient permissions. If the agent can run rm -rf /, it will if it decides to. MCP provides a permission boundary. The spec mandates OAuth 2.1 with PKCE for HTTP-based servers, giving you standardized authentication, token rotation, and revocation.
Multi-user environments. When an agent acts as you, CLI’s ambient security is fine. When an agent acts on behalf of other people - reading customers’ repos, writing to their Jira, messaging their Slack - you need per-user auth, scoped permissions, and audit trails. MCP provides a framework for this.
Tool discovery. MCP servers advertise their capabilities through schemas. An agent can discover what tools are available at runtime without being told upfront. This matters when tools change or when different users have access to different tools.
Structured I/O. MCP tools have typed inputs and outputs. CLI output is unstructured text that the agent must parse. For simple tools this is fine, but for complex APIs with nested JSON responses, structured output is more reliable.
| Situation | Recommended Approach | Why |
|---|---|---|
| Developer working locally | CLI | Zero setup, the agent already knows the tools, cheapest option |
| Well-known tools (git, docker, kubectl, jq) | CLI | LLM has strong training data, reliable parsing |
| Single-user agent | CLI | Ambient permissions are acceptable |
| Multi-user / multi-tenant | MCP | Need per-user auth and scoped permissions |
| Enterprise with audit requirements | MCP | Need structured logging and access control |
| High-frequency narrow tool set | MCP | Schema cost amortizes over many calls |
| Broad tool surface, occasional use | CLI | Avoid paying schema cost for tools rarely used |
| Custom internal API with no CLI | MCP | No existing CLI to leverage |
| Tools that change frequently | MCP | Dynamic discovery handles changes automatically |
Most production systems use both. Claude Code, for example, has a Bash tool for direct CLI access and also supports MCP servers. The decision is per-integration, not system-wide.
A reasonable default: start with CLI. Add MCP when you hit a specific limitation that MCP solves - usually authentication, multi-tenancy, or structured tool discovery.
An interesting tool called mcp2cli converts any MCP server into a CLI at runtime. Instead of loading all tool schemas upfront, the agent queries --list and --help only when needed. This has shown 96-99% token reduction in benchmarks while keeping MCP’s structured API underneath.
MCP introduces a new attack surface. The OWASP Foundation published an MCP Top 10 security risk list. Here are the ones that matter most for agent builders:
A malicious or compromised MCP server can return manipulated results. If your agent trusts tool output without verification, it can be led to take harmful actions.
Mitigation: Validate tool outputs. Use multiple sources for critical decisions. Implement output filtering.
A malicious tool mimics a legitimate one. If an agent has access to two tools with similar names - say query_database from a trusted server and query_db from an untrusted one - it might use the wrong one.
Mitigation: Control which MCP servers your agent can connect to. Review tool names and descriptions. Use allowlists for tool access.
MCP does not have native scope limiting. A database MCP server might expose both read and write operations. If your agent only needs to read, it can still write.
Mitigation: Build or use MCP servers that expose only the operations you need. Implement server-side access controls. Use an API gateway (like Apigee) in front of MCP servers for fine-grained permission management.
Too many MCP tools degrade agent performance. Each tool definition consumes context tokens. A server with 100+ tools can exhaust a significant portion of the context window before any real work begins.
Mitigation: Keep tool counts per server reasonable (under 20). Use multiple specialized servers instead of one large one. Consider lazy loading of tool schemas.
Analysis of 5,200 open-source MCP servers found that over half rely on long-lived static API keys. Only about 8.5% use modern auth like OAuth.
Mitigation: Use short-lived scoped credentials. Store secrets in a secret manager (like Google Cloud Secret Manager), not in environment variables or config files. Rotate credentials regularly.
Google Cloud provides several integration points for MCP:
Google’s Agent Development Kit (ADK) has built-in support for MCP tools. You can connect to any MCP server and use its tools within your ADK agent.
For details on configuring MCP tools in ADK, see the ADK MCP Tools documentation.
For enterprise deployments, Apigee can serve as an API and agent gateway for MCP. This adds:
This is particularly useful when you have many teams deploying MCP servers and need centralized governance.
Model Armor can filter and validate inputs and outputs flowing through MCP tool calls, adding protection against prompt injection and data exfiltration through tool interactions.
If you decide to build an MCP server for your service, here are the key decisions:
| Question | stdio | Streamable HTTP |
|---|---|---|
| Is the server local to the agent? | Yes | Either |
| Do you need remote access? | No | Yes |
| Do you need to deploy serverlessly? | No | Yes |
| Is latency critical? | Yes | Less so |
Prefer fine-grained tools over coarse-grained ones:
get_user_by_id, list_users, create_user, update_user_emailmanage_users (one tool that does everything based on a mode parameter)Fine-grained tools give the LLM clearer choices and produce better results. But keep the total count manageable - 5-20 tools per server is a good range.
Tool names and descriptions are the primary way the LLM decides which tool to use. Invest time in making them clear:
search_documents_by_topic not searchKeep tool outputs concise. The output goes into the agent’s context window, and large responses eat into the budget.
When deciding how to connect your agent to an external service:
Do you need to connect to an external service?
|
+-- Is there a well-known CLI for it? (git, docker, aws, gcloud, kubectl)
| |
| +-- Yes: Does the agent need multi-user auth or audit trails?
| | |
| | +-- No: Use the CLI directly
| | +-- Yes: Use MCP with OAuth
| |
| +-- No: Continue below
|
+-- Is there an existing MCP server for it?
| |
| +-- Yes: Is it actively maintained and from a trusted source?
| | |
| | +-- Yes: Use the MCP server
| | +-- No: Consider building your own or using CLI/API directly
| |
| +-- No: Continue below
|
+-- Does the service have a REST API?
|
+-- Yes: Build an MCP server or use ADK OpenAPI tools
+-- No: Build a custom function tool or MCP server
| Previous Lesson: AGENTS.md | Next Lesson: Agent Skills -> |