Loading ToolBench
A Model Context Protocol server for AI agent consent management
Consent MCP has well-defined tool schemas with proper JSON Schema validation and clear naming conventions. All five tools start with action verbs (request_, check_, admin_simulate_) and have documented descriptions. However, descriptions lack depth and context for LLM selection. Parameter descriptions are present but minimal. Output schemas are not documented. Error handling is not evident in tool definitions. Security considerations around consent and data sensitivity are not explicitly addressed in tool descriptions.
[TEST ONLY] Simulate a consent response without real SMS/email. Use for testing workflows.
BLOCKING: Check if requester has active consent to contact target via email. Returns true ONLY if consent is GRANTED and not expired.
BLOCKING: Check if requester has active consent to contact target via SMS. Returns true ONLY if consent is GRANTED and not expired.
Request consent from a target via email. Sends an email to the target asking for permission.
Request consent from a target via SMS. Sends an SMS to the target phone number asking for permission.
Tool descriptions lack context on WHEN to use each tool and prerequisites. Descriptions are 40-90 characters, below the 50-200 char optimal range for LLM selection guidance.
Output schemas are not documented for any tool. LLMs cannot know what fields to expect (e.g., does check_consent_sms return {granted: bool, expiry: date} or {status: string}?). This blocks downstream tool composition and forces LLMs to guess.
No error handling guidance in tool descriptions. What happens if SMS/email delivery fails? Can the agent retry? Should it offer an alternative contact method? Undocumented error paths confuse agents.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | <=2025-11-25 | v2 |
| 2026-03-09 | C | 64 | - | v1 |
Security-sensitive operations (consent requests, response simulation) lack explicit permission/scope declarations in descriptions. Tools should state what permissions they require and what sensitive actions they perform.
admin_simulate_response description says '[TEST ONLY]' but does not document how agents should distinguish test vs. production mode or why they should avoid this tool in production. Developers may mistakenly invoke it in live scenarios.
Parameter 'expires_in_days' in request tools uses an integer with no documented bounds. Can this be 0? Negative? 10000? Should default to a sensible value (e.g., 30 days) to prevent misuse.
check_consent_sms and check_consent_email descriptions say 'BLOCKING' and 'Returns true ONLY if consent is GRANTED and not expired' but do not clarify: What does false mean? (consent denied, expired, or not yet requested?) This ambiguity forces LLMs to guess the semantics.
No enum constraints on 'scope' parameter. What are valid scopes? (marketing, support, billing, data-sharing?) Free-form strings invite hallucinated values and misuse.
admin_simulate_response 'response' parameter accepts YES, NO, or REVOKE but description does not explain what each means or the consequences (e.g., does REVOKE delete existing consent or mark it revoked?). Ambiguity blocks correct test workflows.