Loading ToolBench
A remote MCP server that provides GitHub OAuth authentication and exposes MCP tools for authenticated users, including GitHub user info retrieval and conditional access to image generation.
This server has 3 tools with explicit definitions visible in src/index.ts. However, it exhibits significant quality gaps across naming, descriptions, and parameter documentation. The 'add' and 'userInfoOctokit' tools are demo/placeholder quality with minimal descriptions. The 'generateImage' tool has better parameter constraints but lacks critical context. Overall parameter descriptions are sparse or missing entirely. No output schemas are documented. Error handling guidance is absent.
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 names lack action verbs or are overly generic. 'add' is vague (add what? to what?). 'userInfoOctokit' exposes implementation detail ('Octokit'). Better names: 'add_numbers', 'get_github_user_info', 'generate_image' (already good).
Parameter descriptions are missing or trivial. 'add' tool parameters 'a' and 'b' have null descriptions in the schema. 'userInfoOctokit' takes no parameters but that's acceptable for a simple API fetch. 'generateImage' has good descriptions for 'prompt' and 'steps', but this is an outlier.
Tool descriptions are too short and lack context. 'add' = 'Add two numbers the way only MCP can' (39 chars), fails to explain what business problem this solves or when to call it. This appears to be a demo/placeholder tool. 'userInfoOctokit' = 'Get user info from GitHub, via Octokit' (38 chars), also minimal; does not explain what fields are returned or when to use it vs other GitHub tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
No output schemas documented. The code shows that tools return { content: [...] } with text or image types, but there is no formal schema defining the response structure for LLMs. LLMs cannot reason about downstream field mappings without knowing the output schema. All tools lack documented return types.
No error handling guidance. None of the tools document what errors can occur, what they mean, or what the LLM should do next. E.g., 'generateImage' may fail if the Cloudflare AI service is unavailable, but there is no recovery hint. E.g., if the GitHub token is invalid, 'userInfoOctokit' will fail silently from the LLM's perspective.
'add' and 'userInfoOctokit' appear to be demo/placeholder tools with no clear production use case. They do not follow the naming, description, or documentation baselines for real agent tools. Consider removing them or replacing with domain-specific tools.
The 'generateImage' tool has good parameter constraints (min/max on 'steps') but does not document rate limits, quota implications, or cost. If image generation is metered or expensive, agents need to know this to avoid runaway calls.
Parameter naming inconsistency. 'generateImage' uses 'prompt' and 'steps' (snake_case would be 'generation_steps' or 'step_count' for clarity). Minor issue but inconsistent with convention in the 'add' tool which uses 'a', 'b' (abbreviated).