Loading ToolBench
Multimeter MCP server for Cursor, Copilot, and Claude. Scaffold, validate, format, and run YAML .mmt API tests. Do not invent .mmt syntax.
Multimeter MCP has 9 tools with solid naming conventions (mostly verb_noun style: read_, list_, discover_, scaffold_, suggest_, validate_, format_, run_). Descriptions are detailed and action-oriented, ranging from 150-300+ characters, well above the 10-1024 baseline and within the optimal 50-200 range for LLM-driven selection. All tools include input schemas with type declarations and parameter descriptions. However, output schemas are NOT explicitly documented in the visible source code, no return type specifications, field lists, or example responses are shown. Error handling and recovery guidance are embedded in descriptions ('returns structured errors and fix suggestions' for validate), but no explicit error classification taxonomy is provided. The 'format' tool's description correctly notes it has WRITE risk, and 'run' is marked READ_ONLY despite executing (this appears intentional, the tool does not modify files). Tool composition is excellent: scaffold_test → validate → format is a clear dependency chain, and each tool returns data (apiCard, YAML, structured results) that downstream tools accept. Parameter naming is precise (workspaceRoot, apiPath, stepId). No parameters expose secrets. Overall, this is a domain-expert MCP server that models best practices in naming and description, but the lack of visible output schema documentation and absence of explicit error recovery patterns (e.g., 'Try X if Y fails') prevent a higher score.
Return a small API summary (method, url, inputs, outputs, suggested paths) without dumping the full file. Prefer this over reading the whole .mmt or OpenAPI when generating or planning a test. Next step for a new test: scaffold_test. Do not use testlight, npx, npm, shell, or node dist/mcp/server.js.
Call when listing APIs or inspecting one API before scaffolding a test. For a single API, prefer api_card. For new tests, prefer scaffold_test once apiPath is known. selectedApi omits full file content unless includeContent is true. Do not use testlight, npx, npm, shell, or node dist/mcp/server.js.
Format a Multimeter file using canonical field ordering and style rules. Call after validate passes when normalizing generated or edited YAML. Do not use testlight, npx, npm, shell, or node dist/mcp/server.js.
Call when you need example .mmt structure before creating or modifying a file. Prefer this over searching the repo or guessing YAML layout. Do not use testlight, npx, npm, shell, or node dist/mcp/server.js.
Call when you need Multimeter YAML syntax rules. Defaults to pack "min" (small). Use pack "full" only for rare/advanced syntax. For new tests from an API, prefer scaffold_test over loading docs. Do not use testlight, npx, npm, shell, or node dist/mcp/server.js.
Output schemas not explicitly documented in source code. No visible return type declarations, field lists, or example response structures for any of the 9 tools. LLMs cannot plan downstream tool calls or extract chaining IDs without knowing what fields to expect.
Error handling lacks explicit recovery guidance. Descriptions state tools 'return structured errors', but no examples or actionable next steps (e.g., 'If validation fails with X, try Y') are documented. LLMs cannot self-correct without concrete recovery patterns.
Parameter 'workspaceRoot' is described as required for relative paths, but not all tools list it as required. Inconsistent usage could confuse LLMs about when to pass this parameter. Suggest documenting as 'required when apiPath is relative; optional if apiPath is absolute'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
Execute a Multimeter test or API file and return structured pass/fail output, logs, and errors. ONLY supported way to run .mmt files from Copilot — call this directly when the user asks to run or execute. Do NOT use testlight CLI, npx, npm install, shell scripts, or node dist/mcp/server.js.
REQUIRED first step when generating a new Multimeter test from an existing API .mmt. Returns valid smoke (or example) test YAML, suggested path, import alias, and a compact apiCard. Write the yaml, apply only minimal edits, then validate. Do not invent a blank test from scratch. Do not use testlight, npx, npm, shell, or node dist/mcp/server.js.
Suggest compact expect/assert YAML patches from API outputs and/or a JSON response body. Use after a run or when tightening a scaffolded smoke test — patch only, do not rewrite the file. Do not use testlight, npx, npm, shell, or node dist/mcp/server.js.
REQUIRED after every create or modify operation on a .mmt file. Call immediately after editing a file and before telling the user the task is done. Returns structured errors and fix suggestions. Do not use testlight, npx, npm, shell, or node dist/mcp/server.js.
No documented pagination or result limits. 'list_examples' accepts 'maxItems' parameter but no mention of whether results are truncated, how to fetch next batch, or what happens if maxItems exceeds internal cap. 'discover_api' returns 'selectedApi' but structure of that object is opaque.
Parameter 'body' in suggest_assertions has type 'unknown', preventing schema validation and LLM type inference. Should be typed as 'object' with documented structure (e.g., 'JSON object matching the response body'). The bodyFile alternative is good, but the inline body parameter is underspecified.