Server data from the Official MCP Registry
Verifiable agreements for agent-led commerce: mandates, obligations, evidence, transaction records.
About
Verifiable agreements for agent-led commerce: mandates, obligations, evidence, transaction records.
Security Report
This is a well-structured MCP server for the A202 Verifiable Agreement Protocol with properly scoped permissions and good code quality. The server exposes commercial transaction validation and authority checking tools over HTTP APIs, with appropriate authentication mechanisms. No critical vulnerabilities were identified; findings are minor code quality issues and informational observations about design patterns. Supply chain analysis found 5 known vulnerabilities in dependencies (0 critical, 3 high severity).
3 files analyzed · 9 issues found
Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.
Permissions Required
This plugin requests these system permissions. Most are normal for its category.
How to Install
Add this to your MCP configuration file:
{
"mcpServers": {
"io-github-a202-protocol-a202-mcp": {
"args": [
"a202-mcp"
],
"command": "uvx"
}
}
}Documentation
View on GitHubFrom the project's GitHub 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
Pre-release.
- No release has been made. The contents are
v0.1working documents, not a tagged release of the set. See RELEASES.md. - 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
| Path | Contents |
|---|---|
CHARTER.md | Purpose, scope, non-goals, design principles |
GOVERNANCE.md | How the project is run, and what the sponsor does and does not control |
MAINTAINERS.md | Who maintains this repository |
CONTRIBUTING.md | Contribution status, and the terms a contribution is accepted under |
SECURITY.md | Private coordinated disclosure |
THREAT-MODEL.md | Adversaries assumed, properties defended, and what is deliberately not defended |
CODE_OF_CONDUCT.md | Expected conduct |
TRADEMARK.md | The A202 name, and what use of it is and is not permitted |
RELEASES.md | Versioning, what a release consists of, compatibility policy |
CHANGELOG.md | What changed, and where the release notes required by RELEASES.md accumulate |
.github/ | Review routing, the pull request and issue forms, and the workflow that runs the suite on every change |
proposals/ | The A202 change proposal process |
schemas/ | Canonical commercial model, transaction profile extension model, and the JSON schemas |
authority/ | Commercial mandate: delegated authority, constraints, delegation, approval, revocation |
discovery/ | Counterparty invitation: how an unregistered party enters one named transaction |
negotiation/ | Transaction and session state machines, and auction event semantics |
conformance/ | Fixtures, manifest, normative runner, and the conformance grade definitions |
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:
python3 -m venv .venv && .venv/bin/pip install "jsonschema>=4.18"
Run it from the repository root:
python3 conformance/run-conformance.py --verbose
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.
Reviews
No reviews yet
Be the first to review this server!
More Developer Tools MCP Servers
Git
Freeby Modelcontextprotocol · Developer Tools
Read, search, and manipulate Git repositories programmatically
Toleno
Freeby Toleno · Developer Tools
Toleno Network MCP Server — Manage your Toleno mining account with Claude AI using natural language.
mcp-creator-python
Freeby mcp-marketplace · Developer Tools
Create, build, and publish Python MCP servers to PyPI — conversationally.
MarkItDown
Freeby Microsoft · Content & Media
Convert files (PDF, Word, Excel, images, audio) to Markdown for LLM consumption
MCP Marketplace
Freeby mcp-marketplace · Developer Tools
Search and install MCP servers from inside your AI client.
FinAgent
Freeby mcp-marketplace · Finance
Free stock data and market news for any MCP-compatible AI assistant.