Loading ToolBench
Local-first MCP server for Source-engine map work: VMF, BSP, entity-lump patches, compile and audit
hammer-mcp has 9 tools with mixed quality. Most tools lack visible input schemas in the provided source, only 5 of 9 show explicit parameter definitions (pakfile, pakfile_extract, search_content, fgd_class, vmf_displacements). Tools 1, 4, 6, 9 (health, map_dependencies, model_info, vmf_read) have no visible input schema. Descriptions are present but generic (avg ~150 chars); many lack actionable context for LLM selection. No tool shows output schema documentation. Error handling and recovery guidance are absent. Naming is verb-forward (good), but parameter descriptions are sparse. This is a domain-specific tool suite (Source engine mapping) with reasonable intent but incomplete schema visibility and LLM-unfriendly documentation.
Describes one class as the game's own FGD declares it, or lists the classes.
Reports what this sidecar can actually do. Must never raise: hammer-mcp's own health tool calls it to describe a broken install rather than fail with it.
Every asset a compiled map references, and where each one will come from.
Bounds, skins and materials of one .mdl -- what Hammer's model browser shows.
Lists what a compiled map carries in lump 40, the embedded pakfile. It is a plain ZIP, so this is the audit of what actually ships with the map: custom materials and models a player will see, and the cubemap VTFs (`c-*.vtf`), whose presence is machine-checkable proof that buildcubemaps was run -- more reliable than trusting the compile settings.
Pulls files out of lump 40, the map's embedded pakfile. `read_pakfile` says what is in there; nothing could get it out, so anything packed inside a map -- a cubemap, a soundscript, a custom material -- was readable only by unpacking the map by hand. That is the gap this closes.
4 of 9 tools (health, map_dependencies, model_info, vmf_read) have no visible input schema in source code.
No tool documents its output schema. LLMs cannot plan downstream calls or extract required fields without knowing what the response contains. This violates the pattern:tool-description and pattern:response-shaper requirements.
Descriptions lack actionable context for LLM selection. E.g., 'Reports what this sidecar can actually do' (health) and 'Every asset a compiled map references' (map_dependencies) do not explain WHEN to call these tools or what they return. Descriptions should be 50 - 200 chars and answer: what, when, why.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Materials and models the game actually has, by name.
Displacements as srctools reads them -- the oracle for our own reader.
Entities, brushes and counts of a .vmf, without judging any of it.
Parameter descriptions are sparse or missing. E.g., pakfile_extract's 'pattern' param says 'Optional glob pattern to match files' but does not explain glob syntax, case sensitivity, or examples. fgd_class's 'fgd' param accepts 'string|array' but does not clarify when to use each or what array elements mean.
No error handling or recovery guidance visible. Tools do not document what errors they can raise, how to interpret them, or what the LLM should do next (retry, ask user, abort). This violates pattern:recovery-guide.