Why a Coordination Vocabulary?
The Model Context Protocol (MCP) lets a model call tools and read data. Agent2Agent (A2A) lets independent agents send each other messages. Neither defines the content of a coordination message — the shared words for “decision recorded” or “milestone reached.” DCP is that missing vocabulary: a thin envelope carrying one Event over eight project-coordination entities.
Agents can talk. They still can’t agree on what to say.
Section titled “Agents can talk. They still can’t agree on what to say.”MCP solved a real problem: how does a model reach a tool or a data source without a bespoke integration per pair. A2A solved a different problem: how does one agent send a message to another agent regardless of who built it. Both are transport- and access-layer protocols. Neither one specifies what the payload of a coordination message should look like once two agents are, in fact, talking.
The result, in practice: every team that wires agents into a shared project reinvents the same ad-hoc JSON. One team’s “task done” event has a status field; another’s has a state field with different casing; a third bolts a free-text notes string onto everything and calls it done. None of these are wrong, exactly — they’re just not shared. An agent built by one team cannot parse a coordination event from another team’s agent, even though both are fluent in MCP and both speak A2A. The transport problem is solved. The semantics problem was never addressed, because it was never MCP’s or A2A’s job to address it.
DCP fills that specific gap
Section titled “DCP fills that specific gap”The Development Coordination Protocol is an open, vendor-neutral, machine-readable vocabulary for exchanging project-coordination events — not a transport, not an auth scheme, not an orchestration engine. As the SPEC states plainly: DCP defines only the structure of project-coordination messages.
Every DCP message is a thin DcpMessage envelope carrying exactly one Event. The event names what changed (entity_type + verb), which thing changed (entity_id), and how — via an entity snapshot, a delta, or refs to other entities. That event describes a change to one of eight closed entities: Project, Task, Dependency, ArchitectureImpact, Decision, ReviewRequest, Finding, or Milestone. As of 2026-07-01 the spec ships 14 JSON Schemas (2020-12), 70 passing tests, a 20-case conformance corpus (7 accept / 18 reject), and 18 worked examples covering all eight entities — enough surface area to say the vocabulary is exercised, not merely proposed.
Crucially, DCP carries no trust. It never authenticates a sender, authorizes an action, or routes a message — those stay exactly where MCP and A2A already put them: in the transport and access layer. DCP only says what changed.
The HTTP-over-TCP analogy
Section titled “The HTTP-over-TCP analogy”The SPEC’s own framing is the clearest way to place DCP in the stack: TCP moves bytes reliably; HTTP gives those bytes a shared request/response shape; a media type like application/json gives the HTTP body a shared grammar. DCP is that last layer for coordination — a media type for coordination events, riding inside whatever carries it.
Map that onto agent protocols: A2A (or MCP, or a message queue, or a database row) is the transport — it gets a payload from one place to another and handles identity and delivery. DCP is the payload’s grammar. A DCP message doesn’t care whether it arrived over an A2A task update, an MCP tool result, a Kafka topic, or a file on disk — it is independently readable and validatable regardless of the carrier. Moving a DCP message from one transport to another is a transport swap, not a rewrite.
Complementary, not competing
Section titled “Complementary, not competing”This means DCP isn’t proposing an alternative to MCP or A2A — it has nothing to say about tool invocation or agent-to-agent messaging at all. It enters the “how do agents coordinate” conversation at exactly one layer: as the extractable, vendor-neutral payload vocabulary that can sit inside an A2A message or an MCP tool response. Two agents can use A2A to exchange messages and DCP to make sure a “decision recorded” event means the same thing to both of them, without either protocol needing to know about the other. See DCP vs. A2A and DCP vs. MCP for a closer look at where each boundary sits.
If your agents already speak MCP and A2A and you’ve noticed that “what actually happened in the project” still gets reinvented per integration, that’s the gap DCP was built to close. The quickstart validates your first message in under five minutes.
By InterIP Networks · Last updated 2026-07-01.
