Loading ToolBench
A governance proxy for MCP servers: per-tool allowlist, human approval for write-class tools, quotas, secret redaction, and a hash-chained audit log.
mcpclerk exposes 6 test tools with minimal descriptions (10-20 chars each) and trivial parameter documentation. All tools lack actionable guidance for LLM selection. Schemas are present but descriptions fall far below the 50-200 char baseline for A+ tools. No error recovery guidance, no output schema documentation, and no distinction between safe and destructive operations in descriptions. This is a governance proxy, not a production tool suite, the test tools are intentionally minimal.
Always fails.
Delete a thing.
Return the text.
Read a thing.
Return the payload verbatim.
Write a thing.
All tool descriptions are under 20 characters ('Return the text.', 'Read a thing.', etc.), violating the 50-200 char baseline. LLMs cannot distinguish when to use read_thing vs secret_sink or understand prerequisites.
No parameter descriptions beyond type names. 'path' and 'text' parameters lack context on format, constraints, or examples. LLMs cannot infer whether 'path' is a file path, URL, or resource ID.
Destructive operations (delete_thing, write_thing) lack confirmation or dry-run support. No error recovery guidance. Descriptions do not warn of irreversible consequences.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | 2026-07-28+ | v2 |
No output schema documentation. Callers cannot predict response structure (e.g., does read_thing return {content: string} or {data: string, metadata: {...}}?). Breaks tool chaining.
Tool 'boom' is designed to fail but provides no actionable error message or recovery guidance. LLMs cannot learn what went wrong or how to proceed.