For A2A Developers

AgentCard with All Extensions

These protocols all use the standard A2A capabilities.extensions mechanism. An agent that supports all of them declares them in a single array:

{
  "name": "service-provider-agent",
  "version": "1.0",
  "capabilities": {
    "extensions": [
      {
        "uri": "https://ravikiran438.github.io/agent-consent-protocol/v1",
        "description": "ACAP: usage-policy consent and per-action adherence.",
        "required": true
      },
      {
        "uri": "https://ravikiran438.github.io/phala-protocol/v1",
        "description": "Phala: principal-declared welfare feedback.",
        "required": false
      },
      {
        "uri": "https://ravikiran438.github.io/pratyahara-nerve/v1",
        "description": "NERVE: behavioral integrity monitoring.",
        "required": true
      },
      {
        "uri": "https://ravikiran438.github.io/sauvidya-pace/v1",
        "description": "PACE: principal accessibility and capacity.",
        "required": true
      },
      {
        "uri": "https://ravikiran438.github.io/pramana-attestation/v1",
        "description": "Pramana: per-output ClaimAttestation with deterministic verification.",
        "required": false
      },
      {
        "uri": "https://ravikiran438.github.io/abhyasa-protocol/v1",
        "description": "Abhyasa: deliver-or-report custody transfer for governance obligations.",
        "required": false
      }
    ]
  }
}

Why some are `required: true`

Protocol	Default	Reason
ACAP	`true`	Callee wants callers to accept usage policy before invoking skills
Phala	`false`	Welfare feedback is advisory (BU-3: agents MAY ignore BeliefUpdates)
NERVE	`true`	Security layer: callee expects callers to participate in the trust envelope
PACE	`true`	Agents serving principals with registered PCPs MUST adapt interaction
Pramana	`false`	Verification artifacts are deployment-specific; regulated deployments (CFPB, NYDFS, §1557) set this to `true`, general-purpose deployments leave it advisory
Abhyasa	`false`	Delivery/custody layer; advisory unless the deployment relies on deliver-or-report for corrective obligations

Agents that support fewer protocols

An agent can declare any subset. A deployment that only needs consent:

{
  "capabilities": {
    "extensions": [
      {
        "uri": "https://ravikiran438.github.io/agent-consent-protocol/v1",
        "description": "ACAP: usage-policy consent and per-action adherence.",
        "required": true
      }
    ]
  }
}

Agents that do not understand an extension ignore the entry. No error, no failure, no negotiation. The extensions are additive.

Advertising Protocol Support in an MCP Handshake

For MCP tool servers whose agent supports one or more of these protocols, each protocol registers as a custom server capability in the serverCapabilities object during the initialize handshake, keyed by the same extension URI used on the A2A AgentCard:

{
  "serverCapabilities": {
    "tools": {},
    "https://ravikiran438.github.io/pratyahara-nerve/v1": {
      "neuron_type": "processing",
      "behavioral_fingerprint": "sha256:...",
      "trust_score": 0.88
    },
    "https://ravikiran438.github.io/sauvidya-pace/v1": {
      "supported_modalities": ["voice", "text"],
      "supported_languages": ["en", "te", "hi"]
    }
  }
}

MCP Reference Servers

Each protocol ships a reference Model Context Protocol server that exposes its validators as MCP tools. Most protocols ship a reference MCP server today (ACAP, Phala, NERVE, PACE, Abhyasa); a Pramana MCP server is planned. All shipped servers use stdio transport and work with any MCP-compatible client; the configuration below uses VSCode’s native MCP settings, and the same console script binds to any stdio-capable host. The pattern is identical across repos; each stays independently installable with no shared package.

Protocol	Console script	Tools exposed	Purpose
ACAP	`acap-mcp`	9	Core validators + one primary entry point per extension (governance tiering, category preferences, regulatory context, audit projection), plus `validate_usage_policy_ref` for AgentCard payload validation.
Phala	`phala-mcp`	12	Six Core validators (five primitives + BU-Privacy) plus five welfare_detectors extension validators: TypedBeliefUpdate structural check, WD-1 typed composition, WD-2 arbitration, WD-3 horizon, WD-4 provenance. Plus `validate_phala_service_ref` for AgentCard payload validation. BU-2 (per-agent uniqueness) and BU-4 (TTL expiry) are runtime-enforced and not exposed via MCP — they require state (a set of updates) or wall-clock time that an MCP tool boundary doesn’t naturally carry.
NERVE	`nerve-mcp`	13	Seven Core safety invariants (N-1, N-3, N-4, N-5, N-9, N-14, N-15) plus three Yathartha extension invariants (N-16, N-17, N-18) for capability-surface integrity. Plus three AgentCard / wire validators: `validate_neural_posture_ref`, `validate_nerve_envelope`, `validate_behavioral_fingerprint`.
PACE	`pace-mcp`	16	Seven Core validators: PCP structural check plus six named accessibility invariants (IM-1, IM-2, CCC-1, CCC-2, AIC-1, AIC-2). Plus four augmentation_profile extension validators (AUG-1 reversibility, AUG-3 identity, AUG-4 skill maintenance, AUG-5 emergency boundary). Plus five wire validators for the sibling-annotation surface: `validate_accessibility_service_ref`, `validate_active_challenge`, `validate_pace_consent_annotation`, `validate_pace_violation_notice`, `compute_ccc_trend`. AUG-2 is omitted because audit decomposition is enforced at type construction by the `Mediation` enum, leaving no separate runtime check to expose.
Abhyasa	`abhyasa-mcp`	6	Three structural validators (Obligation, CustodyAck, AbhyasaServiceRef), the AC-1 admissibility check, `safe(O)` computation, and a deliver-or-report custody-transfer simulation over a configurable lossy channel.

Install

Two paths depending on whether you are consuming or contributing.

For end users (no clone, ephemeral with uvx):

uvx --from 'acap[mcp] @ git+https://github.com/ravikiran438/agent-consent-protocol.git@v0.1.0' acap-mcp
uvx --from 'phala[mcp] @ git+https://github.com/ravikiran438/phala-protocol.git@v0.1.0' phala-mcp
uvx --from 'nerve[mcp] @ git+https://github.com/ravikiran438/pratyahara-nerve.git@v0.1.0' nerve-mcp
uvx --from 'pace[mcp] @ git+https://github.com/ravikiran438/sauvidya-pace.git@v0.1.0' pace-mcp

For end users (persistent, into an existing venv):

pip install 'acap[mcp] @ git+https://github.com/ravikiran438/agent-consent-protocol.git@v0.1.0'
# substitute phala/nerve/pace as needed

For contributors (clone + editable install):

git clone https://github.com/ravikiran438/agent-consent-protocol.git
cd agent-consent-protocol
pip install -e '.[mcp]'

Any of the three paths registers the appropriate <name>-mcp console script in the active Python environment.

VSCode MCP config

Add this to .vscode/mcp.json at your workspace root (or configure globally via your VSCode user settings, under the MCP section). Only include the servers you need.

Option A — uvx from git URLs (no persistent install required):

{
  "servers": {
    "acap": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "--from",
        "acap[mcp] @ git+https://github.com/ravikiran438/agent-consent-protocol.git@v0.1.0",
        "acap-mcp"
      ]
    },
    "phala": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "--from",
        "phala[mcp] @ git+https://github.com/ravikiran438/phala-protocol.git@v0.1.0",
        "phala-mcp"
      ]
    },
    "nerve": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "--from",
        "nerve[mcp] @ git+https://github.com/ravikiran438/pratyahara-nerve.git@v0.1.0",
        "nerve-mcp"
      ]
    },
    "pace": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "--from",
        "pace[mcp] @ git+https://github.com/ravikiran438/sauvidya-pace.git@v0.1.0",
        "pace-mcp"
      ]
    }
  }
}

Option B — absolute paths to pre-installed binaries:

{
  "servers": {
    "acap": {
      "type": "stdio",
      "command": "/absolute/path/to/agent-consent-protocol/.venv/bin/acap-mcp"
    },
    "phala": {
      "type": "stdio",
      "command": "/absolute/path/to/phala-protocol/.venv/bin/phala-mcp"
    },
    "nerve": {
      "type": "stdio",
      "command": "/absolute/path/to/pratyahara-nerve/.venv/bin/nerve-mcp"
    },
    "pace": {
      "type": "stdio",
      "command": "/absolute/path/to/sauvidya-pace/.venv/bin/pace-mcp"
    }
  }
}

Reload the workspace. The tools appear in any MCP-aware VSCode extension grouped by server name. Other MCP hosts accept the same console-script paths under their own configuration conventions.

Tool-naming convention

Every tool is named validate_<invariant> and takes a JSON payload of the primitive(s) it operates on. Output is a JSON object with {"ok": true, ...} on success or {"ok": false, "error": "..."} on invariant failure. A malformed input (not a structural invariant failure) surfaces as an MCP protocol error rather than an ok=false response.

See each server’s src/<package>/mcp_server/README.md for the full tool schema and per-tool examples.

Companion Repositories

Protocol	Package	Tests	TLA+
ACAP	agent-consent-protocol	128 (Core + 4 extensions + MCP)	Full state machine
Phala	phala-protocol	68 (Core + welfare_detectors + MCP)	Core skeleton + welfare_detectors spec
NERVE	pratyahara-nerve	94 (Core + Yathartha + MCP)	Full state machine (Core + Yathartha)
PACE	sauvidya-pace	96 (Core + augmentation_profile + MCP)	Full state machine + augmentation_profile spec
Pramana	pramana-attestation	84 (Core + claim-attestation extension)	Full lifecycle + claim-attestation spec

Total: 470 tests across the stack.

Papers

Protocol	DOI
Anumati / ACAP	arXiv:2604.16524
Phala	10.5281/zenodo.19625611
Pratyahara / NERVE	10.5281/zenodo.19628588
Sauvidya / PACE	10.5281/zenodo.19633138
Yathartha (NERVE extension)	10.5281/zenodo.19659632
Pramana	arXiv:2605.20312
Abhyasa	10.5281/zenodo.20644821