Loading ToolBench
A multi-server MCP repository containing Google OAuth, GitHub OAuth, and Bearer Token authentication implementations for room listing, task management, and location-based services
This server has severe definition quality issues across nearly all dimensions. It is a multi-module aggregation with 17 tools spread across TypeScript (Google OAuth, GitHub OAuth) and Python (bearer token, user ID) implementations. Tool naming lacks consistent verb-prefixing; descriptions are often generic or missing context; schemas are incomplete or absent for most tools; error handling is minimal; and no clear composition strategy guides tool interaction. The TypeScript modules register tools via agents/mcp McpAgent, while Python uses fastmcp. Most critically, parameter descriptions are sparse, output schemas are undocumented, and several tools duplicate functionality (4 'validate' tools with identical behavior). This architecture suggests a demo/prototype rather than production-grade tooling.
Adds a new room listing and returns a secret management key.
Create a new task for a specific user (by puch_user_id).
Mark a user's task as completed by ID.
Deletes a room listing using the room ID and secret management key.
Edits a room listing using the room ID and secret management key.
Generate an image using the `flux-1-schnell` model. Works best with 8 steps.
Shows a help menu with instructions and examples.
Four duplicate 'validate' tools with identical signatures and descriptions. These should be consolidated or removed. Duplicate tools confuse LLM routing and waste schema space.
Tool 'userInfoOctokit' does not follow verb_noun naming convention. Should be 'get_user_info' or 'get_github_user' for clarity and consistency with patterns like 'send_gmail' and 'add_room'.
Output schemas are completely undocumented across all tools. For example, 'send_gmail' and 'userInfoOctokit' return unstructured text/JSON without schema definition. LLMs cannot plan downstream tool calls without knowing response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Fetch a single task by its ID for a given user.
List a user's tasks with optional filters (status, tag, search).
Delete a user's task by ID.
Search for available room listings with optional filters for city, area, rent, gender preference, and amenities.
Send an email via Gmail using authenticated user's access token
Get user info from GitHub, via Octokit
Validated this mcp server to be used by PuchAI
Validated this mcp server to be used by PuchAI
Validated this mcp server to be used by PuchAI
Validated this mcp server to be used by PuchAI
Tool descriptions are generic and lack context for LLM selection. For example, 'validate' tools return only a phone number with description 'Validated this mcp server to be used by PuchAI', unclear what this validates or when to call it. Descriptions should be 10-1024 chars and explain WHAT, WHEN, and WHY.
Many parameter descriptions are minimal or missing semantic detail. E.g., 'add_room' has 'gender_pref' parameter with description '"Male"|"Female"|"Any"', this is an enum example, not a description. Should state 'Preferred gender for room matching: one of Male, Female, or Any.'
No explicit error handling or recovery guidance documented. Tools like 'send_gmail', 'delete_room', 'remove_task' are destructive/write operations but provide no guidance on failure modes, retry logic, or LLM next steps on error.
Tool composition is unclear. It is not documented which tools are prerequisites for others. For example, does 'add_room' require prior authentication? Do task tools depend on user lookup? The server lacks a conceptual flow.
Secrets may be exposed in responses. The 'add_room' tool returns a 'secret management key', if this is returned in plain text in logs/traces without explicit guidance to the LLM to treat it as sensitive, it risks leakage.
No pagination or result limits documented for list tools. 'list_tasks' and 'room_finder' accept optional filters but do not specify max result count, offset/cursor support, or total count in response. Large result sets can blow context window.
Tool parameters inconsistently accept natural identifiers. 'delete_room' requires 'room_id' (e.g., 'R015'), but the schema does not clarify if this can be resolved from name or only via ID lookup. Similarly, task tools require 'puch_user_id' but do not explain how to obtain it.