Developer productivity tools: tech debt scanner, release notes generator, Dockerfile auditor
The server defines 3 tools with complete schemas and reasonable descriptions, but has multiple gaps in parameter descriptions, lacks error handling guidance, and missing documentation for output structures. Naming follows verb_noun conventions. Descriptions are adequate (100-300 chars) but could be more precise about LLM selection criteria. All tools are READ_ONLY, lowering security risk. Parameter descriptions exist but are sometimes vague ('Путь к директории или файлу' lacks format constraints). Output structures are returned as formatted strings rather than structured JSON, reducing downstream composability.
Аудит Dockerfile на соответствие best practices. Проверяет более 30 правил (использование слэшей, многостадийные сборки, минимизацию слоёв, security hardening и т.д.). Возвращает список проблем с приоритетами и рекомендациями.
Генерирует release notes из git-лога в формате Markdown. Автоматически категоризирует коммиты по Conventional Commits.
Сканирует директорию на маркеры техдолга: TODO, FIXME, HACK, BUG, XXX, DEPRECATED и др. Возвращает приоритизированный список с файлом, строкой и контекстом.
Output schemas not documented. All three tools return formatted strings rather than structured JSON. Prevents LLM from extracting specific fields for downstream processing (e.g., extracting file paths from scan_tech_debt, version from generate_release_notes, severity from audit_dockerfile).
Parameter descriptions lack format constraints and examples. 'extensions' in scan_tech_debt says 'comma-separated' but doesn't clarify spacing, quoting, or format (.py,.js vs . py, . js). 'from_ref' and 'to_ref' in generate_release_notes don't document accepted git ref formats.
Enum constraints not formalized in schema. 'priority_filter' in scan_tech_debt documents allowed values ('high', 'medium', 'low') only in text description; not declared as JSON Schema enum. Same for 'strict' boolean, unclear if other values are accepted or rejected.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Error handling provides no recovery guidance. 'Path not found: {path}' returns a plain error but doesn't guide LLM: should it retry? ask user? check path format? No differentiation between user-fixable and fatal errors.
No tool-chaining support. Response fields don't include IDs or references needed by other tools. E.g., if scan_tech_debt is extended with a 'fix_todo' tool, the response should include a per-issue 'id' field; currently only file+line are returned.
Descriptions lack selection guidance. No explanation of WHEN to call scan_tech_debt vs audit_dockerfile, or which tool best serves a given user intent. LLMs must guess when multiple tools are available.