Loading ToolBench
A collection of MCP server implementations demonstrating Google OAuth, GitHub OAuth, and Bearer token authentication patterns with various utility tools
This server exhibits severe quality issues across naming, descriptions, and schema completeness. 17 tools are registered, but many share identical names (5 tools named 'validate', 3 named 'about'), creating ambiguity. Descriptions are present but often generic or trivial (e.g., 'Validated this mcp server to be used by PuchAI'). Parameter descriptions are minimal or absent in many cases. The Gmail tool (send_gmail) has decent input schema but lacks output documentation. Python tools (job_finder, make_img_black_and_white, task management suite) have better descriptions but still suffer from unclear error handling and missing recovery guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite clear risk classifications (WRITE, DESTRUCTIVE). Overall, this reads as a starter template with placeholder implementations rather than production-ready definitions.
Description about this mcp server
An Example Bearer token mcp server
Description about this mcp server
Create a new task for a specific user (by puch_user_id).
Mark a user's task as completed by ID.
Generate an image using the `flux-1-schnell` model. Works best with 8 steps.
Fetch a single task by its ID for a given user.
Tool name collision: 5 tools named 'validate' and 3 named 'about' across different implementations. LLMs cannot disambiguate which tool to call. These should have unique, descriptive names like 'validate_google_oauth', 'validate_github_oauth', 'about_gmail_service'.
Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite explicit Risk classifications in metadata. remove_task is marked DESTRUCTIVE but has no annotation to signal this to the agent. send_gmail is marked WRITE but lacks annotation.
Placeholder/generic descriptions for validate/about tools ('Validated this mcp server to be used by PuchAI'). These are under 50 characters and provide no actionable context. LLMs cannot determine when to call these tools or what they return.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 31 | - | v1 |
Smart job tool: analyze descriptions, fetch URLs, or search jobs based on free text.
List a user's tasks with optional filters (status, tag, search).
Convert an image to black and white and save it.
Delete a user's task by ID.
Send emails via Gmail API
Get user info from GitHub, via Octokit
Validate this MCP server
Validate this MCP server
Validated this mcp server to be used by PuchAI
Validated this mcp server to be used by PuchAI
Missing output schema documentation. No tool documents what it returns. LLMs need to know expected response fields for downstream composition. E.g., send_gmail, userInfoOctokit, generateImage lack explicit output schema declarations.
No error handling guidance. Tools like send_gmail, add_task, remove_task do not document error conditions or recovery paths. E.g., what happens if Gmail API fails? What does 'task creation failed' mean? LLMs need actionable error messages.
Parameter descriptions are minimal or missing context. E.g., job_finder 'user_goal' param lacks examples or constraints. make_img_black_and_white 'puch_image_data' description is under 50 chars and doesn't specify Base64 encoding requirement. list_tasks 'search' param lacks guidance on partial matching.
OAuth/authentication context is implicit and not documented in tool descriptions. Tools like send_gmail rely on 'this.props.accessToken' being populated by OAuth but do not state this as a prerequisite. If auth is missing, error message is vague ('No Google access token found'). No description guides the agent on what to do if auth fails.
Inconsistent parameter naming conventions. 'puch_user_id' and 'puch_image_data' use 'puch_' prefix (likely a custom domain identifier) but other tools use standard naming. This inconsistency signals custom/vendor-specific extensions without explanation.
No constraints on numeric parameters. generateImage 'steps' has min/max (4-8) which is good, but other tools lack bounds. job_finder lacks page/limit parameters for pagination control, risking context explosion.
Secrets in responses: if userInfoOctokit or other OAuth tools return authentication tokens or internal credentials in their responses, these will enter the LLM context and risk being logged or echoed to users.