Multimeter
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| read_documentationA | 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. |
| list_examplesA | 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. |
| discover_apiA | 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. |
| api_cardA | 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. |
| scaffold_testA | 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_assertionsA | 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. |
| validateA | 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. |
| formatB | 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. |
| runA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| edit_mmt_file | Modify a .mmt file: read docs, edit, validate (MCP-first, no CLI). |
| run_mmt_file | Run a .mmt file using the run MCP tool (not CLI or shell). |
| generate_tests_for_api | Workflow prompt for generating Multimeter tests for an API using MCP tools. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| golden-smoke | Multimeter guide: golden-smoke |
| agent-workflow | START HERE: MCP-first workflow for creating, modifying, validating, and running .mmt files |
| offline-agent | Multimeter guide: offline-agent |
| general | Multimeter guide: general |
| generate | Multimeter guide: generate |
| generate-test | Multimeter guide: generate-test |
| generate-test-skill | Multimeter guide: generate-test-skill |
| generate-api | Multimeter guide: generate-api |
| generate-env | Multimeter guide: generate-env |
| generate-suite | Multimeter guide: generate-suite |
| generate-doc | Multimeter guide: generate-doc |
| generate-loadtest | Multimeter guide: generate-loadtest |
| min-overview | Multimeter guide: min-overview |
| min-workflow | Multimeter guide: min-workflow |
| min-test | Multimeter guide: min-test |
| min-api | Multimeter guide: min-api |
| min-suite | Multimeter guide: min-suite |
| min-env | Multimeter guide: min-env |
| min-doc | Multimeter guide: min-doc |
| min-loadtest | Multimeter guide: min-loadtest |
| min-constraints | Multimeter guide: min-constraints |
| testgen-profile | Multimeter guide: testgen-profile |
TDQS
Scored across 9 tools
Most tools map to distinct workflow stages: learning syntax, seeing examples, discovering APIs, scaffolding, validating, formatting, and running. discover_api and api_card overlap for single-API inspection, but the descriptions make the preferred choice clear.
Tool names mostly follow an imperative verb_noun pattern such as read_documentation, list_examples, discover_api, scaffold_test, validate, and run. api_card breaks the pattern as a noun-only name, but the inconsistency is minor and not confusing.
Nine tools is well-scoped for this server's purpose of discovering, generating, validating, formatting, and running Multimeter tests. Each tool serves a clear role in the workflow without redundancy or bloat.
The toolset covers the core lifecycle from API discovery and test scaffolding to assertion suggestions, validation, formatting, and execution. A few peripheral capabilities like listing or deleting existing tests are absent, but agents can complete the primary authoring workflow without dead ends.