# Agent Client Protocol: a Rust schema crate and JSON Schema artifacts for editor-to-agent communication > ACP defines how a code editor talks to a coding agent over JSON-RPC. This repository ships the Rust data model, the versioned JSON Schema files, and the generator that produces them, not a runtime SDK. **agentclientprotocol/agent-client-protocol** — A protocol for connecting any editor to any agent - Repository: https://github.com/agentclientprotocol/agent-client-protocol - Website: https://agentclientprotocol.com - Stars: 4,356 · Forks: 411 - Language: Rust - License: Apache-2.0 - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/agentclientprotocol-agent-client-protocol ## What ACP standardizes, and who this repository is actually for The Agent Client Protocol standardizes communication between code editors, described in the README as interactive programs for viewing and editing source code, and coding agents, described as programs that use generative AI to autonomously modify code. That is the whole scope. It is a wire contract, not a product. The practical consequence is that this repository is not the thing most people want. Its root Rust crate is agent-client-protocol-schema, which the README describes as providing the Rust data model for ACP wire messages: request, response, notification, JSON-RPC envelope, and protocol-version types. If you are implementing a Rust agent or client, the README points you at the higher-level agent-client-protocol runtime crate instead, and calls the schema crate the lower-level protocol type surface. So the audience here is narrow and specific. People writing code generators that consume the JSON Schema. People building a Rust integration who need the message types underneath the runtime. People maintaining an SDK in another language who want the canonical schema as their source of truth. Everyone else, including anyone who just wants an agent inside their editor, is in the wrong repository. ## How the schema repository is laid out and how artifacts are generated The workspace has four default members: agent-client-protocol-schema, schema/v1, schema/v2, and schema-generator. The first is the crate published to crates.io. The schema directories hold generated JSON Schema artifacts, and the README states that when a schema release is published, the versioned .json files are attached to the corresponding schema-v* GitHub release, which it calls the recommended download surface for SDK generators and other release automation. Generation is driven from package.json. The scripts run the schema-generator crate directly through cargo, with feature flags selecting which schema variant is emitted, then run Prettier and cargo fmt over the result. The unstable and unstable_protocol_v2 features are what separate the v1 output from the v2 alpha output, and the full generate script runs all four combinations before formatting. That is the mechanism: Rust types in, JSON Schema out, formatting applied last. A detail worth noticing is that the generated schema is checked into the repository rather than produced only at release time. That makes schema diffs reviewable in pull requests, but it also means the checked-in files and the release attachments have to be kept in step by the release tooling. The repository carries a .release-plz.toml, which is consistent with automated release management, though the README does not describe the release process itself. ## Installing the schema crate and generating your first JSON Schema If you only need the Rust types, the crate is on crates.io under the name agent-client-protocol-schema. The workspace Cargo.toml pins it at version 1.7.0 as a path dependency, and that is the version consumers would request. ```toml [dependencies] agent-client-protocol-schema = "1.7.0" ``` If you are implementing a Rust agent or client rather than working with raw types, the README says to start with the higher-level agent-client-protocol runtime crate instead. The two are not interchangeable. To regenerate the schema artifacts yourself, the repository expects a Rust toolchain and Node with npm. The scripts in package.json call cargo run against the schema-generator package and then format the tree. ```bash npm run generate:json-schema npm run generate:json-schema:unstable ``` The first command emits the stable v1 schema. The second emits the unstable variant. Running the full generate script runs both of those plus the two v2 combinations and then applies Prettier and cargo fmt. After it finishes, the JSON files under schema/v1 and schema/v2 are rewritten in place, so a clean git status before you start is the simplest way to see what changed. The README does not document a rollback or a way to regenerate a single schema file in isolation. If you need one variant only, the individual scripts are the granularity available. ## Version numbers here do not tell you whether two peers can talk This is the part of the README most likely to be skimmed and most likely to cause a broken integration. Three version numbers are in play. The Rust crate version describes the crate. The schema release version describes the JSON Schema artifacts. The ACP protocol version describes the wire protocol, and the README states plainly that the current stable ACP protocol version is 1. Wire compatibility is determined separately, by the protocolVersion exchanged during initialize. The README also notes that the version field in the versioned schema/*/meta*.json files describes the ACP protocol version that the corresponding schema represents. The README gives a concrete example of why this matters: two versions of the JSON Schema artifacts can describe the same wire-compatible protocol version while differing in schema structure, for instance if definitions are reorganized, renamed, or emitted differently in a way that affects downstream code generation without changing the JSON messages exchanged. So a schema release bump can break your generator while leaving runtime messaging untouched, and a crate bump can do the same. The README's instruction is to use the negotiated protocolVersion for wire shape and breaking-compatibility level, the exchanged capabilities to decide which optional messages are supported, and artifact versions only to manage compatibility with this repository's Rust and schema outputs. If you take one operational rule from this repository, take that one: do not infer wire compatibility from the crate or schema release version alone. ## The v2 alpha line and what it means for a stable integration The release list includes schema-v2.0.0-alpha.3 alongside schema-v1.21.0 and the Rust crate at v1.7.0. The v2 schema is generated behind the unstable_protocol_v2 feature, and the v2-unstable script combines that with the unstable feature. An alpha schema line sitting next to a stable protocol version of 1 is a normal arrangement for a protocol project, but it creates a decision for anyone building against this repository. The v2 artifacts are being published, which means the schema structure is far enough along to generate from. They are alpha, which means the README makes no compatibility promise about them, and the negotiated protocolVersion is still the only thing that determines what two peers exchange. For a production integration the safe reading is: generate from schema/v1, negotiate protocolVersion during initialize, and treat the v2 artifacts as something to track rather than something to depend on. The repository does not state a timeline for v2 reaching stable, and the README does not describe a migration path from v1 to v2. ## Where ACP sits next to MCP and A2A The most common question about this project is how it relates to the Model Context Protocol. The distinction is in the two endpoints. MCP connects a model or an agent to tools and data sources; it answers what the agent can call. ACP connects an editor to an agent; it answers how the editor drives the agent and receives its output. A team can reasonably run both, with ACP on the editor-facing side and MCP behind the agent. A2A is a different axis again. It concerns agent-to-agent communication, where the participants are peers rather than an interactive editor and a program it launched. ACP's README frames the relationship as one interactive program controlling another, and the initialize exchange that carries protocolVersion and capabilities fits that framing. The honest limitation is that this repository does not contain a comparison document. The README links to an overview of agents and an overview of clients on agentclientprotocol.com, and the community libraries page, but the protocol-versus-protocol question is answered on the website rather than in the repository. If you are choosing between protocols, the repository itself will not settle it for you. ## Licence, contribution terms and the cost of tracking this repository The repository is Apache-2.0, and both the LICENSE file and the package.json license field agree. The contribution policy is deliberately lighter than many protocol projects: the README states that no Contributor License Agreement is required, and that contributions are accepted under Apache-2.0 with the contributor affirming they have the right to submit the work. That lowers the barrier for drive-by fixes, and it also means the project relies on the licence grant rather than a signed agreement for inbound contributions. Whether that suits your organisation's policy is a question for your own counsel, not something this article can answer. The upgrade cost is where this repository asks something unusual of you. Because the crate version, the schema release version and the protocol version move independently, a routine dependency bump is not automatically safe. A schema reorganization can change generated code without changing any message on the wire. Practically, that means regenerating from schema/v1 and diffing the output before accepting a schema release, and checking the negotiated protocolVersion rather than the changelog when something breaks at runtime. The repository does not document a deprecation window for old schema versions, so the diff is your safety net. Maintenance activity is visible: the last push was on 2026-08-20, the same date as the v1.7.0 crate release, the schema-v1.21.0 release and the v2 alpha. The repository is not archived. The README does not publish a support policy for older schema lines. ## What this repository will not do for you It will not give you a working editor integration. There is no runnable client here. The README points to agentclientprotocol.com for the agent and client overviews, and to separate repositories for the SDKs: acp-kotlin for Kotlin and the JVM, java-sdk, python-sdk, the Rust runtime crate with its agent.rs and client.rs examples, and the TypeScript package @agentclientprotocol/sdk. If your goal is to put an agent inside VS Code or Zed, you want one of those SDKs or an existing editor integration, not this schema crate. It will not give you a conformance suite either. Nothing in the repository describes a test harness that validates a client or agent against the protocol, so verifying that your implementation actually matches the schema is your own work. Generating types from the JSON Schema gets you structural correctness, not behavioural correctness. And it will not stay still. With a stable v1 schema, an active v2 alpha line, and four generation script variants, the artifact surface is broader than a single crate dependency suggests. If you cannot absorb periodic schema regeneration, this is the wrong layer to build on. ## Conclusion Adopt this repository if you are building an editor integration, an agent runtime, or an SDK generator that needs the ACP type surface, and you are prepared to treat the negotiated protocolVersion, not the crate version, as the compatibility boundary. Do not adopt it expecting a working client or agent: the runtime crate and the Kotlin, Java, Python, TypeScript and Rust SDKs live elsewhere. Before committing, verify which protocol version the peer you are integrating with negotiates during initialize, and check whether the JSON Schema you generate from schema/v1 matches the messages your peer actually exchanges. ## FAQ ### What is the Agent Client Protocol (ACP)? It is a protocol that standardizes communication between code editors and coding agents, where agents are programs that use generative AI to autonomously modify code. The README states that the current stable ACP protocol version is 1. ### What is ACP versus MCP? ACP connects an editor to a coding agent, while MCP is a separate protocol in the same ecosystem. The README does not compare the two; it links to agent and client overviews on agentclientprotocol.com instead. ### How does ACP work? Clients and agents exchange JSON-RPC messages, and wire compatibility is determined by the protocolVersion exchanged during initialize. Within a protocol version, the exchanged capabilities decide which optional messages and features are supported. ### Who created the Agent Client Protocol? The package.json in this repository lists Zed Industries as the author, and the project is licensed under Apache-2.0. ### What is agent client protocol versus model context protocol? The README does not draw the comparison. It describes ACP as standardizing communication between code editors and coding agents, and points to agentclientprotocol.com for the agent and client overviews. ### What is agent client protocol versus A2A? The README does not address A2A. It frames ACP as one interactive program, the editor, communicating with a coding agent, and leaves the protocol-versus-protocol question to the website. ## Sources - [Official documentation](https://agentclientprotocol.com) - [Official README](https://github.com/agentclientprotocol/agent-client-protocol#readme) - [Project repository](https://github.com/agentclientprotocol/agent-client-protocol) - [Release notes](https://github.com/agentclientprotocol/agent-client-protocol/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/agentclientprotocol-agent-client-protocol