Loading ToolBench
Model Context Protocol (MCP) server integrating Geekbot data and tools to Claude AI
Geekbot MCP has reasonable tool coverage with 6 well-named tools, but suffers from significant gaps in parameter descriptions, incomplete schemas, and minimal error handling guidance. Naming conventions are strong (all tools start with action verbs: list_, fetch_, post_). Tool descriptions exist but are verbose and lack clear prerequisites/dependencies. Parameter descriptions are sparse, most parameters (e.g., in fetch_reports: 'after', 'before') lack format examples or validation constraints. The post_report tool's schema is the most complete (required fields, nested object structure), but others like list_members and list_standups have empty input schemas with no descriptions. Output schemas are not documented anywhere in the code, making it impossible for LLMs to anticipate response structure. Error handling is absent, no guidance on retryability, user-fixable errors, or recovery steps. Security: API key is injected via Settings (good), but no mention of permission gates or audit logging.
Retrieves Geekbot poll results. Use this tool to analyze poll results or track progress of polls. This tool is usually used after the `list_polls` tool to get the poll id.
Retrieves Geekbot standup reports. Use this tool to analyze team updates or updates from specific colleagues, track progress, or compile summaries of standup activities. This tool is usually used after the `list_standups` tool.
Lists all team members participating in the standups and polls of the user. Use this tool to get information about the colleagues of the user
Retrieves and displays all Geekbot polls a user has access to, including their complete configuration details such as name, time, timezone, questions, participants, recurrence, anonymous, and creator.
Retrieves and displays all Geekbot standups a user has access to, including their complete configuration details such as name, channel, questions, participants, and schedule information. Use this tool to understand the structure of the team and the processes they use track progress and sync.
Empty input schemas for 4 of 6 tools (list_members, list_standups, list_polls, and fetch_poll_results partially). list_members and list_polls have zero properties and required arrays, LLMs cannot infer what these tools accept or require.
Parameter descriptions lack format constraints and validation rules. 'after' and 'before' in fetch_reports state 'format: YYYY-MM-DD' in description but not as JSON Schema format field. 'standup_id' in fetch_reports lacks description of what happens when omitted ('If not provided, reports for all standups will be fetched' is only in tool description, not param description). No min/max on numeric IDs.
No documented output/return schemas. Code does not show what list_members, list_standups, or fetch_reports return. LLMs cannot plan downstream calls or extract needed fields (e.g., user_id to pass to fetch_reports). This violates pattern:tool and pattern:tool-chain.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Posts a report to Geekbot. Use this tool to post a report to Geekbot using the context of the conversation. This tool is usually used after the `list_standups` tool to get the standup id and the question ids. If the context of the conversation lacks sufficient information to answer the questions of the standup, the assistant will ask for the missing information. The report should be beautifully formatted. ALWAYS type formatted reporte in the conversation for preview purposes before calling this tool.
No error handling or recovery guidance. geekbot_mcp/gb_api.py calls response.raise_for_status() but does not document what errors are possible, whether they are retryable, or what LLMs should do next. E.g., a 401 (invalid API key) is unrecoverable and fatal; a 429 (rate limited) is retryable. This guidance is missing.
post_report tool description recommends 'ALWAYS type formatted report in the conversation for preview purposes before calling this tool', this is an instruction to the LLM, not a tool capability. This should be removed; the tool should support idempotent posting or a dry-run mode instead.
Mismatch in fetch_poll_results parameter description: poll_id description says 'ID of the specific standup to fetch reports for', should say 'poll' not 'standup'. This is a copy-paste error that will confuse LLMs.
No pagination parameters documented in list_* tools. If a user has hundreds of standups or polls, these tools will return all of them, bloating the context window. fetch_reports has a limit=50 hardcoded (visible in gb_api.py) but this is not exposed as a parameter or documented in the tool schema.
user_id parameter in fetch_reports expects a string type, but in the tool signature it shows 'user_id' is a string. However, gb_api.py's get_reports() accepts 'user_id: int | None'. Type mismatch between tool definition and implementation. Unclear whether tool accepts 'john' or '12345' or both.