Skip to content

MCP server

executable-stories-mcp exposes StoryReport v1 JSON to MCP-capable coding agents. Read-only tools query the last test run; run_scenario optionally re-executes one scenario through the host framework.

Generate agent artifacts first:

Terminal window
pnpm test
executable-stories format reports/raw-run.json \
--format story-report-json,scenario-index-json,behavior-manifest-json \
--output-dir reports \
--output-name index

Default MCP input path:

reports/index.story-report.json

See Agent artifact contract for the full CI recipe.

Terminal window
pnpm add -D executable-stories-mcp executable-stories-formatters
Terminal window
npx executable-stories-mcp

The server uses stdio transport (standard for Cursor, Claude Desktop, and similar hosts).

{
"mcpServers": {
"executable-stories": {
"command": "npx",
"args": ["executable-stories-mcp"],
"cwd": "/path/to/your/project"
}
}
}

Ensure reports/index.story-report.json exists in cwd, or pass reportPath on each tool call.

ToolPurpose
list_scenariosScenarios with status, tags, steps, doc kinds. Optional statuses / tags / sourceFiles filters
get_scenarioOne scenario by id or exact title
get_failing_scenariosFailed scenarios only
get_scenarios_for_pathsScenarios whose declared covers globs match given product-code paths (e.g. a changed-file list)
get_feature_summaryPer-feature pass/fail counts
get_scenario_indexFull scenario-index v1 artifact
get_behavior_manifestTags, source files, doc coverage, debugger warnings (incl. missing-covers)
get_behavior_diffCompare two StoryReports by scenario id: regressed / fixed / added / removed
get_deployment_statusLatest recorded deployment per environment from the deployment ledger
get_environment_driftScenarios only in one environment plus status drift for shared scenarios

Scenarios declare which product code they exercise via a covers option (globs, project-root-relative), e.g. story.init(task, { covers: ["src/auth/**"] }). get_scenarios_for_paths inverts that: give it the files you’re editing, get back the behavior at risk. This works identically across every language adapter, since covers travels through the StoryReport contract.

ToolPurpose
run_scenarioRun one scenario via vitest, jest, playwright, or cypress

run_scenario accepts:

  • idOrTitle — lookup from StoryReport
  • framework — optional; inferred for .story.spec.ts (playwright) and .story.cy.ts (cypress)
  • cwd — project root for the test command (defaults to server cwd)
  • reportPath — optional StoryReport path

Returns exit code, stdout, stderr, and the resolved command.

For non-MCP clients or local debugging, the same read-only catalog and run_scenario are available over HTTP. This is a programmatic API — the executable-stories-mcp binary itself only speaks stdio.

import { startHttpServer } from "executable-stories-mcp/http";
await startHttpServer({
reportPath: "reports/index.story-report.json",
port: 7357, // default
host: "127.0.0.1", // default
});

Endpoints (each maps to the matching MCP tool):

Method & pathTool equivalent
GET /health— (liveness check)
GET /scenarios (optional ?status=&tag=&sourceFile=)list_scenarios
GET /scenarios/failingget_failing_scenarios
GET /scenarios/covering?path=…get_scenarios_for_paths
GET /scenarios/:idget_scenario
GET /scenarios-indexget_scenario_index
GET /featuresget_feature_summary
GET /manifestget_behavior_manifest
GET /diff?baseline=&current=get_behavior_diff
POST /run-scenariosrun_scenario

Every GET accepts a ?reportPath= query parameter; POST /run-scenarios takes a JSON body of { framework, sourceFile, scenarioTitle?, cwd? }.

  1. Run framework tests and emit StoryReport + index in CI or locally
  2. Point MCP at the report
  3. get_failing_scenarios or get_behavior_manifest for triage
  4. get_scenario for steps, docs, errors, source links
  5. run_scenario to verify a fix (optional)
  6. Full test run + regenerate artifacts

Storybook MCP indexes components; executable-stories indexes behavior scenarios with execution truth.

For release and branch workflows, pair get_behavior_diff with deployment tools. Agents can answer whether dev and production contain the same behavior scenarios, whether shared scenarios have different statuses, and what changed between a dev baseline and a release candidate. See Release confidence.