Loading ToolBench
MCP server that lets AI agents inspect, compile, and diff Kapitan projects safely.
Strong tool definitions with clear naming (verb_noun pattern), comprehensive descriptions (avg 180 chars), and complete input schemas. All 12 tools have explicit registration with ToolAnnotations. Parameters are well-typed and described. Output schemas are documented in descriptions. Error handling uses structured KapitanMcpError responses. Main gaps: no pagination support for list tools, no batch variants, and some parameter descriptions could be more prescriptive about constraints.
Show the ordered class include tree for a target, so you can see which class contributes or overrides a value (parameters merge in include order; target wins last).
Compile the given targets. Writes into the project's compiled/ only when apply is true. Remote fetch is off unless you opt in with fetch=true.
Compile the given targets into a temp dir and return a unified diff against the committed compiled/ output. Never writes into compiled/. Run this before finishing an inventory or template change to review what it produces.
Report the keys actually used under a generator block (default 'components'), learned from the project's own working blocks. Returns each key with how many blocks use it and examples; keys used by exactly one block come back in rare_keys as likely typos. Use to confirm a field name before adding it, instead of guessing the schema.
Flag components/generators blocks that no kadet compile entry consumes: the silent no-op where an inventory block emits nothing with no error. Reads the resolved inventory (all targets if none given). Run after editing a generator block, before kapitan_compile_diff. Catches unwired blocks, not mistyped keys inside a block.
List tools (kapitan_list_targets, kapitan_list_classes) lack pagination (limit, offset, total_count). Large projects may return hundreds of items, exhausting context window.
Parameter descriptions for 'kind' and 'scope' in kapitan_search_inventory use pipe-delimited enums in text rather than formal JSON Schema enum constraints. LLMs cannot parse these reliably.
kapitan_generator_trace and kapitan_generator_schema have vague names ('trace', 'schema') that do not clearly convey action. 'trace' could mean debug trace, execution trace, or dependency trace. Consider 'kapitan_find_unused_generators' and 'kapitan_inspect_generator_keys'.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | <=2025-11-25 | v2 |
Return the fully resolved (merged + interpolated) inventory for one target. Prefer this over mentally merging YAML. Pass a dotted ``parameter_path`` (e.g. 'mysql.image') to fetch just a subtree and keep the response small.
Run kapitan's built-in lint (yamllint plus orphan-class checks) and return whether it passed, with the raw output.
List classes, mapping dotted names to file paths. Optional glob ``pattern``.
List the project's targets (name + path). Optional glob ``pattern`` filters by name.
Detect the kapitan version, inventory backend, and target count for the project. Call this first: the backend determines interpolation syntax for other tools.
List secret refs in the inventory (backend, path, whether a ref file exists). Metadata only: this never reveals a ref value, and no reveal tool exists.
Find where a parameter is defined or overridden across raw inventory YAML. ``kind``: key|value|regex. ``scope``: classes|targets|all. Confirm the resolved winner with kapitan_inventory_target.
No batch variants for compile operations. Agents calling kapitan_compile in a loop for multiple targets waste tokens and latency. The tool accepts a targets array but description does not emphasize batch capability.
Error responses use structured KapitanMcpError but descriptions do not document what errors are possible or how to recover. E.g., kapitan_inventory_target does not explain what happens if target is not found.