Multimeter is a Git-native REST client and API testing tool for VS Code. Requests, tests, mocks, and docs are YAML .mmt files in Git — the same files in the visual editor and in CI via testlight. Apache 2.0. No account.

How do I use Multimeter with Cursor, Copilot, or Claude?

Install the VS Code/Cursor extension or add MCP with npx -y mmt-mcp. Agents should call scaffold_test, validate, format, and run instead of guessing .mmt syntax.

Yes. Apache License 2.0. No account required.

Reports — Multimeter docs

After you run a test, the test runner shows an Overview row of summary cards above the step Report. The cards update as checks and asserts complete and stay…Markdown (no JavaScript)# Reports After you run a test, the **test runner** shows an **Overview** row of summary cards above the step **Report**. The cards update as checks and asserts complete and stay visible until the next run. ![Test reports](../../screenshots/test-reports.png) ## Summary cards Four cards appear in a responsive grid (one column on narrow panels, up to four across on wide panels): | Card | Icon | What it shows | |---|---|---| | **Passed** | Green checkmark | Number of check/assert steps that passed. Sub-label: pass rate (for example `100.0%`). | | **Failed** | Red X | Number of steps that failed. Sub-label: fail rate (for example `0.0%`). | | **Total** | Blue list | Total check/assert steps reported so far. Sub-label: `N check` or `N checks`. | | **Duration** | Gray clock | Wall-clock run time (for example `0.123s`). Sub-label: when the run started (relative time, for example `2 min ago`). | Cards use VS Code testing colors: green for passed, red for failed, blue for total, gray for duration. While a run is in progress, counts and duration update live. Before the first run, the Overview section is hidden. ## Report list Below the overview cards, the **Report** section lists every check, assert, and debug step from the run. Use the **filter** control on the **Report** header to show **All**, **Passed**, or **Failed** steps. This is view-only — it does not change what ran or what gets exported. ### Step status icons Each row starts with a status icon: | Icon | Meaning | |---|---| | {{btn:pass}} | Step passed | | {{btn:error}} | Step failed | | {{btn:play-circle}} | Step is running | | {{btn:stop-circle}} | Run was cancelled | | {{btn:warning}} | Step error (invalid configuration or runtime error) | | {{btn:debug}} | Debug output | | {{btn:compass}} | Pending (not started yet) | When a step reused a cached call result, the pass/fail icon switches to a database-style glyph to indicate **served from cache**. ### Step details | Control | What it does | |---|---| | Step title | From the step's `title:` in YAML, or **Check** / **Assert** / **Debug** when no title is set | | {{btn:chevron-right}} / {{btn:chevron-down}} | Expand or collapse expect comparisons, request/response details, and other output | | Timestamp | Local time when the step reported (right side of the row) | Expanded **Expect** rows show the comparison expression (for example `status == 200`) with a per-expect pass/fail icon. Failed expects also show **got:** actual vs expected values, and similarity or count when relevant. For **call** steps, expanded details can include status code, request, response headers/body, and extracted outputs. ## Report levels (`all`, `fails`, `none`) The YAML `report` field on [check](./steps/check.md), [assert](./steps/assert.md), [judge](./steps/judge.md), and call/http [`expect`](./steps/call.md#expect) / [`require`](./steps/call.md#require) controls **which results are emitted** into the Report list (and related logs/exports). This is separate from the UI filter above — the filter only hides rows that were already emitted. | Value | What gets reported | |---|---| | `all` | Passes and failures | | `fails` | Failures only | | `none` | Nothing — silent even when the comparison fails | ```yaml - check: actual: ${doLogin.status} expected: 200 report: all - check: actual: ${doLogin.status} expected: 200 report: fails - check: actual: ${doLogin.status} expected: 200 report: none ``` A string sets both contexts to the same level. You can also split **internal** (running this test file directly) vs **external** (when the test is imported or run as part of a suite): ```yaml - check: actual: ${doLogin.status} expected: 200 report: internal: all # when running this test directly external: fails # when imported or added to a suite - call: login expect: status_code: 200 report: internal: all external: fails ``` **Default** when `report` is omitted: `internal: all`, `external: fails`. Notes: - A failed `assert` / `require` still **stops** the flow even when `report: none` (silence only affects reporting, not control flow). - Soft `check` / `expect` failures never stop the flow; `report` only controls whether they appear in the Report list. - The same levels drive [check/assert log output](../../features/logging/test-logging.md#checks-and-asserts) in the Output panel. ## Export Use {{btn:export:Export}} on the run bar to save the full report (HTML, MMT, Markdown, or JUnit XML) after a run completes. See [Report overview](../report/index.md) for export formats and CI usage. --- See also: [Test overview](./index.md) · [Operators](./operators.md) · [Report overview](../report/index.md) · [Edit Test](./edit.md) For AI agents · llms.txt · Home