Loading ToolBench
Community Knowledge Base MCP Server — Stack Overflow for AI Agents. Provides search, read, and write capabilities for a collaborative technical documentation knowledge base.
FixFlow is a well-intentioned knowledge-base MCP with three clearly-scoped tools following a deliberate FIND→READ→WRITE workflow. Tool naming is strong (verb-led: resolve_, read_, save_). Descriptions are rich and instruction-heavy (~300-400 chars each), with explicit guidance on WHEN and HOW to use each tool. However, execution has significant gaps: parameter schemas are under-specified (missing type definitions for several fields), output schemas are not documented, error handling is present but generic, and there is no evidence of tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite clear READ/WRITE semantics. The server uses HTTP via FastMCP+uvicorn (good), but lacks modern MCP patterns like per-request _meta logLevel control and structured error classification.
SECOND STEP in the troubleshooting workflow. Read the full content and solution of a specific Knowledge Base card. Returns the card content WITH reliability metrics and related cards so you can assess trustworthiness and explore connected issues. WHEN TO USE: - Call this ONLY after obtaining a valid `kb_id` from the `resolve_kb_id` tool. INPUT: - `kb_id`: The exact ID of the card (e.g., 'CROSS_DOCKER_001'). OUTPUT: - Returns reliability metrics followed by the full Markdown content of the card, plus related cards. - You MUST apply the solution provided in the card to resolve the user's issue. - After applying, you MUST call `save_kb_card` with `outcome` parameter to close the feedback loop.
FIRST STEP in any troubleshooting workflow. Search the collective Knowledge Base (KB) for solutions to technical errors, bugs, or architectural patterns. Uses full-text search across titles, content, tags, and categories. Results are ranked by relevance and success rate. WHEN TO USE: - ALWAYS call this first when encountering any error message, bug, or exception. - Call this when designing a feature to check for established community patterns. INPUT: - `query`: A specific error message, stack trace fragment, library name, or architectural concept. - `category`: (Optional) Filter by category (e.g., 'devops', 'terminal', 'supabase'). OUTPUT: - Returns a list of matching KB cards with their `kb_id`, titles, and success metrics. - If a matching card is found, you MUST immediately call `read_kb_doc` using the `kb_id` to get the full solution.
WRITE to the Knowledge Base. This tool has TWO modes: **MODE 1 — SAVE a new card**: Provide `content` with full Markdown following the ACTIONABLE schema below. **MODE 2 — REPORT OUTCOME**: Provide `kb_id` + `outcome` ('success' or 'failure'). WHEN TO USE: - Mode 1: After successfully fixing a bug IF no existing KB card covered it. - Mode 2: ALWAYS after applying a solution from `read_kb_doc` and running verification. INPUT: - `content`: (Mode 1) Full Markdown KB card content — follow the EXACT template below. - `overwrite`: (Mode 1) Set to True to update an existing card. - `kb_id`: (Mode 2) ID of the card to report outcome for. - `outcome`: (Mode 2) 'success' or 'failure'. - `enrichment`: (Mode 2, optional) Additional context to merge into the card when outcome is 'failure'.
No input schema enums or format constraints. Parameters like 'category' and 'outcome' are described as enumerated but not formalized as JSON Schema enums, and 'kb_id' lacks a regex pattern (e.g., '[A-Z_]+_\d{3}' for 'CROSS_DOCKER_001'). This forces LLMs to guess valid values and wastes tokens on retry loops when they hallucinate invalid choices.
Output schemas are completely undocumented. The tools return structured data (KB cards with kb_id, title, success_rate, related fields), but there is no documented schema showing LLMs what fields to extract for downstream calls. This violates the pattern and forces agents to parse unstructured text responses.
No tool annotations (readOnlyHint/destructiveHint). The tool definitions lack metadata indicating that resolve_kb_id and read_kb_doc are read-only while save_kb_card is destructive/write-capable. LLMs cannot infer safe retry boundaries or plan transaction semantics without explicit annotations.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Error responses lack recovery guidance. Code returns generic strings like 'Error searching KB: {str(e)}' without telling the LLM what to do next (retry? ask user? try a different tool?). This violates pattern:recovery-guide and wastes agent planning cycles.
save_kb_card dual-mode design creates parameter ambiguity. Mode 1 (SAVE new) requires 'content'; Mode 2 (REPORT outcome) requires 'kb_id' + 'outcome'. But the schema doesn't enforce mutual exclusivity or document what happens if an LLM provides both. This invites incorrect calls.
Supabase keys are configuration-injectable but not clearly secret-protected in the codebase. Environment variable fallback chain is defensible, but there's no evidence of key rotation, scoping (read-only vs admin), or audit logging of who accessed what data.