AMR (Agent Mandate Registry) MCP

Create and register a new legal mandate authorizing an AI agent to act on behalf of a principal. A mandate defines the legal basis, scope, and duration of an agent's authorization. Each mandate is cryptographically linked to the previous one (SHA-256 chain). The optional structured perimeter (allowed_actions, forbidden_actions, delegation_allowed, max_delegation_depth, max_amount, period_max_amo

Verify whether an AI agent has a currently active and valid mandate to perform an action. Looks up the most recent active, non-expired, non-revoked mandate for the given agent. For a sub-mandate, every mandate above it must also be active, unrevoked and unexpired. Does NOT check the action against the scope: it returns the free-text scope and, when the mandate has one, its structured perimeter. T

Log an action performed by an AI agent under an active mandate for audit and compliance. Each action log entry is cryptographically linked to the previous action (SHA-256 chain), creating a tamper-evident audit trail. The mandate must be active, not revoked and not expired; for a sub-mandate, so must every mandate above it in the delegation chain (revoking or letting expire a parent stops the log

Generate a complete Proof Pack for a mandate, including all actions and chain integrity. The Proof Pack documents the full mandate chain for regulatory compliance (EU AI Act Art.26, eIDAS 2.0). It includes the mandate details, all logged actions, mandate events, and cryptographic chain integrity verification. Args: mandate_id: UUID of the mandate to generate a proof pack for.

Issue a signed action token IF AND ONLY IF a valid mandate authorizes it. This is the hard-stop: no valid mandate → no token → no action possible. When the mandate (or any mandate above it in a delegation chain) has a structured perimeter, the requested action_type must be allowed, must not be forbidden, and must respect the amount limit, at every level of the chain. A cumulative ceiling (period_

Re-check an action token with the registry at the moment of acting. For the receiver of an agent's action, typically before an irreversible one (a payment, a sent document, a signed order), and always when the token carries amr_registry_check: true. The signature only proves the action was authorized when the token was issued; this check also says whether it still is now. Checks, in order: heade

Register the Ed25519 public key of a principal, once. After registration, create_mandate refuses any mandate from this principal that is not signed with the matching private key. The key cannot be replaced or removed in this version. For an ordinary principal_id the registry does not check who registers it: the first registration wins. Expose this tool to principals (or their back office) only, n

Return the exact bytes a principal must sign to grant this mandate. Takes the same arguments as create_mandate. Nothing is written. The principal signs payload (UTF-8 bytes; payload_b64url is the same bytes) with its Ed25519 key, then calls create_mandate with the same arguments plus principal_signature and this signed_at. Any difference in the arguments makes the signature invalid. Args: si

Return the mandate as a PDF for the principal to sign with its own signature tool. Takes the same arguments as create_mandate (and prepare_mandate_signature). Nothing is written. The PDF shows the mandate and carries, as the attached file amr-mandate.json, the exact bytes prepare_mandate_signature returns for the same arguments and signed_at; the SHA-256 of these bytes is printed on every page. T

Check a PAdES signature of the mandate PDF and record who the certificate names. The principal signs the PDF of prepare_mandate_pdf with its own tool (for example with a qualified certificate) and anyone passes the signed file here, after create_mandate. The registry checks, offline: the file starts with the exact mandate PDF and its attached content is this mandate (for a mandate the principal s

Issue a signed attestation of a mandate, for the agent to show a third party. The receiver (a seller, a hospital, an insurer) verifies it offline with the registry's public key (see get_registry_public_key and amr.verify_attestation), without an account and without calling the registry. It states that the mandate exists, who granted it, the agent, the scope and structured perimeter, the expiry, t

Return the registry's public key, for third parties who verify attestations. A receiver fetches it once, through a channel it trusts, and compares key_id with the one the registry operator publishes. It then verifies attestations offline. Returns: JSON string with keys: issuer, key_id, algorithm ("EdDSA"), public_key_pem, public_key_jwk ({kty "OKP", crv "Ed25519", x, kid, alg}). On e

Takes no parameters.

Export a signed insurer dossier for a mandate over a period. The dossier puts in one signed document what an insurer or an auditor asks about an AI agent: who granted the mandate, its perimeter (allowed and forbidden action types, right to delegate, amount limit), whether it is in force or cut (status, expiry, broken delegation chain), its sub-mandates, the status events, actions and action token

Revoke a mandate now. Final: a revoked mandate cannot be reactivated. Only the mandate's own principal revokes it (for a sub-mandate, that is the agent that delegated it). If the principal has a registered key, the revocation must carry its signature: build the bytes with prepare_revocation_signature, sign them, and pass principal_signature and signed_at. With AMR_REQUIRE_PRINCIPAL_SIGNATURE, eve

Return the exact bytes a principal must sign to revoke one of its mandates. Nothing is written. The principal signs payload (UTF-8 bytes; payload_b64url is the same bytes) with its Ed25519 key, then calls revoke_mandate with the same mandate_id and reason plus principal_signature and this signed_at. Args: mandate_id: UUID of the mandate to revoke. reason: Why it is revoked, as it will be

Record that a principal contests an action an agent already performed. Use it when an act logged with log_action was not wanted: the registry keeps a dated, chained record that the act was disputed, and when, so silence is not the only trace. One contest per action; it cannot be withdrawn or edited. The contesting principal is the mandate's principal (default) or the principal of any mandate abo

Return the exact bytes a principal must sign to contest a logged action. Nothing is written. The principal signs payload (UTF-8 bytes; payload_b64url is the same bytes) with its Ed25519 key, then calls contest_action with the same arguments plus principal_signature and this signed_at. Args: mandate_id: UUID of the mandate the action was logged under. action_id: action_id returned by log_

List contested actions with the days left before their respond_by (the reminder). Read-only. Give mandate_id, contested_by, or both. Call it on a schedule (for example each morning) to see which contests reach their response deadline soon. The deadline is the operator's own (response_days of contest_action), not a legal deadline computed by AMR. Args: mandate_id: Only the contests under this

Report a problem with AMR itself (a bug, a confusing error, a missing feature). Write only what you observed: the tool name, what you sent, what came back. Never paste real mandate contents, personal data, keys or tokens: nothing from the registry is attached; PEM blocks, JWS-shaped tokens, GitHub tokens and bare Ed25519 private keys are refused, other secrets are not detected. Without AMR_ISSUE