Loading ToolBench
A proof-of-concept MCP server running on Cloudflare Workers with Durable Object support
Two tools with minimal descriptions (both under 100 chars) and basic parameter schemas. sayHello has a single string param with description; getDurableObject similarly minimal. No output schemas documented. No error handling guidance. No parameter constraints (enums, ranges). Descriptions lack context on WHEN to use these tools or what they return. Tool names are verb-noun but lack specificity (sayHello is generic; getDurableObject is vague about what 'stub' means to an LLM). No evidence of idempotency, pagination, or composition patterns. This is a proof-of-concept server with skeleton definitions.
Get the Durable Object stub for a given ID.
A warm, friendly greeting from your new Workers MCP server.
No output schemas documented. LLMs cannot infer what fields to expect from tool responses, blocking downstream composition and chaining.
Descriptions are too brief (35 - 50 chars) and lack context. 'A warm, friendly greeting' does not explain WHEN to call sayHello or what it returns. 'Get the Durable Object stub' does not explain what a stub is or how to use it.
Tool names lack specificity. 'sayHello' is generic and does not convey that it is a greeting utility. 'getDurableObject' is vague, does it create, retrieve, or initialize? LLMs cannot disambiguate without reading descriptions.
No error handling guidance. If getDurableObject fails (invalid ID, missing env), the response provides no recovery hint. Agents cannot self-correct.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 36 | 2026-07-28+ | v2 |
Parameter 'id' in getDurableObject lacks format constraints. Is it a UUID, alphanumeric string, or arbitrary? No enum, pattern, or length limit. LLMs will guess.