Search for a command to run...
How Model Context Protocol and Agent Communication Protocol shape the AI stack.
Software Engineer x Data Engineer - I make the world a better place to live with software that enables data-driven decision-making
No comments yet. Be the first to comment.
In this series, I will discuss machine learning concepts and their implementation in the modern world of software architecture. [Series cover photo by JJ Ying on Unsplash]
Model Context Protocol Server in Real-Life Example
Optimize context budgets and eliminate prompt bloat by decoupling skill discovery triggers from execution details.
Why fanning out OAuth introspection inside your VPC creates a distributed bottleneck - and how to keep internal auth fast.
A practical follow-up on turning agent instructions into focused, testable workflows.
How to reduce context size, improve reasoning, and build more predictable AI coding workflows
The rapid evolution of the AI developer space has shifted our focus from single-turn propmpts to autonomous, multi-agent workflows. Building a system that scans code, writes a PR, runs tests, and deploys a fix is no longer a sci-fi demo. However, as we build these multi-step pipelines, we run into an integration headache: every framework, IDE, and model provider seems to define its own way of connecting agents to dbs, APIs, and other specialized assistants.
If every agent needs a custom integration for every tool and every other assistant, the ecosystem will collapse under its own weight. To avoid this integration hell, the industry is moving towards standardization. In this landscape, two acronyms are emerging as key players: MCP (Model Context Protocol) and ACP (Agent Communication Protocol, which has recently merged into the Linux Foundation's A2A standard). While they sound similar, they operate at entirely different layers of the agentic stack.
Developed by Anthropic and adopted across the industry by Google and OpenAI, MCP is the "USB-C port" for AI models. It standardizes the connection between LLM client (the runner) and the external data sources or tools it needs to interact with.
Before MCP, if you wanted a coding assistant to read a local directory or query a database, you had to write custom tool-calling wrappers tailored to that specific assistant's API. If you switched from a custom python runner to a new IDE plugin, you had to rebuild those integrations from scratch.
MCP solves this via client-server architecture:
The Client: The application running the LLM (like Claude Desktop, Cursor, or a custom runner)
The Server: a lightweight process exposing tools, resources (files, DB schemas), and prompts through a standard protocol.
Communication happens locally over stdio or HTTP Server-Sent Events (SSE). The client doesn't need to know how the server accesses a database; it just queries the server for available tools, and the server executes actions. It is local, secure, and model-agnostic. MCP gices the model hands and eyes to interact with its immediate host.
While MCP focuses on how a model talks to tools, the Agent Communication Protocol (ACP) addresses a higher-level challenge: how agents talk to each other.
In complex pipelines, a single LLM call is rarely enough. You often have a network of specialized agents working in tandem - for example, a PM agent defining requirement, a Developer agent writing code, and a QA agent testing it. Currently, building such a systems locks you into a specific framework (like CrewAI, LangGraph, or AutoGen). Coordinating accross different frameworks requires writing custsom glue code.
The Agent Communication Protocol (ACP) — which has recently merged into the Linux Foundation's unified Agent-to-Agent (A2A) Protocol — introduces a framework-independent messaging standard defining:
Discovery: How agents find other specialized assistants on a network (using machine-readable metadata or "Agent Cards").
Delegation: How an orchestrator sends a task to a worker agent and monitors progress.
State Sharing: How agents pass context, message history, and token budgets.
(Note: While originally developed as ACP by IBM for the BeeAI project, it has transitioned directly to the Linux Foundation's A2A standard. Additionally, in the developer tooling space, you might encounter the Agent Client Protocol (another "ACP"), which standardizes how IDEs control autonomous coding assistants. Both definitions focus on workflow-level coordination rather than raw tool access).
Think of the LLM as the CPU of your agentic system.
MCP is the equivalent of the PCIe slor or USB controller. It defines how the CPU plugs into local hardware - storage, networks, and peripherals. It is low-latency, localized, and handles data retrieval and basic actions.
ACP is the equivalent of TCP/IP or HTTP. It defines how independent computers (agents), each with their own CPU and local memory, communicate across a network to share workloads and complete distributed tasks.
| Feature | Model Context Protocol | Agent Communication Protocol |
|---|---|---|
| Primary Level | Tool and Context Access (Model-to-Tool) | Workflow and Collaboration (Agent-to-Agent) |
| Connection Type | Client-Server (Typically local via stdio) | Distributed (Often remote via event streams/gRPC) |
| Key Capability | Read files, query databases, execute local scripts | Delegate tasks, coordinate multi-agent teams |
| Analogy | USB-C cable connecting a laptop to a monitor | HTTP request communicating between microservices |
Here is these two protocols work together to fix a migration bug:
The Trigger: A developer requests a fix. The IDE uses the Agent Client Protocol (ACP) to spin up the Orchestrator Agent.
Coordination (ACP): The Orchestrator (Agent A) needs a database analyst to look at the schema. It messages the DB Analyst Agent (Agent B) using the Agent Communication Protocol (ACP).
Tool Execution (MCP): The DB Analyst Agent queries a local database using a standard Postgres MCP Server, retrieves the schema, and find the issue.
Feedback & Fix (ACP & MCP): Agent B reports the root cause back to Agent A, which delegates the code fix to the Developer Agent (Agent C). Agent C edits the migration files and runs a dry run using a local Shell MCP Server.
Resolution: Once verified, the IDE displays the completed task.
By separating the protocols, the database doesn't need to understand the task delegation, and the orchestration layer doesn't need to know how to connect to Postgres.
As we build more advanced AI systems, modularity is our best defense against complexity. Trying to build a monolithic agent that knows how to communicate with every API and orchestrate every colleague agent is a recipe for unmaintenable code.
When designing your next AI ferature, keep the boundaries clear:
Expose your data, schema, and local APIs as MCP servers. This ensures any model or agent runner you use in the future can instantly leverage them.
Structure your multi-agent interactions and task delegations around ACP standards to prevent getting locked into a single orchestration library
Standardizing these connectionlayers is what will turn AI coding assistands from novelty IDE extension into robust, scalable software engineering plartforms.
Model Context Protocol: https://modelcontextprotocol.io/
Model Context Protocol GitHub: https://github.com/modelcontextprotocol
Agent-to-Agent (A2A) Protocol: https://a2a-protocol.org/
Linux Foundation A2A Project GitHub: https://github.com/a2aproject
Agent Client Protocol: https://agentclientprotocol.com/
Hope this helps,
Cheers!