mcprigor 1.3.1 → 1.5.0

package/docs/LANGUAGE-SPEC.md

@@ -1,9 +1,11 @@
 # MCP Test Language 1
 
-Status: compatibility-stable frontend for MCP Rigor 0.12.
+Status: compatibility-stable frontend for MCP Rigor 1.x.
 
 The `.mcpr` language and YAML compile to the same `Suite` runtime model. Every user-authored YAML capability has a deterministic plain-language equivalent; YAML remains available for generated files and programmatic integrations rather than being a more powerful test format.
 
+Parity is enforced, not aspirational: every `.mcpr` construct compiles to a suite that also validates against the YAML/JSON schema, and `mcprigor convert my-tests.mcpr --out my-tests.yaml` (or `--format json`) emits that equivalent file. The converted suite reloads to the identical suite model and produces the same run results — the regression suite converts each shipped example, reloads it from YAML, and compares runs.
+
 ## Design goals
 
 - Readable by QA professionals without programming experience
@@ -62,6 +64,23 @@ Server options:
     Authorization: "Bearer ${env.QA_TOKEN}"
 ```
 
+Multi-server compositions use named server declarations and per-test routing:
+
+```text
+Named server "catalog": node services/catalog.js
+Named server "billing": https://qa.example.com/billing/mcp
+
+Server options for "billing":
+  headers:
+    X-Tenant: qa
+
+Test: "catalog lookup"
+  On server "catalog"
+  Call tool "search"
+```
+
+The YAML equivalent is a top-level `servers` mapping plus `server` on a test. A composition requires at least two named servers, and an unknown `On server` name is rejected during compilation.
+
 Parity targets use the same connection grammar:
 
 ```text
@@ -77,6 +96,8 @@ Suite-level YAML fields have direct equivalents:
 
 ```text
 Default timeout: 10 seconds
+Budget: p95 500ms over 20 calls
+Budget for "order lookup": p50 300ms over 20 calls
 Redact: "secret-value", "token-value"
 Snapshots: snapshots.json
 Ignore snapshot paths: "$.createdAt", "$.requestId"
@@ -94,11 +115,7 @@ Client behavior:
       approved: true
 ```
 
-## Imports
-
-```
-
-Per-test scripted responses (override `Client behavior:` for one test):
+Per-test scripted responses override `Client behavior:` for one test:
 
 ```text
 When the server asks for input, respond "accept" with:
@@ -106,7 +123,10 @@ When the server asks for input, respond "accept" with:
 When the server asks for input, respond "decline"
 When the server requests sampling, respond "scripted text"
 ```
-text
+
+## Imports
+
+```text
 Import flows from "./shared/customer-flows.mcpr"
 ```
 
@@ -183,6 +203,7 @@ Send "ping"
 ```text
 Expect it succeeds
 Expect an error
+Expect the call to finish within 800ms
 Expect "structuredContent.total" equals 2
 Expect "content[0].text" contains "complete"
 Expect "items" exists

package/docs/MONITORING.md

@@ -0,0 +1,62 @@
+# Scheduled production monitoring
+
+> Available since `1.5.0`.
+
+Turn an HTTP MCP suite into a continuous production check:
+
+```bash
+mcprigor monitor tests/prod.mcpr \
+  --every 15m \
+  --notify https://alerts.example.com/hooks/mcprigor
+```
+
+The monitor runs immediately, then at the fixed interval until stopped. Durations accept `ms`, `s`, `m`, or `h`, with a minimum interval of one second.
+
+For operational safety, monitoring requires a Streamable HTTP target. It refuses stdio suites so a long-running process cannot repeatedly spawn local commands by accident.
+
+## Notification policies
+
+```bash
+mcprigor monitor tests/prod.mcpr --every 5m --notify URL --notify-on change
+```
+
+`--notify-on` supports:
+
+- `change` (default): first failure, then failure/recovery transitions;
+- `failure`: every failed run;
+- `recovery`: transitions from failed to passed;
+- `always`: every run.
+
+Webhook requests are JSON POSTs with a 15-second timeout:
+
+```json
+{
+  "source": "mcprigor",
+  "event": "monitor.failure",
+  "suite": "tests/prod.mcpr",
+  "run": 12,
+  "status": "failed",
+  "startedAt": "2026-08-30T12:00:00.000Z",
+  "durationMs": 842,
+  "summary": { "passed": 7, "failed": 1, "skipped": 0, "blocked": 0 },
+  "failures": [{ "name": "order lookup", "error": "..." }]
+}
+```
+
+A non-2xx webhook response fails the monitor with `MCP-MONITOR-003`; notification loss is never silently ignored.
+
+## History and trends
+
+Every monitoring run appends to `.mcprigor/workspace-history.jsonl`, so existing `mcprigor trends`, PDF/CSV exports, flaky detection, latency budgets, and regression analysis include production monitoring evidence.
+
+## Bounded runs
+
+For smoke tests, cron jobs, and CI validation:
+
+```bash
+mcprigor monitor tests/prod.mcpr --every 1m --max-runs 1
+```
+
+`SIGINT` and `SIGTERM` stop the interval cleanly after active MCP sessions shut down.
+
+Use an authenticated suite target (`headers` or `Token from:`), retain history according to your evidence policy, and send webhooks only to reviewed HTTPS endpoints.

package/docs/MULTI-SERVER-COMPOSITIONS.md

@@ -0,0 +1,103 @@
+# Multi-server compositions
+
+> Available since `1.5.0`.
+
+Real MCP clients mount several servers together. MCP Rigor compositions test each named server and govern the combined tool, resource, and prompt namespace as one fleet.
+
+## Declare named servers
+
+```text
+MCP Test 1
+Suite: "Checkout fleet"
+
+Named server "catalog": node services/catalog.js
+Named server "billing": https://qa.example.com/billing/mcp
+
+Server options for "billing":
+  Token from: node scripts/get-qa-token.mjs
+
+Test: "catalog search works"
+  On server "catalog"
+  Call tool "search" with:
+    query: "widget"
+  Expect "structuredContent.total" is a number
+
+Test: "billing responds"
+  On server "billing"
+  Send "ping"
+  Expect it succeeds
+```
+
+`On server` routes every action in that test to the selected server. Tests without `On server` continue to use the legacy/default `Server:` or `MCP URL:` target. Cross-test dependencies and exported values continue to work across named servers.
+
+YAML parity:
+
+```yaml
+version: 1
+name: Checkout fleet
+target:
+  transport: stdio
+  command: node
+  args: [services/gateway.js]
+servers:
+  catalog:
+    transport: stdio
+    command: node
+    args: [services/catalog.js]
+  billing:
+    transport: streamable-http
+    url: https://qa.example.com/billing/mcp
+tests:
+  - name: catalog search works
+    server: catalog
+    steps:
+      - tool:
+          name: search
+          arguments: { query: widget }
+```
+
+Unknown server names fail validation before a test starts.
+
+## Check the live composition
+
+```bash
+mcprigor composition-check tests/fleet.mcpr
+```
+
+The check discovers all named servers and reports:
+
+- `MCP-COMP-001`: duplicate tool name;
+- `MCP-COMP-002`: conflicting input/output schemas for the same tool (breaking);
+- `MCP-COMP-003`: duplicate resource URI or URI template (breaking);
+- `MCP-COMP-004`: duplicate prompt name.
+
+MCP Rigor reports collisions; it never silently renames or chooses a winning server.
+
+## Create a combined fleet lock
+
+```bash
+mcprigor composition-discover tests/fleet.mcpr \
+  --out contracts/checkout.composition.lock.yaml
+```
+
+The lock embeds each named server's ordinary discovery contract, the cross-server issue set, and a stable fleet fingerprint. Volatile discovery timestamps and diagnostics do not change the combined fingerprint. Writes are atomic: all servers must be discovered successfully before the previous lock is replaced.
+
+## Gate fleet drift in CI
+
+```bash
+mcprigor composition-drift tests/fleet.mcpr \
+  --against contracts/checkout.composition.lock.yaml \
+  --fail-on breaking
+```
+
+The drift report combines:
+
+- server additions and removals;
+- each server's tool/resource/prompt contract changes;
+- newly introduced or resolved cross-server conflicts.
+
+`--fail-on` accepts `breaking` (default), `potentially-breaking`, `any`, or `none`, matching the single-server drift gate. Add `--json report.json` for machine-readable CI evidence.
+
+## Composition versus parity
+
+Use a **composition** when several servers are mounted together and their namespaces interact. Use **transport parity** when the same logical server is exposed through alternate targets such as local stdio and deployed HTTP. The `servers` and `targets` fields remain intentionally separate.

package/docs/PERFORMANCE-GOVERNANCE.md

@@ -0,0 +1,85 @@
+# Performance governance
+
+> Available since `1.5.0`.
+
+MCP Rigor turns MCP latency into a deterministic release gate. It supports immediate per-call limits, percentile budgets over recorded history, and automatic regression detection against each test's historical baseline.
+
+## Limit one call
+
+Add a latency assertion after an action:
+
+```text
+Test: "order lookup stays interactive"
+  Call tool "find_order" with:
+    orderId: "A-1001"
+  Expect the call to finish within 800ms
+```
+
+The measured duration covers the live MCP request and response. A call over the limit fails with `MCP-PERF-001` and reports the measured and allowed duration.
+
+YAML parity:
+
+```yaml
+- tool:
+    name: find_order
+    arguments:
+      orderId: A-1001
+  assert:
+    maxDurationMs: 800
+```
+
+## Set percentile budgets
+
+A percentile budget uses successful durations from recent recorded runs plus the current run:
+
+```text
+Budget: p95 500ms over 20 calls
+Budget for "order lookup stays interactive": p50 300ms over 20 calls
+```
+
+- A suite-wide budget applies independently to every test.
+- A named budget applies only to that test.
+- MCP Rigor uses the deterministic nearest-rank percentile.
+- Fewer than three usable samples reports the budget as pending instead of guessing.
+- A measured percentile over budget fails the CLI run.
+
+YAML parity:
+
+```yaml
+budgets:
+  - test: "*"
+    percentile: 95
+    maxMs: 500
+    window: 20
+  - test: order lookup stays interactive
+    percentile: 50
+    maxMs: 300
+    window: 20
+```
+
+## Fail on regression without maintaining thresholds
+
+```bash
+mcprigor test tests/orders.mcpr --fail-on-regression
+```
+
+For every successful test, MCP Rigor compares the current duration with the median of its latest successful history. The gate requires at least five samples and reports a regression when the current run exceeds both:
+
+- 1.5× the historical median; and
+- the historical median plus 50 ms.
+
+The absolute floor prevents very small tests from failing because of ordinary scheduler jitter.
+
+## CI example
+
+```yaml
+- run: npx mcprigor test tests/orders.mcpr --fail-on-regression --junit reports/orders.xml
+```
+
+Explicit budgets answer “is this fast enough?” The regression gate answers “did this release make it materially slower?” Teams commonly use both.
+
+## History source
+
+CLI, QA workspace, and MCP-server-driven test runs append to `.mcprigor/workspace-history.jsonl`. The same data powers `mcprigor trends`, CSV/PDF trend exports, flaky detection, percentile budgets, and regression baselines.
+
+Commit the test and its budget declarations. Treat history as a CI artifact or retained workspace file according to your evidence policy.

package/docs/PLAIN-LANGUAGE-COOKBOOK.md

@@ -302,6 +302,34 @@ Test: "summaries embed the sampled text"
 
 Suite-wide defaults live in a `Client behavior:` block; these per-test lines override them for one test.
 
+## Set latency budgets and catch slow releases
+
+Fail a single call that takes too long:
+
+```text
+Test: "order lookup is fast"
+  Call tool "find_order" with:
+    orderId: "A-1001"
+  Expect the call to finish within 800ms
+```
+
+Set suite-level budgets measured as percentiles over recorded run history (the same history behind `mcprigor trends`):
+
+```text
+Budget: p95 500ms over 20 calls
+Budget for "order lookup is fast": p50 300ms
+```
+
+Budgets are judged after each `mcprigor test` run and fail the run when a percentile exceeds its budget. Until enough history exists they report as pending instead of guessing.
+
+Gate CI on latency regressions against the trend baseline — no budget numbers needed:
+
+```bash
+mcprigor test suite.mcpr --fail-on-regression
+```
+
+A test regresses when it runs slower than 1.5x its historical median (with a 50 ms floor so micro-tests don't trip on jitter).
+
 ## Match a snapshot
 
 ```text

package/docs/PUBLISHING.md

@@ -0,0 +1,53 @@
+# Shareable hosted reports
+
+> Available since `1.5.0`.
+
+Turn a test run into a URL anyone can open — no repository access, no CI login:
+
+```bash
+export NETLIFY_AUTH_TOKEN=...   # personal or CI token
+mcprigor publish tests/catalog.mcpr --site your-netlify-site
+```
+
+`publish` runs the suite, builds the readable HTML report **with the clickable request/response session timeline**, deploys it to your Netlify site with the dependency-free digest API, waits until the deploy is live, and prints the shareable URL:
+
+```
+Published report: https://68b1c2--your-site.netlify.app
+```
+
+Each publish is a normal Netlify deploy of your own site, so access control, custom domains, deploy previews, and retention follow your existing hosting configuration. Unchanged files are skipped automatically via content digests.
+
+## Options
+
+```bash
+mcprigor publish suite.mcpr --site SITE [--include-json] [--test NAME] [--env qa]
+mcprigor publish suite.mcpr --out reports/latest
+```
+
+- `--site` — Netlify site ID or name. The token comes only from `NETLIFY_AUTH_TOKEN` (or `MCPRIGOR_PUBLISH_TOKEN`); tokens are never accepted as command-line flags.
+- `--out DIR` — write the same bundle to a local directory instead of (or in addition to) hosting it. Serve it from any static host: S3, GitHub Pages, nginx, an artifact store.
+- `--include-json` — also publish `result.json` for dashboards and programmatic consumers.
+- `--test`, `--env`, `--command`, `--url` — the same run-selection options as `mcprigor test`.
+
+The exit code still reflects the run (`0` passed, `1` failed), so `publish` can replace `test` in a pipeline step that both gates and shares.
+
+## Publishing from the QA workspace UI
+
+The visual workspace (`mcprigor workspace`) exposes the same features without the command line:
+
+- **HTML report** — every finished test run has an `HTML report` button that opens the full report, including the clickable session timeline, in a new tab.
+- **Publish** — start the workspace with hosting configured and a `Publish` button appears next to the export buttons:
+
+  ```bash
+  export MCPRIGOR_PUBLISH_SITE=your-netlify-site
+  export NETLIFY_AUTH_TOKEN=...
+  mcprigor workspace
+  ```
+
+  Clicking it deploys the selected run's report and opens the shareable URL; a `View published ↗` link stays on the run for re-opening or copying. Without both variables the button is hidden and the API answers with a clear configuration message — the token itself never reaches the browser.
+
+## Security
+
+- The report is produced by the same pipeline as `--html`: secrets and configured redaction patterns are removed **before** the report exists.
+- Publishing makes the report as public as the target site. Use a password-protected or team-restricted Netlify site for internal results.
+- The hosting token is read from the environment at the last moment and is never echoed, logged, or stored.

package/docs/QA-WORKSPACE.md

@@ -30,7 +30,7 @@ An empty folder shows a three-step welcome screen. Choose **＋ New test file**
 2. Edit the plain-language scenario. The editor provides syntax highlighting, line numbers, and autocomplete: top-level declarations at the start of a line, actions and assertions when indented, and comparison phrases after `Expect "field"`. Accept with `Tab` or `Enter`; force the list open with `Ctrl+Space`.
 3. Choose **Validate** (`Ctrl/⌘+S` saves, `Ctrl/⌘+Enter` runs). A wording problem highlights the offending line and moves the cursor to it.
 4. Choose **▶ Run tests** or **Parity**.
-5. Review the results panel: per-file pass/fail with durations; select a file for its full report.
+5. Review the results panel: per-file pass/fail with durations; select a file for its full report. Drag either panel divider to resize the file list, editor, and results areas; widths persist across reloads, arrow keys resize a focused divider, and double-click resets the layout.
 
 The editor marks unsaved changes; running or validating saves them first. If the file changed elsewhere after you opened it, the workspace refuses to overwrite it and asks you to reload.
 
@@ -52,6 +52,10 @@ Test runs are recorded in `.mcprigor/workspace-history.jsonl` (most recent 2000
 
 One search box filters all three tabs. It matches suite names, test names, and error text, and highlights matches, so you can answer questions like "when did `delivered` start failing?" without leaving the browser.
 
+Completed runs expose **PDF**, **CSV**, and **JUnit XML** downloads. The Trends tab exports a rich trends PDF, aggregate CSV, or raw history CSV. PDF reports include summary cards, pass-rate visuals, per-test detail, failures, durations, and evidence identifiers.
+
+An **HTML report** button opens the full report — including the clickable request/response session timeline — in a new tab. When the workspace is started with `MCPRIGOR_PUBLISH_SITE` and `NETLIFY_AUTH_TOKEN` set, a **Publish** button also appears: one click hosts the report at a shareable static URL and keeps a `View published ↗` link on the run. See [Shareable hosted reports](PUBLISHING.md).
+
 ## What is available
 
 - Creating, renaming, and editing `.mcpr` suites (YAML and JSON suites are listed and editable too)

package/docs/README.md

@@ -18,6 +18,12 @@ Choose the path that matches your role.
 - [State and dependencies](STATE-AND-DEPENDENCIES.md) — share outputs across tests and runs.
 - [Data engineering](DATA-ENGINEERING.md) — types, filters, joins, samples, and caches.
 - [Transport parity](TRANSPORT-PARITY.md) — compare stdio and Streamable HTTP.
+- [Performance governance](PERFORMANCE-GOVERNANCE.md) — call limits, percentile budgets, and regression gates.
+- [Multi-server compositions](MULTI-SERVER-COMPOSITIONS.md) — route tests across a fleet and gate combined drift.
+- [Coverage](COVERAGE.md) — find untested MCP surfaces and input-schema branches.
+- [Scheduled monitoring](MONITORING.md) — continuously test production HTTP endpoints and notify webhooks.
+- [GitHub Action](GITHUB-ACTION.md) — test, drift, flaky warnings, and rich pull-request comments.
+- [Shareable hosted reports](PUBLISHING.md) — `mcprigor publish` turns a run into a static report URL.
 
 ## Contracts and evidence
 
@@ -30,6 +36,7 @@ Choose the path that matches your role.
 
 - [Extension SDK](EXTENSION-SDK.md)
 - [Stable error model](ERROR-MODEL.md)
+- [Deterministic security audit](SECURITY-AUDIT.md) — built-in probe pack, severity gate, and rich reports.
 - [Security and retention](SECURITY-AND-RETENTION.md)
 - [Compatibility policy](COMPATIBILITY.md)
 

package/docs/SECURITY-AUDIT.md

@@ -0,0 +1,77 @@
+# Deterministic security audit
+
+> Available since `1.5.0`.
+
+`mcprigor audit` runs a fixed security and permissions probe pack against an MCP server and produces an auditable score. No AI chooses payloads or interprets outcomes.
+
+## Run the safe default pack
+
+Use a suite's configured target:
+
+```bash
+mcprigor audit tests/server.mcpr
+```
+
+Or supply a target directly:
+
+```bash
+mcprigor audit --url https://qa.example.com/mcp
+mcprigor audit --command "node dist/server.js"
+```
+
+The non-destructive default probes:
+
+| Probe | What MCP Rigor verifies |
+|---|---|
+| Malformed parameters | Invalid `tools/call` parameters are rejected |
+| Tool-name spoofing | An unknown administrative-looking tool cannot be invoked |
+| Oversized payload | A deterministic 1 MiB payload is rejected |
+| Path traversal | Resource reads reject Unix, Windows, and relative traversal URIs |
+| Tool inventory | Advertised tools are listed for opt-in injection/canary testing |
+
+## Opt into reviewed tool calls
+
+MCP Rigor never guesses that a tool is safe. Tool execution is disabled unless you allow an exact name:
+
+```bash
+mcprigor audit tests/server.mcpr \
+  --allow-tool search \
+  --allow-tool summarize
+```
+
+Only allow read-only, non-destructive tools in a disposable test environment. An allowed tool receives a fixed prompt-injection payload containing a deterministic canary. MCP Rigor checks whether the response follows or reflects the payload and whether it exposes the canary. Report evidence replaces the canary with `[CANARY REDACTED]`.
+
+## CI severity gate
+
+```bash
+mcprigor audit tests/server.mcpr --fail-on high
+```
+
+Values are `critical`, `high`, `medium`, `low`, and `none`; the default is `high`. The command exits nonzero when a failed finding meets or exceeds the selected severity.
+
+Scoring starts at 100:
+
+- critical: −35
+- high: −20
+- medium: −10
+- low: −4
+- skipped: no deduction
+
+Skipped probes remain visible with the exact `--allow-tool` needed. They are not represented as passes.
+
+## Reports
+
+```bash
+mcprigor audit tests/server.mcpr \
+  --pdf reports/security.pdf \
+  --json reports/security.json \
+  --csv reports/security.csv
+```
+
+The rich PDF includes score, grade, severity cards, per-finding status, explanations, and bounded evidence. Markdown output is available with `--markdown`.
+
+## Interpreting results
+
+The audit is deterministic black-box evidence, not a certification or a replacement for threat modeling. A passing probe proves the observed server rejected that exact payload under that exact configuration. Review skipped probes, environment permissions, downstream model behavior, and business authorization separately.
+
+Run intrusive tool probes only in an isolated environment. Do not expose production mutation tools through `--allow-tool`.

package/editors/mcpr-language.json

@@ -12,11 +12,11 @@
       "name": "keyword.control.version.mcpr"
     },
     {
-      "match": "^\\s*(Suite|Server|Server options|MCP URL|Compare target|Target options for|Default timeout|Redact|Snapshots|Ignore snapshot paths|Client behavior|Import flows from|Flow|Inputs|Outputs|Test|Scenario|Id|Depends on|Require|Require protocol|Variables|Skip|Setup|Steps|Cleanup|Data source):?",
+      "match": "^\\s*(Suite|Server|Named server|Server options|Server options for|MCP URL|Compare target|Target options for|Default timeout|Budget|Redact|Snapshots|Ignore snapshot paths|Client behavior|Import flows from|Flow|Inputs|Outputs|Test|Scenario|Id|Depends on|Require|Require protocol|Variables|Skip|Setup|Steps|Cleanup|Data source):?",
       "name": "keyword.control.mcpr"
     },
     {
-      "match": "^\\s*(Call tool|When the server asks for input|When the server requests sampling|Read resource|Get prompt|Send|Expect|Save|Export|Set|Use flow|For each row|Wait up to|Wait for notification|Subscribe to resource|Unsubscribe from resource|Set log level|List all|Get task|List tasks|Cancel task|From CSV|From JSON|From YAML|From Excel|From REST|Column|Derive|Keep rows where|Sample|Cache this source)\\b",
+      "match": "^\\s*(Call tool|On server|When the server asks for input|When the server requests sampling|Read resource|Get prompt|Send|Expect|Save|Export|Set|Use flow|For each row|Wait up to|Wait for notification|Subscribe to resource|Unsubscribe from resource|Set log level|List all|Get task|List tasks|Cancel task|From CSV|From JSON|From YAML|From Excel|From REST|Column|Derive|Keep rows where|Sample|Cache this source)\\b",
       "name": "keyword.other.mcpr"
     },
     {

package/editors/vscode/package.json

@@ -2,7 +2,7 @@
   "name": "mcprigor",
   "displayName": "MCP Rigor",
   "description": "Syntax highlighting and inline validation for MCP Rigor (.mcpr) natural-language MCP test suites.",
-  "version": "1.3.0",
+  "version": "1.4.0",
   "publisher": "fusionone",
   "license": "Apache-2.0",
   "repository": { "type": "git", "url": "https://github.com/FusionOnePlatform/mcprigor" },

package/editors/vscode/syntaxes/mcpr.tmLanguage.json

@@ -12,11 +12,11 @@
       "name": "keyword.control.version.mcpr"
     },
     {
-      "match": "^\\s*(Suite|Server|Server options|MCP URL|Compare target|Target options for|Default timeout|Redact|Snapshots|Ignore snapshot paths|Client behavior|Import flows from|Flow|Inputs|Outputs|Test|Scenario|Id|Depends on|Require|Require protocol|Variables|Skip|Setup|Steps|Cleanup|Data source):?",
+      "match": "^\\s*(Suite|Server|Named server|Server options|Server options for|MCP URL|Compare target|Target options for|Default timeout|Budget|Redact|Snapshots|Ignore snapshot paths|Client behavior|Import flows from|Flow|Inputs|Outputs|Test|Scenario|Id|Depends on|Require|Require protocol|Variables|Skip|Setup|Steps|Cleanup|Data source):?",
       "name": "keyword.control.mcpr"
     },
     {
-      "match": "^\\s*(Call tool|When the server asks for input|When the server requests sampling|Read resource|Get prompt|Send|Expect|Save|Export|Set|Use flow|For each row|Wait up to|Wait for notification|Subscribe to resource|Unsubscribe from resource|Set log level|List all|Get task|List tasks|Cancel task|From CSV|From JSON|From YAML|From Excel|From REST|Column|Derive|Keep rows where|Sample|Cache this source)\\b",
+      "match": "^\\s*(Call tool|On server|When the server asks for input|When the server requests sampling|Read resource|Get prompt|Send|Expect|Save|Export|Set|Use flow|For each row|Wait up to|Wait for notification|Subscribe to resource|Unsubscribe from resource|Set log level|List all|Get task|List tasks|Cancel task|From CSV|From JSON|From YAML|From Excel|From REST|Column|Derive|Keep rows where|Sample|Cache this source)\\b",
       "name": "keyword.other.mcpr"
     },
     {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mcprigor",
-  "version": "1.3.1",
+  "version": "1.5.0",
   "description": "Plain-language MCP testing with isolated extensions and a local QA workspace",
   "type": "module",
   "bin": {