
A202
io.github.a202-protocolPublished by GitHub account a202-protocolv0.1.0Updated Oct 24, 2026
Verifiable agreements for agent-led commerce: mandates, obligations, evidence, transaction records.
Overview
A202 MCP server for the A202 verifiable agreement protocol, covering commercial mandates, negotiation state and conformance checks for agent-led commerce.
- What you can do
- Work with the A202 commercial model: delegated authority, mandates, constraints, approval and revocation
- Model transactions and bilateral sessions, including negotiation state machines and auction event semantics
- Handle counterparty discovery and invitations for unregistered parties entering a named transaction
- Validate fixtures against the JSON schemas and apply invariants that schema validation cannot express
- Check that negative fixtures are refused for the declared reason codes
- When to use it
- Useful if you are implementing or testing the A202 specification and want an assistant to work with its schemas, fixtures and conformance results, or if you need agent-led commerce transactions modelled as mandates, obligations and evidence.
- Requirements
- Runs as a local process over stdio, distributed as an OCI image (ghcr.io/a202-protocol/a202-mcp:0.1.0), so a container runtime is needed. The conformance runner described in the README needs Python 3 with jsonschema 4.18 or later. No authentication, environment variables or headers are declared.
Installation
In SourceWeft
- Open A202 in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
A202: the Verifiable Agreement Protocol for Agent-Led Commerce
Status: Informative in full.
A202 is verifiable commerce for agent-to-agent or agent-led transactions: an open specification of commercial authority, negotiation state, and verifiable conformance for transactions between independent organisations, including transactions conducted on their behalf by software agents.
It defines typed objects for delegated commercial authority, a state machine for the transaction and for each bilateral session inside it, rules for what may be disclosed to whom, and an executable conformance suite that turns each of those into a check an implementation either passes or fails.
The full statement of purpose, scope, and non-goals is in CHARTER.md.
Created and developed by A. A. Musse. See MAINTAINERS.md.
Status
Released, pre-1.0.
v0.1.0is the first tagged release of the set: a tag, a digest for every schema file, the conformance manifest, and release notes, published together. See RELEASES.md and CHANGELOG.md. Before 1.0 a MINOR increment may break compatibility, and any break carries migration notes.- The name is A202, spoken "A two-oh-two", and in full A202, the Verifiable Agreement Protocol for Agent-Led Commerce. The long form is a descriptor and not an expansion: the letters do not stand for it. The
202is HTTP 202 Accepted, which A202-0017 makes the status an accepted submission returns, because acceptance is the primitive the rest of the specification is built on. TheA202-reason-code prefix, theA202-NNNNproposal identifiers, and thea202-commercial/0.1specification version string all follow from the name. - A202™ is a trademark of Plural Worlds. Permitted use of the name is stated in TRADEMARK.md.
- Schema
$idvalues resolve underhttps://schemas.a202.org. Fixture hosts use reserved.invalidnames, because test data must never resolve. - Licensed under the Apache License, Version 2.0. One licence covers the whole repository: specification text, schemas, fixtures, manifest, runner, and informative documents. The licence carries an express patent grant from each contributor. See LICENSE and CONTRIBUTING.md.
- External contributions are accepted on the terms in CONTRIBUTING.md: inbound contributions under the same licence, with a developer certificate of origin sign-off.
Layout
Each specification document carries a status header stating which of its sections are normative and which are informative.
Running the conformance suite
The runner validates every fixture named in the manifest against the schemas, then applies the invariants that JSON Schema cannot express. Schema validity is not conformance, which is the reason the runner exists.
It needs jsonschema>=4.18. If that is not on the system interpreter, a virtual environment is enough:
Run it from the repository root:
The expected result is every fixture passing and none failing, with the totals the manifest carries: the manifest is the single source for the count, and the runner prints it on every run. The runner also asserts that each negative fixture is refused for the reason code the manifest declares for it, wherever the normative layer raises codes at all. Run it before and after any schema change.
Every negative fixture is minimal: removing the single offending element must leave a document that validates cleanly. A negative fixture that fails for an incidental reason tests nothing, so verify that when adding one.
The suite does not depend on anyone remembering to run it. It runs, together with the reference implementation tests and the MCP server tests, on every pull request and on every push to the default branch, under .github/workflows/checks.yml. GOVERNANCE.md section 3.4 requires the suite to pass for any change to schemas, fixtures, the manifest, or the runner, and that workflow is what turns the requirement into a gate.
Where to start reading
- CHARTER.md for what this is and what it deliberately is not.
- schemas/canonical-commercial-model-v0.1.md for the object model, the envelope, and the invariants schema validation cannot express.
- negotiation/pilot-transaction-state-machine-v0.1.md for what moves state and what does not.
- conformance/manifest-v0.1.json for the fixtures that decide whether an implementation agrees with either of the above.
Source: README.md at commit 8473b04
Tools
0Version history
1- v0.1.0LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts