Loading ToolBench
An MCP server that provides access to kd-gen functionality for enum generation from YAML configuration files.
kd-gen provides 8 tools with explicit schema registration via mark3labs/mcp-go framework. All tools have descriptions and input schemas visible. However, descriptions are brief (10-60 chars), parameter descriptions lack depth, and output schemas are undocumented. Tool naming follows verb_noun convention well (list_methods, generate_enum, validate_config). No security issues detected (no credentials in params). Error handling is basic, no recovery guidance documented. The server targets a specialized domain (Go enum code generation) with coherent single-responsibility tools, but falls short of production-grade LLM optimization due to sparse parameter documentation and missing output schema specifications.
Compare two enum configuration files and show the differences.
Show an example enum config file for a given type.
Explain the structure and methods of an enum from its configuration.
Format and normalize an enum configuration file.
Generate Go enum types from a YAML configuration file.
List all available enum generation methods
Show the YAML structure of the config file for generating enums.
Validate a config file for correctness.
Parameter descriptions are minimal or absent. E.g., 'config_path' is described as 'Path to the enum configuration YAML file' (41 chars), which is a label rather than guidance on format, constraints, or when to use it. LLMs need to know acceptable paths, whether relative/absolute, and examples.
Output schemas are not documented. Tools like 'generate_enum' and 'explain_enum' return structured results, but the schema (field names, types, examples) is invisible to LLMs. Without documented outputs, agents cannot plan chained calls or extract the right data.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 55 | - | v1 |
Tool descriptions are too brief (40 - 60 chars). E.g., 'show_config_structure' is 'Show the YAML structure of the config file for generating enums.' This labels what the tool does but omits WHEN to call it (e.g., 'before writing your first enum config') and WHAT the LLM should expect to learn (structure, required fields, valid options).
No error handling guidance. If a config file is invalid or missing, what does 'validate_config' return? What recovery steps should the LLM try? Without documented error codes or actionable messages, agents cannot self-correct.
Parameter 'type' in 'example_config' lacks constraint documentation. Should it be an enum (string, int, uint, etc.)? Are custom types allowed? Without explicit constraints, LLMs may pass invalid values, wasting calls.
No pagination or result-limiting guidance. Tools like 'list_methods' and 'show_config_structure' are probably small, but if they scale (e.g., listing methods or fields), no max_results or pagination params are visible. Large unbound results waste context.