mmt-mcp 1.45.2-pre → 1.45.3

package/dist/examples/intermediate/20_document_parameters/README.md

@@ -21,5 +21,6 @@ An intermediate `type: doc` example that documents input parameters with options
 - **Ranges** use syntax like `<<i:page>> [1-5] Page number`.
 - **Output annotations** use `<<o:name>> Description`.
 - **`html.triable: true`** enables interactive Try buttons in rendered docs.
+- Open the API file’s **Inputs** tab to pick values with the ⋯ menu on constrained fields.
 
-See [Doc docs](../../../docs/files/doc/index.md#parameter-annotations-in-api-descriptions) for details.
+See [Input and output documentation](../../../docs/files/input-output-docs.md) for details.

package/dist/guides/generate-api.md

@@ -65,6 +65,7 @@ Notes for the AI:
 ## When to use which fields
 
 - Use **`title`** and **`description`** whenever the user describes intent or business meaning (`"login endpoint"`, `"create user"`, etc.).
+- When documenting parameters, prefer `<<i:name>>` / `<<o:name>>` in `description`, with `[a, b]` or `[1-5]` for allowed values / ranges on inputs (⋯ picker + Doc tables).
 - Use **`tags`** when the user mentions categories like "smoke", "load", "auth", "payments".
 - Use **`inputs`** when the user expects to change parameters between runs (username, pagination, filters, ids, etc.).
 - Use **`outputs`** + **`setenv`** when the user wants to **capture response data** for later steps (e.g. tokens, IDs).

package/dist/guides/generate-test-skill.md

@@ -53,6 +53,8 @@ steps:
       status: 200
 ```
 
+Prefer **inline `expect` / `require` on the `call`** for assertions about that step’s outputs. Use separate `check` / `assert` steps only for cross-step conditions.
+
 ## When to use this skill
 
 - “Generate a test for this API.”

package/dist/guides/generate-test.md

@@ -142,7 +142,9 @@ Beyond the basic `call`, `id`, and `inputs`, a call step also supports:
   report?: all | fails | none # controls pass/fail reporting level
 ```
 
-`expect` is a shorthand for common assertions — each key is a dotted path into the response, and the value is compared with `==` by default. You can prefix with an operator (e.g. `>= 1`, `!= null`).
+`expect` is a shorthand for common assertions — each key is a dotted path into the response, and the value is compared with `==` by default. You can prefix with an operator (e.g. `>= 1`, `!= null`). Use `require` instead of `expect` when a failed comparison must **stop** the test (same map shape).
+
+**Prefer inline `expect` / `require` on the `call` or `http` step** when the comparison is only about that step’s outputs (status, body fields, headers, …). Do **not** add a separate `- check:` / `- assert:` step for those. Reserve standalone `check` / `assert` for multi-step or cross-step conditions (comparing two step ids, values set earlier, loop state, etc.).
 
 `debug` uses the same syntax as `expect` but never fails the test — it always logs results with a debug icon for troubleshooting. Debug entries are excluded from exported reports.
 
@@ -328,5 +330,6 @@ steps:
 - Prefer small, readable tests focused on a single behavior.
 - Prefer `steps` for simple linear flows; only use `stages` when explicit parallelism is needed.
 - Always include `title` and `tags` (even if tags is a small list like `[smoke]`).
+- Prefer **inline `expect` / `require` on `call` / `http`** over a following `check` / `assert` when validating only that step’s result.
 - Avoid adding `js` steps unless the user needs custom logic that can’t be expressed with other constructs. YAML comments (`#`) are fine — Format Document preserves them. Prefer `title` / `description` for structured documentation.
-When unsure, generate a **minimal valid test** that clearly calls the described APIs and asserts the most important property (typically HTTP status or a key field in the response).
+When unsure, generate a **minimal valid test** that clearly calls the described APIs and asserts the most important property (typically HTTP status or a key field in the response) via inline `expect` on the call.

package/dist/guides/min/test.md

@@ -27,7 +27,7 @@ steps:
 - Use `steps` **or** `stages`, not both
 - Every `call` needs unique `id`
 - Import aliases before calling them
-- Assert with `expect` on call, or `assert` / `check` steps
+- Prefer `expect` / `require` **on the call** when validating that step only; use `assert` / `check` steps for cross-step conditions
 - No YAML comments (`#`)
 - Tokens: `e:`, `i:`, `r:`, `c:` (snake_case)
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mmt-mcp",
-  "version": "1.45.2-pre",
+  "version": "1.45.3",
   "description": "Multimeter MCP server for Cursor, Copilot, and Claude. Scaffold, validate, format, and run YAML .mmt API tests. Do not invent .mmt syntax.",
   "mcpName": "io.github.mshobeyri/multimeter",
   "type": "module",