Loading ToolBench
Legal mandate chain for AI agents. MCP server for registering, verifying, and auditing agent mandates with cryptographic proof chains.
Five tools with complete input schemas and descriptions. Naming follows verb_noun pattern (create_mandate, verify_mandate, log_action, get_proof, issue_action_token). Descriptions are substantive (100-250 chars), explaining WHAT and WHEN. Parameters are well-typed with clear descriptions. However, output schemas are not documented, LLMs cannot predict response structure. Error handling guidance is minimal. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profiles (WRITE vs READ_ONLY). Missing pagination guidance for list-like operations.
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).
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.
Issue a signed action token IF AND ONLY IF a valid mandate authorizes it. This is the hard-stop enforcement layer: no valid mandate → no token → no action possible. Returns a JSON string with either {token, jti, expires_at, key_id} on success, or {denied: true, reason: '...', mandate_id: '...'} on denial.
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 and not expired.
Verify that an agent has a valid, active mandate to perform a specific action. Returns authorization status, mandate details, and expiration information.
Output schemas not documented. LLMs cannot predict response structure (mandate object fields, proof pack format, token response shape). Responses must include mandate_id, agent_id, and expiration for downstream tool chaining.
No tool annotations despite clear risk profiles. create_mandate, log_action, and issue_action_token are destructive/write operations; verify_mandate and get_proof are read-only. Missing destructiveHint and readOnlyHint annotations prevent agents from reasoning about side effects and retry safety.
Error handling lacks recovery guidance. Tools return success/failure but do not guide LLM on next steps. E.g., verify_mandate rejection should suggest 'Call create_mandate to establish authorization' or 'Check mandate expiration with get_proof'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Parameter 'metadata' in create_mandate accepts arbitrary object but lacks validation rules. Should specify max keys, key/value length limits, and allowed characters to prevent injection or oversized payloads.
No idempotency guarantees documented. create_mandate and log_action modify state; agents retrying on ambiguous failures risk duplicate mandates or action logs. Should declare idempotency or provide deduplication keys.