Loading ToolBench
MCP server for OpenTerms — cryptographic consent receipts + policy engine + provider verification for AI agents.
OpenTerms MCP server has well-structured tool definitions with complete input schemas and clear descriptions for most tools. All 10 tools are explicitly registered with proper JSON Schema. Naming follows verb_noun convention (issue_, verify_, check_, get_, list_, simulate_, policy_). However, output schemas are not documented, LLMs cannot predict response structure for downstream chaining. Parameter descriptions are present but some lack detail on constraints (e.g., 'terms_hash' says '64 hex chars' but no validation guidance). Error handling is mentioned in issue_receipt description ('POLICY_DENIED', 'POLICY_ESCALATION_REQUIRED') but no recovery guidance provided. Security concern: API_KEY and PROVIDER_KEY are environment variables (good), but no mention of rate limiting or permission gates. Tool composition is sound, each tool has single responsibility. Average tool description length ~150 chars (within 10-1024 baseline). No critical naming conflicts.
Check workspace USDC balance (minor units, 1 USDC = 1,000,000).
Get the active policy (guardrails) for this workspace. Returns the rules that govern what this agent is allowed to do. An agent SHOULD call this on startup to understand its constraints.
Get current per-receipt pricing. Public — no API key needed.
Issue a cryptographically signed terms receipt BEFORE your agent takes an action. Returns an Ed25519-signed receipt proving consent to terms. If this returns POLICY_DENIED or POLICY_ESCALATION_REQUIRED, STOP and notify the user.
List recent receipts for this workspace.
View recent policy evaluation decisions (allow/deny/escalate) for this workspace. Useful for auditing and understanding what the policy engine has been doing.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination) for downstream tool chaining. E.g., does list_receipts return {receipts: [], total: int, next_cursor: string}? Unknown.
Parameter constraints lack detail. 'terms_hash' says '64 hex chars' but no validation guidance. 'limit' parameters lack min/max bounds (e.g., 'max 50' stated for list_receipts but not for policy_decisions). LLMs may pass invalid values.
Error handling lacks recovery guidance. issue_receipt mentions 'POLICY_DENIED' and 'POLICY_ESCALATION_REQUIRED' but does not explain what the agent should do next. No actionable error messages documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
View receipt activity against your terms URL (requires provider API key via OPENTERMS_PROVIDER_KEY). Shows stats, unique agents, and recent receipts for your API.
Test whether a hypothetical action would be allowed by the current policy WITHOUT actually issuing a receipt. Use this to pre-check before acting.
Verify a receipt's cryptographic integrity. Public — no API key needed.
Verify a receipt by its canonical hash. Public — no API key needed. Use this to check if an agent has a valid consent receipt before serving a request. Returns receipt details and cryptographic verification result.
No permission gates or scope declarations. Tools like provider_activity require OPENTERMS_PROVIDER_KEY but no tool-level permission check or scope metadata (e.g., 'read:provider', 'write:receipt'). Audit trail not documented.
Descriptions for simple tools (check_balance, get_pricing) are minimal (~60 chars). No guidance on WHEN to call them or what they enable. E.g., 'Check workspace USDC balance' does not explain why an agent would call this before issue_receipt.