Loading ToolBench
Git Changelog MCP Server for generating changelogs and release notes
The server defines 2 tools with reasonable structure but has significant gaps in schema completeness, parameter descriptions, and error handling guidance. Both tools have action-verb names (generate_*) and basic docstrings, but parameter descriptions are inconsistent and output schemas are not formally documented. Input validation exists but error messages lack recovery guidance. This is solid C-grade work, better than average community servers, but with clear gaps before production use.
Generate changelog from git history.
Generate release notes for a specific version.
Output schemas not documented. Both tools return `str` but do not specify what structure or fields are in that string. LLMs cannot plan downstream processing without knowing if output is JSON, markdown, or plain text, or what structure it contains.
Parameter descriptions lack detail on constraints and format. E.g. 'output_format' for generate_changelog lists '(markdown, json, keepachangelog)' in description but does not explain what each produces. 'from_version' says '(optional)' even though it has a default. Descriptions are too brief (under 50 chars avg) to guide LLM parameter selection.
Error handling does not guide recovery. Errors like 'Error: Invalid repo_path' or 'Error: Version not found' do not tell the LLM what to do next. Should include guidance: 'repo_path must be a valid local git repository; check with `git status` first' or 'Try calling generate_changelog first to list available versions.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 60 | - | v1 |
Enum constraints for 'output_format' and 'style' are documented in descriptions but not formalized in JSON Schema. Using string enums in schema (not just description) allows LLMs to auto-complete and validates input before tool execution.
The 'use_ai' parameter in generate_release_notes has a side effect (depends on GITHUB_TOKEN environment variable) that is not clearly documented in the parameter description. Should state: 'Set to true only if GITHUB_TOKEN is configured; falls back to template-based generation otherwise.'
No dry-run or confirmation pattern for potentially destructive operations. While both tools are read-only, if this server were extended to create tags or commits, irreversible operations should support a 'dry_run' parameter or confirmation flow.