Loading ToolBench
MCP server for searching indexed GitHub issues for bug solutions matching errors or symptoms, with tools for fetching issue threads, requesting library indexing, and managing bug solution searches.
BugSolutionsMCP has three tools with clear action verbs (search_, fetch_, request_) and detailed descriptions (194-250 chars each). However, input schemas lack type definitions for most parameters, and output schemas are entirely undocumented. The search_bugs tool includes helpful usage guidance (steps 1-4, call limits), but parameter descriptions are minimal. fetch_thread and request_library have adequate descriptions but no visible schema validation. Error handling is implicit rather than explicit, no recovery guidance for common failures (e.g., 'library not found').
Returns the complete GitHub issue thread for a specific issue. Use this when a search_bugs result references a linked issue number in its comments that may contain the actual fix. For links pointing to external sites, use web search instead. Each result includes the full thread: title, body, all comments, resolution text, library, and organization. IMPORTANT: Do not call this tool more than once per linked issue.
Request a GitHub library to be indexed for bug solutions.
Search indexed GitHub issues for bug solutions matching an error or symptom. Each result includes: - title: Issue title - body: Full problem description - resolution_text: The comment that resolved the issue - comments: Full thread with all replies - library: Repository name - organization: GitHub organization that owns the repo - distance: Relevance score (lower is closer) Steps: 1. Call this tool first with the exact error message or symptom as the query 2. If comments contain linked issue numbers, call fetch_thread to follow them 3. If results are not relevant to your error, call request_library to get the library indexed 4. For external URLs in comments, use web search IMPORTANT: Do not call this tool more than 3 times per question. Use the best result you have.
Input schemas lack type definitions. Parameters 'query', 'libraryName', 'owner', 'repo' are documented in descriptions but have no explicit 'type' field (string, integer, enum) in the schema. This forces LLMs to infer types and invites invalid inputs.
Output schemas are completely undocumented. search_bugs returns 'title', 'body', 'resolution_text', 'comments', 'library', 'organization', 'distance' but the response structure is not formally defined. LLMs cannot plan downstream calls or extract fields reliably.
No error recovery guidance. If search_bugs returns no results or fetch_thread hits a 404, the tool description does not tell the LLM what to do next (e.g., 'Try request_library to index the missing repo'). Agents dead-end instead of self-correcting.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | <=2025-11-25 | v2 |
Parameter 'libraryName' is optional in search_bugs ('Leave empty for global search') but the schema does not mark it as non-required. LLMs may always pass a value, defeating the global search intent.
search_bugs includes usage steps and call limits in the description ('Do not call this tool more than 3 times per question'), but these constraints are not enforced by the tool itself. LLMs may ignore the guidance, and there is no server-side rate limiting or validation.