Loading ToolBench
A remote MCP server running on Cloudflare Workers that uses GitHub OAuth for authentication and provides tools for GitHub integration and AI-powered image generation
This server has 3 tools with significant quality gaps. Tool naming lacks consistency and clarity, 'add' is generic and does not follow verb_noun conventions; 'userInfoOctokit' mixes camelCase with a library name, reducing discoverability; 'generateImage' is clear but is the only well-named tool. Descriptions are present but severely under-specified: parameter descriptions are missing entirely for 'add' and 'userInfoOctokit', violating the pattern:tool-description rule that every parameter must be documented. The 'add' tool's description ('Add two numbers the way only MCP can') is vague marketing copy rather than actionable documentation. Schemas are defined via Zod but lack inline descriptions for most parameters, 'a' and 'b' in the 'add' tool have null descriptions in the parsed schema. The 'generateImage' tool is the strongest: it has proper constraints (min/max steps 4 - 8), per-parameter descriptions, and clear intent. Output schemas are not documented anywhere, LLMs cannot plan downstream calls. Error handling is absent: no guidance on what happens if GitHub API fails, what happens if image generation times out, or what the agent should do next. The server demonstrates basic MCP SDK usage but falls well short of production quality for agentic use.
Add two numbers the way only MCP can
Generate an image using the `flux-1-schnell` model. Works best with 8 steps.
Get user info from GitHub, via Octokit
Tool 'add' uses a generic verb with no object. Does not follow verb_noun naming convention. Name alone does not convey the specific action or domain. LLMs may confuse it with database additions, list appends, or configuration merges.
Tool 'userInfoOctokit' mixes camelCase with a library brand name, reducing clarity. Preferred naming: 'get_github_user' or 'fetch_authenticated_user'. Current name conflates the implementation detail (Octokit) with the intent (get user info).
Parameters 'a' and 'b' in 'add' tool have no descriptions (null in schema). LLMs cannot infer whether these are counts, offsets, IDs, or numeric values. Violates pattern:tool-description requirement that every parameter must be documented.
Tool 'userInfoOctokit' has no input parameters documented, yet it likely depends on context (the authenticated user's accessToken). The schema shows empty {} but no description of what it returns or what auth context is required.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 39 | - | v1 |
No output schemas documented for any tool. LLMs cannot plan downstream tool calls or extract the right data. For 'add', is the result an object with a 'sum' field or just the number? For 'userInfoOctokit', what fields are returned from the GitHub API? For 'generateImage', what URL or binary data format is returned?
No error handling or recovery guidance. What happens if GitHub API fails during userInfoOctokit? What if image generation times out? What should the agent do next? Current implementation has no try-catch or error messaging.
The 'add' tool description ('Add two numbers the way only MCP can') is marketing copy, not actionable documentation. Does not state WHAT it does, WHEN to use it, or WHAT it returns. Baseline for good descriptions is 50 - 200 chars of concrete detail.
No idempotency or side-effect documentation. 'generateImage' calls an external AI service and returns binary data. Is the call idempotent? Can it be safely retried if the LLM gets a timeout? No guidance provided.