Loading ToolBench
MCP server for agentbond — AI agent authorization and governance
The server provides 17 well-structured authorization and governance tools with comprehensive schemas and descriptions. Most tools have explicit input schemas with typed parameters and clear descriptions (194 chars baseline met for many). However, several critical patterns are not fully implemented: output schemas are not documented, error handling guidance is minimal, and some parameter descriptions lack constraint details. Tool naming is strong and verb-driven. The domain is specialized (authorization/governance) and tools are appropriately scoped, but production readiness would benefit from explicit error recovery guidance and output schema documentation.
Create a new inter-agent contract in draft status. Requires exactly 2 parties (one principal, one executor). Conditions can include budget_cap, time_limit, approval_gate, or custom.
Evaluate an action against an authorization token and consume budget if allowed. Returns an AuthorizationDecision with allowed/denied status, reason code, and retryable flag.
Evaluate whether a contract is valid for operations. Checks that the contract is active and all conditions (time_limit, budget_cap) are met.
Evaluate intent policy for an action. Checks if an IntentRecord exists when requireReasoning is true. Records the result in the audit log with intentRef linkage based on auditLevel.
Get audit records for a specific action ID.
Get audit records for a specific token ID.
Query the audit log with optional filters (layer, outcome, time range, limit).
Output schemas are not documented in tool definitions. LLMs cannot plan downstream tool calls or understand what fields to expect. This violates the pattern:tool-composition and pattern:response-shaper patterns.
Error handling guidance is minimal. Tool descriptions state what happens but do not explain what to do if the operation fails (retryable vs. fatal, alternative paths). Missing pattern:recovery-guide guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 11 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 62 | 2025-03-26+ | v1 |
Retrieve a contract by ID.
Retrieve an intent record by ID.
Retrieve an intent record by action ID.
Retrieve an authorization token by ID.
Issue a new authorization token. If parentTokenId is provided, delegation constraints are validated (child scope/budget/expiry must not exceed parent).
Reactivate a suspended authorization token. Child tokens automatically become usable again.
Record an intent for an action — why the agent is performing this action. Evidence must be a summary (no raw logs). Required before action evaluation when the token has requireReasoning: true.
Permanently revoke an authorization token. All child tokens will be denied via cascade evaluation (their status is not changed).
Temporarily suspend an authorization token. Can be reactivated later. Child tokens are denied while parent is suspended.
Transition a contract's status. Only the principal can transition. Valid transitions: draft→active, active→completed, active→disputed, disputed→active, disputed→completed.
Simple getter tools (agentbond_get_token, agentbond_get_intent, agentbond_get_contract, agentbond_get_audit_by_*) have minimal descriptions (20-30 chars). They state WHAT but not WHEN to call, failing the pattern:tool-description guideline (descriptions should be 10-1024 chars with clear context).
No pagination parameters on agentbond_get_audit_log despite it being a list/query tool. Per pattern:paginated-result, tools returning lists should accept limit and offset/cursor, with total count or next_cursor in response. Current implementation only has 'limit' as optional.
Destructive operations (agentbond_revoke_token, agentbond_transition_contract to 'completed' or 'disputed') lack confirmation or dry-run support. Pattern:confirmation-request recommends agents have a safety mechanism before irreversible actions.
Parameter constraints in descriptions are sometimes vague. For example, 'maxLength': 1000 on evidence content and 'maxLength': 500 on reason are present in schemas but descriptions do not always restate them for LLM clarity.