vouchfx-mcp

A native vouchfx toolbelt for AI agents.

A local stdio Model Context Protocol server that wraps the packaged vouchfx CLI — eighteen tools, two documentation resources, and an error-catalogue resource family, so an agent works with .e2e.yaml integration-test suites directly, instead of shelling out and parsing console output by hand.

Wraps the published vouchfx CLI pinned in ENGINE_PIN · current engine release v1.0.0-rc.5 · early prerelease — feature-complete, not yet published to NuGet.org

Everything a call away

Eighteen tools. No shelling out, no scraping output.

Every tool returns a structured result — success or a typed failure — so an agent never has to parse free-form text to know what happened.

validate_suite

Validates an .e2e.yaml suite against the engine's JSON Schema, without running it. Runs isolated in a killable child process.

list_step_types

Lists all 25 Core provider step types, grouped by family — derived straight from the embedded schema.

describe_step_type

Returns one step type's full required/optional field contract.

search_docs

Free-text search over the vendored language reference and recipes, with deep links to vouchfx.io.

plan_coverage

Runs the engine's Planner: a read-only coverage-and-gap analysis over a declared suite set and event history. Every gap finding carries a suggested step type/id for scaffold_suite.

scaffold_suite

Generates a machine-drafted, schema-valid .e2e.yaml skeleton from structured step types and ids — never free text.

run_suite

Runs a suite through the installed vouchfx CLI and reports its taxonomy-faithful verdict — pass / fail / environment error / inconclusive.

explain_run

Diagnoses a completed run purely by reading its JSON Lines event stream — never re-running anything.

diagnose_run

Adds Fail-only Healer patch proposals to a run's diagnosis. Environment errors get infrastructure guidance only, never a YAML rewrite — proposals are never auto-applied.

explain_diagnostic

Looks up one catalogued VFX-D-####/VFX-E-#### code and returns its title, explanation, common causes, and fixes — fully offline, no CLI required.

get_schema

Returns the language's own composed JSON Schema — the whole document, one section, or one step type — as a schema document or a capped markdown digest. Offline-first; cross-verified against the pinned CLI when one is installed.

normalize_suite

Returns a suite's canonical formatting — schema-derived key order, one quoting and layout style — alongside its full validation result. The server never writes the file; your host decides whether and where to. Comments are dropped, so it is opt-in.

get_run_events

Pages a run's raw JSON Lines events exactly as the engine wrote them — wire tokens, unknown fields and all — filtered by type and step before paging, with an opaque cursor. Build your own timeline instead of consuming a summary.

get_run_status

One run's current lifecycle state from the persisted registry — status, verdict, timestamps, the suites it covered, its event stream and its labels. The same record the diagnosis tools resolve a runId through, so it can never disagree with them.

cancel_run

Stops an in-flight run through exactly the mechanism run_suite already uses — stdin closed for a graceful engine shutdown, force-kill only after the grace period. A cancelled run is Inconclusive, never Fail.

list_runs

Pages the run registry newest first, filtered by label or start time, with the same opaque cursor contract get_run_events uses. Find a runId you no longer hold, or correlate runs by whatever triggered them.

get_step_timeline

One step's complete RETRY attempt timeline, from the same event stream explain_run reads. Where explain_run's size tiers throw the attempt list away first, this one keeps every attempt and drops evidence text instead.

get_run_artifacts

What a finished run left behind: its event-stream artefact, plus whatever environment resources the run's own events named. Honestly partial — every result says which fields are still gated on the engine's artifacts directory, and why.

Plus two documentation resources and an error catalogue

The engine's own docs, vendored byte-exact.

Read directly as MCP resources. The language reference and recipes are also searchable through search_docs; the error catalogue is also reachable through explain_diagnostic.

Get started

Install it, register it, run a suite.

No arguments or environment variables to configure — the server locates its own engine pin and vendored documentation relative to wherever it is installed.

Honest status

Not a black box. A typed result for every call.

18/18 tools real, not stubs — every one exercises the actual vouchfx schema, CLI, or vendored/catalogue docs
4 taxonomy verdicts kept distinct everywhere — pass / fail / environment error / inconclusive, never conflated
1 engine version this build is pinned to in ENGINE_PIN — a mismatch is always reported, never silently ignored

Install it. Register it. Let your agent run a suite.

Eighteen tools, two vendored documentation resources, an error-catalogue resource family, one taxonomy-faithful verdict every time.