What can you do with this server?

The AGA-mcp-server is a cryptographic governance and compliance enforcement platform for autonomous AI agents, implementing the Attested Governance Artifact (AGA) protocol. It acts as a zero-trust policy enforcement point, providing tamper-evident attestation, behavioral monitoring, and signed auditing. Policy Enforcement & Attestation * Intercepts MCP client tool calls, evaluates them against sealed policies (allowlist, denylist, audit_only; permissive/standard/restrictive profiles), and produces Ed25519-signed receipts * Creates sealed Policy Artifacts, measures subject state against sealed references, verifies artifact signatures, and supports mid-session revocation with TERMINATED or SAFE_STATE transitions Behavioral Monitoring & Drift Detection * Define baselines (permitted tools, rate limits, forbidden sequences) and detect behavioral drift via continuous or on-demand measurement Tamper-Evident Auditing & Chain Management * Bootstrap a continuity chain with a genesis event, log all events (behavioral, delegations, receipts, revocations, attestations), and retrieve/verify chain history Evidence Bundles & Offline Verification * Export verifiable evidence bundles (artifact + receipts + Merkle proofs) and perform 4-step offline bundle verification Identity, Access & Key Management * Manage Ed25519 keys with pinned issuer keys, TTL re-attestation, and auditable key rotation * Set verification tiers (BRONZE, SILVER, GOLD) and delegate constrained policies to sub-agents (scope only diminishes, never escalates) Privacy & Disclosure * Privacy-preserving claim disclosure with auto-substitution (PROOF_ONLY, REVEAL_MIN, REVEAL_FULL modes) Developer & Diagnostics Tools * Full lifecycle demo tool (attest → measure → drift → revoke → bundle → verify) for scenarios like drone or SCADA * Server info, portal state inspection, and quarantine/forensic capture status * 3 resources (protocol spec, sample bundle, crypto primitives) and 3 prompts for demos/reports The server uses a two-process boundary where the proxy holds signing keys (the client holds none), ensuring fail-closed enforcement and covering all 12 CoSAI MCP security threat categories.

de en es ja ko ru zh

AGA-mcp-server

by attestedintelligence

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

The AGA-mcp-server is a cryptographic governance and compliance enforcement platform for autonomous AI agents, implementing the Attested Governance Artifact (AGA) protocol. It acts as a zero-trust policy enforcement point, providing tamper-evident attestation, behavioral monitoring, and signed auditing.

Policy Enforcement & Attestation

Intercepts MCP client tool calls, evaluates them against sealed policies (allowlist, denylist, audit_only; permissive/standard/restrictive profiles), and produces Ed25519-signed receipts
Creates sealed Policy Artifacts, measures subject state against sealed references, verifies artifact signatures, and supports mid-session revocation with TERMINATED or SAFE_STATE transitions

Behavioral Monitoring & Drift Detection

Define baselines (permitted tools, rate limits, forbidden sequences) and detect behavioral drift via continuous or on-demand measurement

Tamper-Evident Auditing & Chain Management

Bootstrap a continuity chain with a genesis event, log all events (behavioral, delegations, receipts, revocations, attestations), and retrieve/verify chain history

Evidence Bundles & Offline Verification

Export verifiable evidence bundles (artifact + receipts + Merkle proofs) and perform 4-step offline bundle verification

Identity, Access & Key Management

Manage Ed25519 keys with pinned issuer keys, TTL re-attestation, and auditable key rotation
Set verification tiers (BRONZE, SILVER, GOLD) and delegate constrained policies to sub-agents (scope only diminishes, never escalates)

Privacy & Disclosure

Privacy-preserving claim disclosure with auto-substitution (PROOF_ONLY, REVEAL_MIN, REVEAL_FULL modes)

Developer & Diagnostics Tools

Full lifecycle demo tool (attest → measure → drift → revoke → bundle → verify) for scenarios like drone or SCADA
Server info, portal state inspection, and quarantine/forensic capture status
3 resources (protocol spec, sample bundle, crypto primitives) and 3 prompts for demos/reports

The server uses a two-process boundary where the proxy holds signing keys (the client holds none), ensuring fail-closed enforcement and covering all 12 CoSAI MCP security threat categories.

AGA - Attested Governance Artifacts

Cryptographic runtime governance for AI agents and autonomous systems.

npm PyPI License: MIT npm provenance

Status: published to npm; this release carries SLSA build provenance (check it: npm audit signatures). The server tools and the aga-proxy emit the canonical SEP evidence bundle, verifiable offline by the published @attested-intelligence/aga-verify and the reference verifier aga-receipt-spec/verify/verify-sep.mjs. Since 3.2.0 the verifier is algorithm-agile and ships a post-quantum profile: v1 Ed25519-SHA256-JCS (the default the gateway emits) and v2 ML-DSA-65+Ed25519-SHA256-JCS (a NIST FIPS-204 ML-DSA-65 + RFC-8032 Ed25519 composite, both must verify), selected per-bundle by the algorithm field with a VERIFIED / FAILED / UNSUPPORTED_PROFILE trichotomy. Pre-3.0 releases (a legacy continuity-chain bundle that does not verify under the SEP verifier) are deprecated; use ^3.0.0. Claim scope and residual attack surface are documented honestly in THREAT_BOUNDARY.md.

# This package IS the AGA MCP server (TypeScript, runs over stdio). Use it from any MCP client:
npx -y @attested-intelligence/aga-mcp-server

A Python companion SDK (aga-governance) is documented in the Python SDK section below.

Verify this yourself (don't take our word)

You do not have to take any of this on faith. The repo ships the reference verifier, the canonical vectors, and sample bundles, so you can check one offline right now, with no network and no callback to us:

git clone https://github.com/attestedintelligence/aga-mcp-server
cd aga-mcp-server
# A canonical SEP bundle verifies; a one-byte-tampered copy is rejected.
node aga-receipt-spec/verify/verify-sep.mjs fixtures/valid_minimal.json   # OVERALL: VERIFIED (integrity only; no key pinned)
node aga-receipt-spec/verify/verify-sep.mjs fixtures/tampered.json        # OVERALL: FAILED

The published @attested-intelligence/aga-verify CLI renders the identical verdict, and npm run conformance:cross-stack (first: npm run build && npm --prefix independent-verifier run build) proves six v1 verifier configurations — spanning three independent toolchains (JavaScript, Go, and Python, including a pure-stdlib, no-third-party-crypto path) — agree on the 54 object-level cases, and the five file-parsing verifiers agree on the 7 raw-byte/file-parse cases (61 total). The in-server engine is library-only, receiving parsed objects rather than raw file bytes, so it does not run the file-parse cases; six configurations do not agree on all 61 and this no longer claims they do. npm run conformance:cross-stack-v2 proves two genuinely independent-language oracles (@noble/JS and CIRCL/Go) agree on the v2 composite corpus. For a full trust-free reproduction (build the package yourself, reproduce the published tarball byte-for-byte, re-run every gate), see the REVIEWER_GUIDE.md (a command-by-command self-service path), REPRODUCIBILITY.md, and the step-by-step SKEPTICAL_AUDITOR.md. This release carries SLSA build provenance, checkable with npm audit signatures.

Related MCP server: Proofpane

What This Does

Every tool call an AI agent makes passes through the AGA gateway. Each call is evaluated against policy, and the decision (PERMITTED or DENIED) is recorded as a signed, hash-linked governance receipt. Receipts are collected into evidence bundles that any third party can verify offline using standard cryptography.

Record. Prove. Verify.

Scope: a verified bundle proves the integrity of the receipts present: each is authentic, correctly ordered, Merkle-included, and (when a key is pinned) provenance-bound. It does not prove non-omission (that every action the agent took was logged); completeness is bounded by the tamper-evidence of the interception point, which is outside the bundle. See KNOWN_LIMITATIONS.md for the full honest boundary, and THREAT_BOUNDARY.md for the per-field detail.

Use with Claude Desktop

Add to your Claude Desktop MCP config (claude_desktop_config.json):

{
  "mcpServers": {
    "aga": {
      "command": "npx",
      "args": ["-y", "@attested-intelligence/aga-mcp-server"]
    }
  }
}

Claude can then seal artifacts, measure integrity, generate evidence bundles, and verify compliance through natural language.

Persist the signing key (do this first)

By default the gateway signs with an ephemeral key that rotates on every restart. That is fine for a first look, but evidence-bundle provenance cannot be pinned across restarts (and the server warns about it on stderr). Set one stable 64-hex Ed25519 seed so provenance stays pinnable:

# generate a seed once (32 random bytes, hex)
node -e "console.log(require('node:crypto').randomBytes(32).toString('hex'))"

Provide it via AGA_GATEWAY_KEY, or AGA_GATEWAY_KEY_FILE (a path to the seed). In Claude Desktop, add an env block:

{
  "mcpServers": {
    "aga": {
      "command": "npx",
      "args": ["-y", "@attested-intelligence/aga-mcp-server"],
      "env": { "AGA_GATEWAY_KEY": "<your-64-hex-seed>" }
    }
  }
}

Keep the seed secret and out of version control; see DEPLOYMENT.md for key handling.

MCP Tools (15)

Category	Tools
Identity	`get_server_info`, `get_portal_state`
Lifecycle	`init_chain`, `attest_subject`, `revoke_artifact`
Measurement & decision	`measure_integrity`, `measure_behavior`, `verify_chain`
Evidence	`generate_evidence_bundle`, `verify_bundle_offline`
Privacy	`request_claim`, `list_claims`
Delegation	`delegate_to_subagent`
Audit	`get_receipts`, `get_chain_events`

measure_behavior is detective-only by default: it observes tool-usage patterns and records a signed, provable drift finding, but does not block. Enforcement (drift → quarantine) is opt-in via enforce=true and off by default. Hard governance decisions (PERMITTED/DENIED) are made by the portal/PEP, not the behavioral monitor.

Quick Start: verify a bundle offline

A bundle this package emits (via the generate_evidence_bundle MCP tool) is a canonical SEP bundle. Verify it offline, with no network and no callback to us:

# Published verifier CLI — ships on npm, nothing to clone. Pin the gateway key (from get_server_info) to prove provenance.
npx -y @attested-intelligence/aga-verify evidence-bundle.json --pubkey <gateway-public-key>

# Or, from a clone of this repo, the zero-dep reference verifier (Node 18+) renders the identical verdict:
node aga-receipt-spec/verify/verify-sep.mjs evidence-bundle.json --pubkey <gateway-public-key>

The published @attested-intelligence/aga-verify CLI is the shipped path (the older forgeable 1.0.0 is deprecated); the reference verify-sep.mjs renders the identical verdict from a repo clone. Without --pubkey you get an integrity-only result (issuerVerified=false); pin the key to also prove who issued it. See THREAT_BOUNDARY.md §3.7. A hosted browser verifier is linked under Links.

The reference §6 algorithm is implemented in three languages: JavaScript (aga-receipt-spec/verify/verify-sep.mjs), Go (verify.go, stdlib crypto/ed25519), and Python (verify.py, pure-stdlib RFC-8032 Ed25519). A cross-stack harness (npm run conformance:cross-stack; first: npm run build && npm --prefix independent-verifier run build) proves all three, plus the in-server engine and aga-verify, render identical verdicts on the canonical vectors (valid, adversarial, and every small-order forgery). The v2 composite profile (ML-DSA-65+Ed25519-SHA256-JCS) is held to the same bar by a second harness (npm run conformance:cross-stack-v2): a @noble/JavaScript engine and a CIRCL/Go oracle, two genuinely independent toolchains, render identical verdicts on the pinned v2 corpus, and the reference v1 verifier (verify-sep.mjs/verify.py/verify.go) returns UNSUPPORTED_PROFILE (exit 3) on a v2 bundle, signalling "profile not implemented" rather than a misleading "invalid". (The published aga-verify CLI does not implement this profile trichotomy: on a v2 bundle it returns FAILED (exit 1). Use exit 3 as the unsupported-profile signal only with the reference verifiers.)

Check-name mapping across implementations

The JS reference verifier and the Python SDK (aga-governance) decompose the same seven-check verification differently. Overall verdicts and exit codes agree on every conformance-corpus case (re-proven 2026-07-01: 10/10 cells across pristine/tampered bundles with unpinned, correct, and wrong keys); the sub-check that reports a given tamper can differ:

JS reference check	Python result field	What it covers
`structural`	`algorithm_valid` + parts of `bundle_consistent`	algorithm id, key well-formedness, receipt/proof counts
`receipt_signatures`	`receipt_signatures_valid`	Ed25519 over canonical receipt bytes
`chain_and_ordering`	`chain_integrity_valid`	prev-leaf linkage, monotonic ids and timestamps
`merkle_and_bijection`	`merkle_proofs_valid`	leaf recompute, single-root walk, index bijection
`signed_checkpoint`	`checkpoint_valid`	gateway-signed root + count + chain-head binding
`envelope_consistency`	`envelope_consistent`	envelope metadata vs signed content
`gateway_key_match` (with `--pubkey`)	`gateway_key_match` / `provenance`	pinned issuer key

Known decomposition difference: the JS reference recomputes every Merkle leaf from full receipt content, so a receipt-signature tamper also fails merkle_and_bijection; the Python verifier surfaces the same tamper in receipt_signatures_valid, chain_integrity_valid, and bundle_consistent while its merkle_proofs_valid can remain true. Neither is looser: the bundle fails in both stacks, exit 1. One input-handling difference is deliberate: a malformed --pubkey pin is a usage error (exit 2) in the Python SDK, while the JS reference treats a malformed pin as unpinned; the Python behavior is strictly tighter.

How It Works

AI Agent                  AGA Gateway                    Verifier
   |                          |                              |
   |-- tools/call ----------->|                              |
   |                    [Evaluate Policy]                    |
   |                    [Sign Receipt]                       |
   |                    [Chain to Previous]                  |
   |<-- PERMITTED/DENIED -----|                              |
   |                          |                              |
   |                    [Export Bundle]                       |
   |                          |--------- evidence.json ----->|
   |                          |                  [Verify Signatures]
   |                          |                  [Verify Chain + Order]
   |                          |                  [Verify Merkle Tree]
   |                          |                  [Verify Signed Checkpoint]
   |                          |                  [PASS / FAIL]

MCP Governance Proxy

Run AGA as a transparent proxy between any MCP client and any MCP server. Every tool call gets evaluated against policy and produces a signed receipt.

# Start the proxy (the `aga-proxy` bin) in front of an upstream MCP server.
# stdio upstream = the hardened default (the upstream is a child process, not network-reachable).
npx -p @attested-intelligence/aga-mcp-server aga-proxy start \
  --upstream "npx -y @modelcontextprotocol/server-filesystem /tmp/test" --profile standard

Exporting the evidence bundle from a running proxy

The proxy records receipts in its own process and keeps the SEP ledger in memory. To make that live ledger reachable from a separate shell, aga-proxy start opens a loopback-only control channel — an HTTP listener bound to 127.0.0.1 (never a routable interface), on its own port (default 18801, override with --control-port), distinct from the agent-facing proxy port (18800). It exposes only read routes (/export, /status, /receipts); nothing on it mutates policy or state, and it is unreachable off-host by construction (the loopback bind is the guarantee). The proxy writes the chosen control port to ~/.aga-proxy/control.json alongside proxy.pid.

A separate aga-proxy export invocation reads that file and fetches the same signed bundle the running proxy would emit:

# Terminal A — start the proxy in front of an upstream MCP server
npx -p @attested-intelligence/aga-mcp-server aga-proxy start \
  --upstream "npx -y @modelcontextprotocol/server-filesystem /tmp/test" --profile standard

# Terminal B — export the live ledger from a different shell, then verify it offline
npx -p @attested-intelligence/aga-mcp-server aga-proxy export -o evidence.json
npx -y @attested-intelligence/aga-verify evidence.json --pubkey <gateway-public-key>

If no proxy is running, aga-proxy export prints no running proxy found; start it first, or export from within the session and exits non-zero — it never emits an empty or placeholder bundle. Within the MCP server session you can also call the generate_evidence_bundle tool and save the returned JSON.

In-memory ledger: the exported bundle is the durable cryptographic record, but the live in-process chain does not survive a proxy restart. This flow makes the live ledger reachable from another process; it does not add cross-restart persistence, which needs the persistent (SQLite) backend and remains roadmap (see KNOWN_LIMITATIONS.md).

The proxy intercepts tools/call requests, evaluates them against a sealed policy, and generates a signed SEP receipt for every decision. Permitted calls are forwarded to the downstream server; denied calls return an MCP error and never reach it. Every decision is hash-linked and checkpoint-bound into a tamper-evident bundle. (Methods other than tools/call aren't policy-evaluated, but non-benign ones are recorded as signed passthrough receipts for auditability, and an optional denylist can reject them; see THREAT_BOUNDARY.md §3.2.)

Three built-in policy profiles:

permissive - log everything, block nothing (default)
standard - rate limits + blocks destructive operations
restrictive - explicit tool allowlist, all unknown tools denied

Because the default (permissive) is audit-only, starting with an audit_only policy prints a loud stderr banner stating that every call is permitted and recorded and no call is denied in that mode — denial happens only under an allowlist-mode policy (standard, restrictive, or a custom --policy file). An unrecognized --profile value is a hard error (exit 2 listing the valid names), never a silent fallback to permissive.

Verification (canonical SEP 3.0; normative §6 algorithm in `aga-receipt-spec/verify/verify-sep.mjs`)

Structural floor - Bundle declares Ed25519-SHA256-JCS, public key well-formed (all small-order encodings + non-canonical y ≥ p rejected), receipts.length > 0, proof count = receipt count
Receipt Signatures - Ed25519 over JCS-profile canonical JSON, sorted-key (signature field excluded)
Chain + ordering - Each receipt's previous_receipt_hash = leaf of the preceding receipt; non-decreasing timestamps
Merkle Proofs - Recompute every leaf from receipt content, walk siblings/directions to one root, leaf indices form the complete 0..N-1 bijection
Signed checkpoint - Verify the gateway-signed checkpoint binding merkle_root, leaf_count, and chain head (this makes the no-prefix construction truncation-safe)
Provenance (when a key is pinned) - public_key == expected key; otherwise integrity-only is reported

Cryptographic Primitives

Primitive	Purpose
Ed25519	Receipt signatures
SHA-256	Hash chaining, Merkle trees, leaf computation
JCS-profile (sorted-key canonical JSON)	Deterministic signing (canon is byte-compatible with the reference verifier)
Merkle Trees	Binding all receipts to a single verifiable root

Live Gateway

A demo gateway is deployed on Cloudflare Workers (a separate deployment that may track its own version; treat it as a convenience mirror, and always verify what it returns offline against a pinned key, not as the canonical artifact):

# Check status
curl https://aga-mcp-gateway.attested-intelligence.workers.dev/health

# Export evidence bundle
curl https://aga-mcp-gateway.attested-intelligence.workers.dev/bundle -o evidence-bundle.json

Python SDK

pip install aga-governance

from aga import AgentSession

with AgentSession(gateway_id="my-gateway") as session:
    session.record_tool_call(
        tool_name="search_web",
        decision="PERMITTED",
        reason="tool in allowlist",
        request_id="req-1",
    )
    bundle = session.export_bundle()
    result = session.verify()
    assert result["overall_valid"]

Test Suite

Automated tests across TypeScript and Python, plus a conformance corpus:

TypeScript MCP server: 384 automated tests (vitest), including provable-denial and behavioral-monitor regressions
SEP conformance corpus: npm run test:conformance (valid → VERIFIED, negatives → FAILED)
Python companion SDK: the separately-published aga-governance PyPI package (install + smoke-checked here; its full pytest suite runs from the source tree)

npm test                              # TypeScript tests (vitest)
npm run test:conformance              # SEP conformance corpus
pip install aga-governance && python -c "import aga; print(aga.__version__)"   # Python SDK smoke check

Benchmarks

Receipt-format determinism is reproducible here: npm test runs the cross-language vectors, and npm run conformance:cross-stack (first: npm run build && npm --prefix independent-verifier run build) shows the six v1 verifier configurations (across three independent toolchains: JS, Go, Python) agree on the 54 object-level cases of the canonical 61-case corpus — the remaining 7 are raw-byte/file-parse cases run by the five file-parsing verifiers, since the in-server engine never receives raw bytes — while npm run conformance:cross-stack-v2 shows the two independent-language v2 oracles agree on the composite corpus.

Project Structure

src/
  sep/                 # Canonical SEP evidence engine: single source of truth (canon, merkle, receipt, checkpoint, bundle, verify)
  core/                # Governance primitives (portal, artifact, attestation, disclosure, delegation, behavioral) + internal continuity-chain profile
  crypto/              # Internal continuity-chain crypto: Ed25519 (node:crypto), SHA-256/blake2b, salt
  proxy/               # MCP governance proxy (transparent interception + policy enforcement; emits SEP bundles)
  middleware/          # Governance PEP wrapper (records a signed PERMITTED/DENIED receipt per governed call)
independent-verifier/  # @attested-intelligence/aga-verify: standalone SEP verifier, zero AGA imports
scenarios/             # Demo scenarios (SCADA, autonomous vehicle, AI agent) that emit SEP bundles
tests/                 # TypeScript test suite (384 automated tests)

Security

See SECURITY.md for vulnerability reporting.

Contributing

See CONTRIBUTING.md for development setup and guidelines.

License

MIT

Attested Intelligence Holdings LLC

Available Tools

15 tools

attest_subjectC

Attest subject, generate sealed Policy Artifact. Auto-loads into portal.

ParametersJSON Schema

Name	Required	Description
`evidence_items`	No
`subject_content`	Yes	Content/bytes of the subject
`subject_metadata`	Yes
`behavioral_baseline`	No

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description only indicates that it generates and auto-loads an artifact. It does not disclose whether the operation is destructive, idempotent, requires authorization, or has side effects beyond loading into the portal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two short sentences. It front-loads the core action and provides an important side effect (auto-loading) without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters, nested objects, and no output schema, the description is too sparse. It does not explain return values, the format of the sealed artifact, or how parameters like evidence_items and behavioral_baseline contribute to the attestation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not mention any parameters, despite schema description coverage being only 25%. It fails to explain the purpose or usage of subject_content, subject_metadata, evidence_items, or behavioral_baseline, leaving a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool attests a subject and generates a sealed Policy Artifact, with auto-loading into a portal. However, it does not distinguish from sibling tools like generate_evidence_bundle or request_claim, which could have overlapping purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, use cases, or scenarios where other tools would be more appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delegate_to_subagentB

Derive a constrained policy artifact for a sub-agent. Scope can only diminish, never expand. (NCCoE constrained delegation)

ParametersJSON Schema

Name	Required	Description
`measurement_types`	Yes	Subset of parent measurement types
`delegation_purpose`	Yes	Purpose of the delegation
`enforcement_triggers`	Yes	Subset of parent enforcement triggers
`requested_ttl_seconds`	Yes	Requested TTL (will be clamped to parent remaining)

TDQS

B3.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It discloses the key behavioral trait of non-expanding scope, but lacks details on permissions, side effects, or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, concise and to the point, with no wasted words. However, it could benefit from slightly more structure or context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 required parameters, no output schema, and no annotations, the description is too minimal. It lacks details on return values, prerequisites, or how this fits with siblings, leaving an agent with insufficient information for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and each parameter is described in the schema. The description adds no additional meaning beyond the general purpose of constrained delegation, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool derives a constrained policy artifact for a sub-agent, with specific scope restrictions. It uses domain-specific terminology (NCCoE constrained delegation) but is not contrasted with siblings like request_claim or attest_subject.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The constraints 'Scope can only diminish, never expand' provide some usage context, but there is no explicit guidance on when to use this tool versus alternatives, nor when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_evidence_bundleA

Export the canonical SEP evidence bundle: signed PERMITTED/DENIED tool-call receipts + Merkle proofs + a mandatory signed checkpoint, for offline third-party verification (verify_bundle_offline, aga-verify, or aga-receipt-spec/verify/verify-sep.mjs). Pin gateway_public_key to prove provenance.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description bears full burden. It discloses the output components (receipts, proofs, checkpoint) and purpose (offline verification). However, it does not mention potential side effects, authentication, or whether it is read-only (likely safe).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences that front-load the main action. It contains no fluff, though it could be slightly more structured (e.g., bullet list) for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no parameters and no output schema, the description provides a comprehensive overview of what the bundle contains and how it is used. Minor gaps: no mention of prerequisites (like needing a chain) or the bundle's size/format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, and schema coverage is 100%. The description adds value by explaining what the tool outputs and its purpose, which is more than the schema provides. Baseline for 0 parameters is 4, and the description meets it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Export' and the resource 'canonical SEP evidence bundle', detailing its content (signed receipts, Merkle proofs, signed checkpoint). It distinguishes from the sibling 'verify_bundle_offline' by specifying this is for generation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the use case: 'for offline third-party verification'. Mentions verification methods (verify_bundle_offline, etc.) and a key prerequisite (pin gateway_public_key). Does not include when-not-to-use or alternative tools beyond verify_bundle_offline.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_chain_eventsC

Get continuity chain events.

ParametersJSON Schema

Name	Required	Description	Default
`end_seq`	No
`start_seq`	No

TDQS

C2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden of behavioral disclosure. It does not mention side effects, authorization requirements, rate limits, or any constraints beyond the name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

At only four words, the description is underspecified rather than concisely informative. It fails to provide necessary details that would make it useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, no annotations, and no parameter descriptions, the description leaves the agent with minimal understanding of tool behavior, inputs, or outputs. It is insufficient for the given complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 0% parameter description coverage, and the description does not explain the meaning, format, or use of 'start_seq' and 'end_seq'. The agent remains uninformed about these parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states it retrieves 'continuity chain events', identifying a specific resource and action. However, it lacks clarity on what these events represent, and does not distinguish it from sibling tools like 'get_portal_state' or 'get_server_info'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description provides no context about scenarios or prerequisites for invoking it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_portal_stateA

Get current portal state, loaded artifact info, and enforcement status.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description must disclose behavioral traits. It only names what is retrieved, but does not mention side effects, permissions, or whether it is read-only. This is insufficient for a no-annotation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no wasted words. Every part contributes to understanding the tool's output.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so description should explain return structure. It names major components but lacks detail on format or fields. Given low complexity (no params, no annotations), it is minimally adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters in schema, so baseline is 4. Description adds meaning by specifying what the tool returns, going beyond the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states what is retrieved: 'current portal state, loaded artifact info, and enforcement status'. Verb and resource are specific and distinct from siblings like get_server_info or get_chain_events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., get_server_info). No context about prerequisites or typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_receiptsC

Get all signed receipts, optionally filtered by artifact.

ParametersJSON Schema

Name	Required	Description	Default
`artifact_hash`	No

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It states 'Get' implying read-only, but does not explicitly confirm no side effects, idempotency, or permission requirements. It does not disclose behavior for missing artifact_hash or large result sets.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, concise but lacks structure. It could be improved by separating purpose and usage details. It earns its place but does not excel in providing organized information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description is incomplete. It omits return format, pagination, error handling, and behavior for missing parameters. For a tool with one optional param, it is borderline but still leaves significant questions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds minimal meaning: 'optionally filtered by artifact' links the parameter artifact_hash to filtering but does not explain the format or valid values. This is insufficient for a parameter with no schema description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves all signed receipts with optional filtering by artifact. The verb 'Get' and resource 'signed receipts' are specific. Sibling tools like list_claims or get_chain_events are distinct, so no confusion arises.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusions. For example, it does not clarify if this tool is preferred over list_claims for certain cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_server_infoA

Get AGA server info, public keys, and portal state.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It does not disclose whether the operation is safe, requires authentication, or has any side effects. For a read-only tool, minimal behavioral disclosure is given.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded and concise with no waste. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although the description mentions the types of information retrieved (server info, public keys, portal state), it does not describe the output structure or format. With no output schema, the description should provide more detail on what the response contains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, and the description does not need to add parameter meaning. Schema coverage is 100% trivially. Baseline for 0 parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves AGA server info, public keys, and portal state. It uses a specific verb 'Get' and distinguishes from sibling tools like get_portal_state, which is more specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. Given siblings like get_portal_state and other info tools, the description should include context on when to prefer this over others.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

init_chainC

Initialize continuity chain with genesis event.

ParametersJSON Schema

Name	Required	Description	Default
`specification_hash`	No

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It only says 'initialize' and 'genesis event', but does not mention side effects, idempotency, error conditions, or required permissions. Falls short for a mutating operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise at 5 words, but at the expense of critical information. It is front-loaded but does not earn its place as it omits parameter details and usage guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one parameter, no output schema, and no annotations, the description is incomplete. It lacks explanation of the parameter's meaning, return value, and overall behavior, making it insufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'specification_hash' has no description in the schema and is not mentioned in the description. The agent has no way to understand its purpose or format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Initialize' and the resource 'continuity chain' with 'genesis event', which differentiates it from sibling tools like verify_chain. However, the term 'continuity chain' is not explained, assuming domain knowledge.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like get_chain_events or verify_chain. No prerequisites, exclusions, or contextual conditions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_claimsA

List available claims with sensitivity levels.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only states that the tool lists claims with sensitivity levels, but does not disclose side effects (likely none), authorization needs, or data freshness. For a tool with no parameters, the behavior is simple, but more transparency could help.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that conveys the essential information without any fluff. It is front-loaded and efficient, earning its place with precise wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters or output schema, the description is sufficient for a simple list operation. It tells the agent what the tool provides (claims with sensitivity levels). However, it could mention if the list is complete or filtered in any way, but overall it is adequately complete for its simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters and 100% schema description coverage. The description adds no parameter information, but since none exist, this is appropriate. The baseline is 4 for no parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: listing available claims with sensitivity levels. It uses a specific verb ('list') and resource ('claims'), and adds detail about sensitivity levels, distinguishing it from siblings like 'request_claim' or 'verify_bundle_offline' which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. For example, it does not explain how 'list_claims' differs from 'get_receipts' or other listing operations. No context about prerequisites or ideal scenarios is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

measure_behaviorA

Measure behavioral patterns (unauthorized tools, rate violations, forbidden sequences). DETECTIVE-ONLY by default: it records and PROVES drift but does not block. Pass enforce=true to also trip the portal into phantom quarantine on drift (opt-in; off by default). (NIST-2025-0035)

ParametersJSON Schema

Name	Required	Description	Default
`enforce`	No

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the detective-only default, that it records and proves drift but does not block, and that enforce=true triggers phantom quarantine. It could elaborate on what 'phantom quarantine' entails, but it's sufficiently transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with purpose and followed by details on default behavior and enforce option. Every sentence adds value with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter and no output schema, the description covers purpose, default behavior, and the enforce option. It does not describe the output or what triggers measurement, but it is fairly complete given the context. A brief mention of output would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides only the parameter name and type with 0% coverage. The description adds valuable meaning: it explains that enforce (boolean, default false) opts in to phantom quarantine on drift. This fully compensates for the schema's lack of description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool measures behavioral patterns (unauthorized tools, rate violations, forbidden sequences) and distinguishes itself from sibling tools by highlighting 'DETECTIVE-ONLY' default behavior and an optional enforce parameter for quarantine.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool (for detecting behavioral drift) and how to opt into enforcement via enforce=true. It does not explicitly state when not to use it or compare to siblings like measure_integrity, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

measure_integrityB

Measure subject state, compare to sealed reference. Generates signed receipt for every measurement.

ParametersJSON Schema

Name	Required	Description	Default
`subject_content`	Yes	Current content of the subject
`subject_metadata`	Yes

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden for behavioral disclosure. It mentions receipt generation but does not disclose side effects, permission requirements, or what happens on mismatch. The comparison to a sealed reference is implied but not detailed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no redundancy, front-loaded with the core action. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having two parameters (one nested) and no output schema, the description is too brief. It omits the source of the sealed reference, return format, and any prerequisites, leaving significant gaps for an agent to successfully invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only 50% of parameters have schema descriptions; the description adds no parameter-level details. Subject_content is described in schema; subject_metadata lacks description in both schema and tool description. The description does not clarify their roles beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: measuring subject state and comparing to a sealed reference, and generating signed receipts. It uses specific verbs and resources, distinguishing it from sibling tools like 'attest_subject' and 'measure_behavior'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It only states the function without contextual usage advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

request_claimC

Request disclosure of a claim. Auto-substitutes if denied.

ParametersJSON Schema

Name	Required	Default
`mode`	No	REVEAL_MIN
`claim_id`	Yes
`requester_id`	No	anonymous

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden for behavioral disclosure. It mentions 'Auto-substitutes if denied', which is a key behavior, but fails to explain what 'substitutes' means, whether it's destructive, or any other side effects. No mention of permissions or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise (two sentences), but it lacks structure and essential information. While it is not verbose, the conciseness comes at the cost of completeness. Every sentence should earn its place, but here they are insufficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain the return value, the meaning of disclosure modes, or the auto-substitution behavior in detail. The tool is for a potentially complex operation, but the description leaves many gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description adds no parameter explanations. It doesn't mention claim_id, mode, or requester_id. The mode enum (PROOF_ONLY, REVEAL_MIN, REVEAL_FULL) is not described. The description fails entirely to add meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Request disclosure of a claim.' The verb 'request disclosure' and resource 'claim' are specific. It also mentions auto-substitution on denial, adding context. However, it doesn't differentiate from siblings like 'list_claims', but the purpose is distinct enough.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, scenarios, or exclusions. The tool is for requesting claim disclosure, but no context on when to choose this over other claim-related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

revoke_artifactA

Revoke an active policy artifact mid-session. Portal terminates on next measurement. (NCCoE Phase 3b)

ParametersJSON Schema

Name	Required	Description	Default
`reason`	Yes	Reason for revocation
`sealed_hash`	Yes	Sealed hash of artifact to revoke

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description partially carries the burden. It discloses the termination effect on next measurement, but does not detail permissions, side effects on other artifacts, or confirmation mechanics. It adds value but leaves gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero waste. Every word contributes to understanding purpose and key behavior. Efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is minimal but covers the primary action and a notable behavioral effect. However, given no output schema and potential complexity around revocation, more detail (e.g., what happens to the session, how to confirm success) would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions for both parameters ('sealed_hash', 'reason'). The tool description does not add any additional meaning beyond what the schema already provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the action 'Revoke' on the resource 'active policy artifact', adds context 'mid-session', and notes a specific effect 'Portal terminates on next measurement'. This distinguishes it from sibling tools like 'attest_subject' or 'delegate_to_subagent'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context ('mid-session') but no explicit guidance on when to use this tool versus alternatives (e.g., when not to use, or which sibling to choose instead). It lacks exclusion criteria or comparative hints.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_bundle_offlineA

Verify a canonical SEP evidence bundle offline (full §6 algorithm: structural floor, receipt signatures, chain+ordering, leaf-recompute + Merkle bijection, signed checkpoint). Pass pinned_public_key to also prove provenance.

ParametersJSON Schema

Name	Required	Description	Default
`bundle`	No
`pinned_public_key`	No

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description details the verification algorithm: structural floor, receipt signatures, chain+ordering, leaf-recompute + Merkle bijection, signed checkpoint. This fully discloses the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first describes purpose and algorithm, second adds optional parameter. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the algorithm well and parameter use, but lacks output specification (return value) and prerequisites. For a complex verification tool, this is a notable gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has zero description coverage. The description explains pinned_public_key for provenance but does not elaborate on the bundle parameter's structure or constraints, leaving a gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool verifies a canonical SEP evidence bundle offline, listing specific algorithm steps from §6. It distinguishes from sibling tools like verify_chain by focusing on bundle verification.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when offline bundle verification is needed and mentions optional provenance via pinned_public_key. It does not explicitly state when not to use, but context with siblings is implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_chainC

Verify continuity chain integrity.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.6/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, and the description does not disclose behavioral traits. It does not state whether the tool performs a read or mutation, what it returns, or any side effects, leaving the agent with no insight into the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise (one sentence). However, it sacrifices informativeness for brevity; it could provide more detail without being verbose. It is not tautological but minimally sufficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (no parameters, no output schema), the description still fails to explain what 'verify' entails, what the output indicates, or how it relates to sibling tools like verify_bundle_offline. It is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so schema coverage is trivially 100%. The description adds no parameter information, but baseline for zero parameters is 4. No further meaning is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Verify' and resource 'continuity chain integrity', making the general purpose clear. However, it does not differentiate from sibling tools like verify_bundle_offline or get_chain_events, which limits clarity in context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description lacks any context about prerequisites, intended use cases, or when to avoid it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool has a unique purpose with no overlapping functionality. For example, measure_behavior and measure_integrity measure different aspects, and verify_chain vs. get_chain_events are distinct operations. The descriptions clearly differentiate them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., attest_subject, delegate_to_subagent, verify_chain). There is no mixing of conventions or irregular naming.

Tool Count5/5

With 15 tools, the server is well-scoped for its attestation and policy domain. Each tool earns its place, covering setup, measurement, verification, and revocation without being excessively numerous.

Completeness5/5

The tool surface appears complete for the server's purpose, covering artifact creation, delegation, evidence export, chain initialization, state querying, claims handling, behavioral and integrity measurement, revocation, and offline verification. No obvious gaps in the core workflow.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

AxioRank: Zero-Trust for AI Agents A
com.axiorank
Zero-trust gateway for AI agents: score tool calls, verify agent cards, enforce policy, audit.
Security Observability
222
AccordTrace A
io.github.Kosta1985
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Security AI & Machine Learning
41
HiveAttest A
io.github.srotzin
Pre-action attestation perimeter for AI agents — 8 primitives, signed C18 receipt per call.
Security Autonomous Agents
182
governance-platform A
ai.geodesiclabs
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
AI & Machine Learning Testing & QA Tools Monitoring
373

Related MCP Servers

agent-sudo-mcp
Security Autonomous Agents
Kisyntra
A
license
A
quality
A
maintenance
Local zero-trust permission gateway for AI agents. Enforces policy-based tool authorization, human approvals, scoped permissions, and cryptographically verifiable audit logs.
Updated 25 days ago (2026-08-10 11:23 UTC)
4
5
Apache 2.0
Proofpaneofficial
Security Shell Access Command Line
Proofpane
A
license
B
quality
A
maintenance
A governance proxy for AI tools — every MCP/agent tool call is policy-gated, secret-redacted, and written to a hash-chained, offline-verifiable audit trail.
Updated 23 days ago (2026-08-12 10:41 UTC)
13
MIT
contextboundary-gw
Security Developer Tools
kannanokannan
A
license
Not graded
quality
B
maintenance
Self-hosted MCP gateway that applies deterministic, compiled policy to tool discovery, invocation, and outbound data flow, with no model in the enforcement path. Every decision emits a hash-chained receipt sealed with Ed25519 and verifiable using public keys only.
Updated 2 days ago (2026-09-01 23:54 UTC)
Apache 2.0
evav-gatewayofficial
Security Agent Orchestration
evavai
A
license
Not graded
quality
B
maintenance
Governed MCP gateway that lets AI agents call tools with policy enforcement, prompt-injection screening, a kill-switch, and tamper-evident signed audit logs.
Updated a month ago (2026-07-31 19:09 UTC)
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/attestedintelligence/aga-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

AGA - Attested Governance Artifacts

Verify this yourself (don't take our word)

What This Does

Use with Claude Desktop

Persist the signing key (do this first)

MCP Tools (15)

Quick Start: verify a bundle offline

Check-name mapping across implementations

How It Works

MCP Governance Proxy

Exporting the evidence bundle from a running proxy

Verification (canonical SEP 3.0; normative §6 algorithm in aga-receipt-spec/verify/verify-sep.mjs)

Cryptographic Primitives

Live Gateway

Python SDK

Test Suite

Benchmarks

Project Structure

Links

Security

Contributing

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Proofpaneofficial

evav-gatewayofficial

Latest Blog Posts

MCP directory API

Verification (canonical SEP 3.0; normative §6 algorithm in `aga-receipt-spec/verify/verify-sep.mjs`)