Loading ToolBench
Reference implementation for the Agentic Power of Attorney standard - a protocol for secure delegation and authorization of AI agents with JWT-based tokens, revocation, audit trails, and delegation chains
APOA is a cryptographic authorization library, not an MCP server. The 20 tools are Python SDK functions exposed as tool definitions, but lack proper MCP registration, structured schemas, and LLM-optimized descriptions. Most tools have generic or incomplete descriptions (many under 100 chars). Input schemas reference custom types (APOADefinition, SigningOptions, etc.) without inline JSON Schema definitions visible in the source. No error handling guidance, no output schemas documented, and no tool annotations (readOnlyHint/destructiveHint). The codebase shows TypeScript and Python SDKs but no MCP server implementation, this appears to be a library evaluation, not an MCP server.
One-stop authorization check: revocation + scope + constraints + rules. Enforcement order: 1. Check revocation, 2. Check scope, 3. Check constraints, 4. Check hard rules, 5. Check soft rules
Wrap an array of JWKs in the JWKS envelope
Revoke a parent token and all its child tokens in a delegation chain
Check a specific constraint on a service. Returns allowed=False if the constraint is explicitly set to false. Returns allowed=True if the constraint is not set or is truthy.
Check if a requested action is within the authorized scope set of a token
Create a KeyResolver backed by a remote JWKS endpoint. The resolver fetches the URL, caches the response, and returns the matching public key for a given kid claim.
No JSON Schema definitions visible for input parameters. All 20 tools reference custom types (APOADefinition, SigningOptions, ValidationOptions, etc.) without inline schema definitions. Cannot verify parameter types, constraints, or required fields.
No output schemas documented for any tool. LLMs cannot infer what fields to expect in responses, preventing downstream tool chaining and forcing agents to guess at response structure.
Tool descriptions are generic and under 100 characters for most tools (e.g., 'Check if a requested action is within the authorized scope set of a token'). Lack context on WHEN to use each tool vs similar alternatives (check_scope vs authorize vs check_constraint).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | 2026-07-28+ | v2 |
Create an APOA token from a definition and sign it with the provided private key
Create a delegated (attenuated) token from a parent token. Inherits principal from parent, enforces attenuation rules, and additional rules can only be added, not removed.
Generate a key pair for token signing. Returns (private_key, public_key).
Get the audit trail for a specific token
Get the audit trail for a service across all tokens
Get the list of ancestor token IDs from a delegation chain
Check if a token has been revoked
Log an action against a token to the audit store
Match a scope pattern against a requested scope using wildcard matching
Parse an APOA token definition from JSON or other format
Convert a public CryptoKey into a JWK. The kid is required so callers can match keys against the kid header on signed tokens.
Revoke a token by its ID, recording who revoked it and optionally why
Verify a JWT signature and return the decoded payload with validation result
Verify a full delegation chain. Checks structural integrity (attenuation, expiry, revocation, parent links) but does NOT verify cryptographic signatures.
No error handling guidance. Tools like 'validate_token' and 'authorize' do not document what errors they return, when they are retryable, or how to recover. No actionable error messages specified.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Destructive tools like 'revoke', 'cascade_revoke', and 'log_action' are not marked as such, preventing agents from understanding side effects and retry safety.