For the past three years, every production agentic system has been a tangle of bespoke OpenAPI wrappers, custom authentication schemes, and brittle per-client integration code. Adding a new tool required updating every client. Adding a new client required implementing every tool's custom calling convention again. Anthropic's Model Context Protocol (MCP), published November 25, 2024, is the standardization event that ends that. MCP is a JSON-RPC protocol with three primitives — tools (functions the LLM can invoke), resources (data it can read), and prompts (templates it can request) — and a client-server architecture where any MCP-compatible client can speak to any MCP-compatible server without custom integration code. Claude, OpenAI's Agents SDK, Cursor, Windsurf, and the LangChain ecosystem already support it. Google's Agent-to-Agent (A2A) protocol (April 9, 2025) operates one layer above MCP: it specifies how agents from different organizations discover each other via agent cards, authenticate, and delegate multi-step tasks. Where MCP is about a single agent accessing tools, A2A is about agent-to-agent collaboration — a DealLens agent at your firm delegating a cap-table analysis sub-task to a specialized financial-data agent at another firm. Together, MCP and A2A form the protocol stack that replaces the current chaos.
MCP: tools, resources, and prompts
MCP uses JSON-RPC 2.0 over stdio or HTTP+SSE as the transport. The three primitives: a tool is a function the LLM may call (name, description, JSON Schema input, returned content); a resource is data the LLM can read without calling a function (a file, a database row, a live feed — identified by URI); a prompt is a server-defined template the client can request to inject standardized context. The server exposes these via a tools/list endpoint and handles tools/call requests. Servers are small — the canonical Python implementation (FastMCP, maintained by Anthropic) is ~200 lines for a three-tool server.
The security model of MCP as of the November 2024 specification is trust-based: the client trusts the server, and the server trusts the client's tool calls. There is no built-in authorization framework specifying which tools a given user can call or with what parameters. This is a known gap. The 2025 additions add OAuth 2.1 authorization server support for remote MCP servers, which matters the moment your MCP server is exposed to the internet rather than running locally. For DealLens, the implication is explicit: your search-memos and score-deal tools must enforce authorization at the application layer, not the protocol layer, until the spec matures.
The practical value of MCP for DealLens is immediate: expose three tools as an MCP server and your agent becomes compatible with Claude Desktop, any LangChain MCP client, any future OpenAI Agents SDK client, and any other MCP-compatible orchestrator — with no additional integration work per client. The alternative is maintaining a separate OpenAPI spec, authentication scheme, and SDK wrapper for each client. At the pace the MCP ecosystem is growing (hundreds of servers listed in the MCP registry by mid-2025), the standardization bet is clearly correct.
A2A: agent-to-agent delegation
A2A (Google, April 9, 2025) addresses a problem MCP does not: how does an agent at organization A discover and delegate to an agent at organization B, with proper authentication and task lifecycle management? The core concept is the agent card — a JSON document hosted at a well-known URL (typically /.well-known/agent.json) that declares the agent's capabilities, input/output schemas, authentication requirements, and pricing. An A2A client discovers agent cards, selects the right agent for a sub-task, authenticates via OAuth 2.0 or API key, and exchanges Task objects with defined lifecycle states (submitted, working, completed, failed).
The DealLens use case: a portfolio-analytics orchestrator agent receives a mandate to screen 20 new deals. It discovers a DealLens agent card, delegates deal-scoring tasks to it via A2A, receives structured results, and aggregates. The DealLens agent discovers a financial-data agent card for cap-table verification and delegates to it. This multi-agent delegation pattern is what moves AI from single-agent demos to cross-organizational workflows — and A2A provides the standard so you do not invent your own.
MCP for the humanoid home assistant
The JHU humanoid capstone needs to expose home-control APIs: smart home state (lights, thermostat, appliances), calendar access, recipe database, and shopping list management. These are precisely MCP tool and resource primitives. The LangGraph planning loop calls the frontier LLM with the list of available MCP tools; the LLM decides which to call; the MCP client executes the call against the home assistant MCP server; results come back as structured content. The same architecture that makes DealLens tool-extensible makes the humanoid planner tool-extensible.
The critical constraint for the humanoid is that some MCP tools must be gated behind an interrupt: unlocking the front door, deleting a calendar event, placing a purchase order. MCP does not provide interrupt semantics natively — you implement those at the LangGraph orchestration layer (Chapter 22). The MCP server declares these tools normally; the orchestrator inspects the tool name against a hardcoded interrupt list before executing. This two-layer approach — protocol standardization at MCP, safety semantics at the orchestrator — is the correct separation of concerns.
Why MCP wins over bespoke OpenAPI wrappers
The network effect argument: as of mid-2025, every major LLM client speaks MCP. Building a bespoke OpenAPI integration means you maintain a custom translation layer for each client — Claude needs one format, OpenAI function calling needs another, LangChain needs a third. An MCP server is written once and consumed by all of them. The spec is stable enough for production (backwards-compatible versioning, clear deprecation policy), and the tooling (MCP Inspector for debugging, FastMCP for Python, TypeScript SDK) is mature enough to use without fighting the framework.
The one scenario where you keep a raw OpenAPI spec: when you need to expose your API to non-agent HTTP clients — browsers, Zapier, standard REST consumers — that will never speak MCP. In that case, maintain both: an OpenAPI spec for HTTP REST clients, and an MCP server that wraps the same logic for agent clients. The FastMCP server and the FastAPI router can share the same underlying Python functions.
A malicious MCP server can return tool descriptions designed to manipulate the LLM's behavior — this is the tool-poisoning attack (Chapter 24). Vet every third-party MCP server before adding it to your agent's tool list. Your humanoid's MCP server should be first-party only.