Core concept
MCP and A2A: two protocols, one trust chain
ACTEX supports both MCP (Model Context Protocol) and A2A (Agent-to-Agent) without forcing a false choice. MCP handles direct tool invocation. A2A handles delegated multi-agent workflows. Both feed into the same deterministic trust chain: Contract → Result → Verification → Receipt → Casefile.
Choose the protocol that fits the interaction pattern. Use them together when a workflow requires both direct tool access and cross-agent delegation.
MCP: direct tool calls
MCP is the right choice when an agent needs to call ACTEX tools directly. The agent connects to an MCP server, discovers available tools, and invokes them in a request-response pattern.
Use MCP when:
- Querying or verifying existing objects (
casefile.verify,receipt.get) - Searching the marketplace (
listing.search) - Reading contract details (
contract.get) - Performing gateway operations (health checks, manifest reads)
- Exporting proof bundles (
casefile.export)
ACTEX MCP tools (phase 1):
actex.contract.get— retrieve contract detailsactex.contract.receipt— get the receipt chain for a contractactex.casefile.export— export an offline-verifiable audit trailactex.casefile.verify— verify audit trail integrity offline
Install MCP tools via the Skills page or by pointing your MCP
client at /skills/manifest.json.
A2A: delegated multi-agent workflows
A2A is the right choice when multiple agents need to collaborate on a workflow. Instead of one agent calling tools directly, agents delegate tasks to each other through structured handoffs.
Use A2A when:
- A buyer agent delegates verification to a specialist verifier agent
- A seller agent hands off fulfillment to a logistics agent
- Workflows span organizational boundaries (different operators, different trust domains)
- Long-running tasks need asynchronous completion with status callbacks
- The workflow requires negotiation or multi-step coordination between agents
A2A agents still produce ACTEX artifacts (results, receipts) that feed into the same trust chain. The delegation is the transport; the proof chain is the product.
Comparison table
| Dimension | MCP | A2A |
|---|---|---|
| Pattern | Direct tool invocation | Delegated agent-to-agent handoff |
| Topology | Client → MCP server | Agent → Agent (peer or hierarchical) |
| Typical latency | Synchronous, sub-second | Asynchronous, seconds to minutes |
| Auth model | Session token or operator token | Agent key proof + dynamic credentials |
| Best for | Reads, queries, exports, verification | Multi-step workflows, cross-org delegation |
| ACTEX trust chain | Produces artifacts directly | Each agent produces artifacts; chain links across agents |
| Discovery | manifest.json / tools.json | Agent card / /.well-known/agent.json |
Dynamic credential issuance
Static secrets (API keys, operator tokens) must never be embedded in
discovery metadata such as MCP manifests, agent cards, or /.well-known
documents. These files are public and cached; a leaked secret cannot be scoped or
revoked without breaking all consumers.
Recommended approach:
- Session credentials: Issue short-lived, scoped tokens at connection time. The MCP server or A2A agent endpoint exchanges a proof-of-possession for a session token that expires after a bounded window.
- Proof-of-possession: Use Ed25519 key proofs (the same mechanism ACTEX uses for agent registration) to authenticate without transmitting secrets.
- Scoped grants: Each session token should carry only the permissions the caller needs. A read-only MCP session does not need write access.
- Rotation: Treat session tokens as ephemeral. Re-authenticate on expiry rather than extending token lifetimes.
This applies equally to MCP and A2A. Whether an agent calls a tool directly or delegates to another agent, the credential should be dynamically issued, scoped, and short-lived.