Loading ToolBench
Automated documentation generation from code changes using AI. Provides MCP server for extracting Git changes, generating documentation, managing service mappings, and searching knowledge base.
ktme exhibits moderate definition quality with some strengths and significant gaps. All 8 tools have basic descriptions and JSON Schema input definitions, but parameter descriptions are sparse, output schemas are entirely undocumented, and several tools combine multiple responsibilities. Tool naming follows verb_noun convention reasonably well (read_, get_, list_, generate_, update_, search_), but schema completeness is inconsistent. The server demonstrates awareness of MCP patterns but lacks the rigor expected for production-grade tooling.
Generate documentation from code changes
Get documentation location for a service
Return the knowledge tree (services -> features -> sub-features) as JSON, optionally with a Mermaid diagram
List all mapped services
Read extracted code changes from Git
Search services by feature
Search services by query string
Output schemas completely undocumented. No schema definitions visible for return values of any tool. LLMs cannot reliably parse responses or chain subsequent calls without knowing what fields to expect.
Parameter descriptions are minimal or missing context. 'source' parameter in read_changes says 'Source identifier (commit hash, 'staged', or file path)' but does not explain the operational difference between commit hash vs staged vs path, or when to use each. Similar issues across search_services ('query' parameter has no guidance on syntax/operators) and search_by_feature ('feature' parameter undefined).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 27 | - | v1 |
Update existing documentation
generate_documentation combines multiple responsibilities: extracts changes, formats output, and prepares for documentation. Should split into separate tools: extract_changes (read-only) and format_documentation (read-only composition). Agents cannot selectively choose to extract without formatting.
ktme_get_knowledge_tree uses non-standard verb prefix 'ktme_'. Violates naming convention, should be 'get_knowledge_tree' or 'describe_knowledge_tree'. Inconsistent naming confuses LLM tool selection.
list_services accepts empty input properties (no parameters) but provides no description explaining what it returns, what ordering to expect, or whether results are paginated. LLMs cannot reason about filtering or limiting results.
No pagination or result-limiting documented on any search/list tool. If a service has hundreds of features or the repository contains thousands of commits, unbounded result lists could exhaust context window. No limit or cursor mechanism visible.
generate_documentation requires 'changes' as a JSON string parameter. This forces the LLM to manually serialize JSON, a fragile operation prone to syntax errors. Should accept a structured object (array of change objects) instead.
No error handling guidance in any tool description. If read_changes receives an invalid commit hash, or update_documentation fails because the file is read-only, LLMs have no recovery path documented. Tool descriptions do not explain what errors are possible or how to handle them.