Loading ToolBench
MCP server for analyzing repositories and generating onboarding documentation
repo-onboarding has 7 tools with mixed quality. Naming is generally clear (verb-prefix patterns like generate_, get_, analyze_, read_, write_), but several tools lack adequate descriptions and schema completeness. Tool descriptions range from 70 - 180 characters, which meets baseline (avg 194 chars), but several are generic or lack actionable guidance. Schemas are partially defined: analyze_repo and get_run_and_test_commands have parameter descriptions, but write_onboarding has inconsistent detail. Error handling guidance is absent, tools do not communicate retryability, user-fixable conditions, or recovery paths. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite write_onboarding being destructive. The ping tool is deprecated in current MCP spec (removed 2026-07-28) and should be removed.
Analyze the current repository (Python-first) and return a structured summary.
Returns the authoritative instructions for generating ONBOARDING.md. This enables the slash command usage: /generate_onboarding
Returns the authoritative instructions (prompt) for generating ONBOARDING.md. Useful for retrieving the prompt content programmatically.
Return the main dev, test, and build commands for this repository.
Sanity check: returns a small JSON payload to verify MCP connectivity.
Read the ONBOARDING.md file (or a specified path).
Create or update the ONBOARDING.md file.
Tool descriptions lack LLM-optimized guidance. Many descriptions are under 100 chars and do not explain WHEN to call the tool vs alternatives or what the typical next step is. E.g., get_onboarding_template says 'Returns the authoritative instructions' but does not clarify its relationship to generate_onboarding or when to prefer one over the other.
write_onboarding is a destructive operation (WRITE risk) but lacks tool annotations and error handling. No readOnlyHint, destructiveHint, or idempotentHint is present. No guidance on what happens if the file already exists, what recovery looks like, or how to undo a mistaken overwrite. The 'create_backup' parameter partially mitigates this but does not document the behavior clearly.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 45 | - | v1 |
Missing output schema documentation. Tool responses are not documented in the source code provided. LLMs cannot plan downstream calls without knowing what fields are returned (e.g., does analyze_repo return {files: [], structure: {}, dependencies: []}?). This forces LLMs to reason about response structure without explicit guidance.
ping tool is deprecated in MCP spec (removed 2026-07-28). This tool should be removed entirely. The protocol is stateless and does not require a ping handshake.
Parameter descriptions are sparse or missing for some tools. E.g., analyze_repo's 'path' parameter says 'Optional sub-path within the repo to analyze' but does not clarify what happens if the path does not exist, whether it must be relative or absolute, or how it interacts with max_files. Parameter names like 'path' and 'mode' in write_onboarding need more detail.
Error handling guidance is absent. No tool description explains what errors are retryable, what are user-fixable, or how to recover. For example, read_onboarding does not say what happens if the file does not exist; write_onboarding does not clarify whether 'create' mode fails if the file exists or silently succeeds.
write_onboarding 'mode' parameter uses string enum ('create', 'overwrite', 'append') but the description does not clarify semantics. Does 'create' fail or succeed if the file exists? Does 'append' create the file if missing? Does 'overwrite' without create_backup=true permanently destroy the original?
Tool overlap: generate_onboarding and get_onboarding_template both appear to retrieve instructions for ONBOARDING.md generation. The distinction is unclear from descriptions alone, an LLM cannot easily decide which to call. This violates the single-responsibility principle.