Loading ToolBench
AI-native software engineering tools with design-by-contract verification. Exposes invar guard, sig, map, refs, and document manipulation tools as MCP services.
Invar MCP Server defines 13 tools with explicit names, descriptions, and input schemas. Most tools follow verb_noun naming conventions and have structured descriptions. However, there are significant gaps: output schemas are not documented anywhere; many parameter descriptions lack constraint details; error handling guidance is absent; and no tool annotations (readOnlyHint/destructiveHint) are present despite the risk classification. The server shows baseline competence in naming and parameter definition but falls short of production-grade quality due to missing output documentation and weak error recovery guidance. Average per-tool score: 62.
Delete a section from a document. Optionally delete child sections as well.
Find sections matching a pattern in a document. Supports glob-style title patterns, optional content search, and level filtering.
Insert a new section into a document at a specified anchor location.
Read a specific section from a document. Section can be addressed by slug path (e.g., 'requirements/auth'), fuzzy match (e.g., 'auth'), index (e.g., '#0'), or line anchor (e.g., '@48'). Returns section content with optional child sections.
Read multiple sections from a document in one operation. Returns a list of dicts with 'path' and 'content' keys.
Replace a section's content in a document. Returns info about the replacement operation.
No output schemas documented for any tool. Tool descriptions state what tools return in English ('Returns status snapshot', 'Returns section content', 'Returns info about replacement operation') but never formalize the response structure. LLMs cannot plan downstream tool chains without knowing return field names and types.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present in the MCP server definition. Tools are classified with Risk: READ_ONLY, WRITE, DESTRUCTIVE in the spec provided, but these hints are not registered in the MCP protocol layer. Agents cannot determine which tools are safe to retry or which require user confirmation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Extract document structure (table of contents) from a markdown file. Returns sections with hierarchy, slugs, line numbers, and character counts.
Smart Guard: Verify Python code quality with static analysis + tests. Runs pytest + doctest + CrossHair + Hypothesis. Uses pyproject.toml as project marker. For DX-91 full-scan gate parity, authoritative CLI path is 'uvx invar-tools guard --all'. Use this INSTEAD of Bash('pytest ...') or Bash('npm test ...').
Get status snapshot for a deferred invar_guard full scan run. Use this after invar_guard returns status=deferred.
Wait for deferred invar_guard full-scan completion with bounded polling. Returns running/complete/failed/cancelled status.
Show function signatures and contracts (@pre/@post). Supports Python projects. Use this INSTEAD of Read('file.py') when you want to understand structure.
Find all references to a symbol. Target format: 'path/to/file.py::symbol' or 'path/to/file.pyi::symbol'
Show function signatures and contracts (@pre/@post). Supports Python projects. Use this INSTEAD of Read('file.py') when you want to understand structure.
invar_map description is a copy-paste error: it claims 'Show function signatures and contracts (@pre/@post)' which is invar_sig's purpose, not map's. Map's actual purpose is unclear, likely 'Show the project structure/map of all functions' but the description does not explain what 'map' returns or when to call it instead of invar_sig.
Destructive operations (invar_doc_delete, invar_doc_replace, invar_doc_insert) lack error recovery guidance and confirmation patterns. Descriptions do not mention what happens if an operation fails halfway, whether it can be rolled back, or whether a dry-run mode exists. Agents need explicit recovery paths for irreversible actions.
Many parameter descriptions lack constraint details. For example, invar_doc_find's 'pattern' parameter mentions 'glob-style' but does not explain syntax (*, ?, [...] behavior). invar_guard's 'path' parameter says 'Project path (default: .)' but does not specify if relative or absolute paths are required, or if symlinks are followed.
Tool names use abbreviations (invar_sig, invar_map, invar_refs, invar_doc_toc) which are less discoverable than full names. LLMs benefit from explicit names like 'show_function_signatures', 'list_project_structure', 'find_symbol_references'. Abbreviations force the LLM to infer meaning rather than reading intent from the name.
No error handling guidance. Tool descriptions do not explain what happens on failure (file not found, parsing error, permission denied, etc.). LLMs are left to guess recovery steps. For example, invar_doc_read does not say what error is returned if the section slug is invalid, or suggest alternatives.
No pagination guidance for tools returning multiple items. invar_doc_find and invar_map have a 'top' parameter to limit results, but descriptions do not explain what happens if there are more results beyond the limit, whether pagination is available, or how to continue.