Loading ToolBench
MCP server that wraps the CodeBoarding CLI as living architecture docs: cheap drift detection, on-demand (re)mapping, and reading the generated map back for a RAG/agent.
CodeBoarding MCP has well-structured tool definitions with clear descriptions (avg 180 chars, within baseline 194) and complete input schemas. All 4 tools are explicitly registered with @McpServerTool attributes and have parameter descriptions. However, output schemas are not documented in the source, responses are inferred from code (Ok/Err wrappers). Parameter constraints are minimal (no enums, ranges, or format specs). Error handling returns structured responses but lacks recovery guidance. Tool composition is sound (each does one thing), but descriptions could be more prescriptive about when to call each tool vs alternatives.
Set a repo's LLM provider for mapping, persisted in its manifest. Use kind="ollama" (local, private/client repos), "anthropic" (cloud, public repos), or "openai-compatible" (DeepSeek/OpenRouter/LiteLLM via baseUrl + apiKeyEnv). API keys are read from the named env var, never stored.
Read the generated CodeBoarding map back as markdown (for a RAG or to answer questions). Parses <repo>/.codeboarding/analysis.json — the artifact the local CLI emits. With no section, returns the overview (description + component list + a rebuilt mermaid graph); with a component name, returns just that component's description and its relations.
Generate or update the CodeBoarding architecture map for a repo (writes analysis.json to <repo>/.codeboarding/). Expensive: invokes an LLM. mode="auto" (default) picks full when never mapped, otherwise incremental. The repo's LLM provider comes from its manifest (set via codeboarding_configure). On success the drift baseline is updated.
Cheaply check (no LLM) whether a repo's CodeBoarding architecture map is stale. Compares the current code's architectural surface against the last map and returns a drift score plus a recommendation. Call this before codeboarding_map to avoid needless expensive runs.
Output schemas not documented. Tools return Ok(object) and Err(string) but response structure is not formally specified. LLMs cannot plan downstream calls or extract fields reliably.
codeboarding_configure has 7 parameters with minimal constraints. 'kind' should be an enum (ollama|anthropic|openai-compatible). 'driftThreshold' and 'depthLevel' lack range specs (0..1 and positive int implied but not stated).
Error responses lack recovery guidance. Err() returns plain strings like 'Invalid mode' or 'Failed to launch CodeBoarding' without suggesting next steps (e.g., 'Try mode=auto or mode=full').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | <=2025-11-25 | v2 |
Tool descriptions lack dependency hints. codeboarding_map says 'Expensive: invokes an LLM' but does not say 'Call codeboarding_status first to check drift and avoid needless runs.' This forces agents to discover the pattern.
codeboarding_get parameter 'section' is nullable string with case-insensitive matching, but no enum of valid component names is provided. LLMs must call the tool blind or infer names from prior calls.