Fmeca

What the fmeca MCP server does

The fmeca MCP server structures Failure Modes, Effects & Criticality Analysis (FMECA) for an MCP client. It accepts failure modes, causes, effects, observations, and mitigations, then derives severity, probability, criticality, residual risk, standing, and readiness from fixed rules. The caller supplies domain observations rather than numeric scores, so the scoring result is computed by the engine.

Analyses can be handled as persistent sessions or as one-shot requests. Session workflows preserve an append-only event log and support resuming, state inspection, risk prioritization, readiness assessment, and report export. The stateless analyze operation returns a complete computed report without creating a session or persisting data.

How it works

A strategy provides a fixed catalog of observation identifiers. The caller selects observations such as evidence about data loss or normal-use frequency, and the engine maps them to severity and probability levels. Criticality is then read from the selected fixed severity-by-probability matrix. Computed values are folded from the event history rather than accepted as caller-provided scores.

Mitigations can be added and moved through planned, implemented, verified, or abandoned states. Verification requires evidence beyond a note. Failure modes can be accepted with an approver or excluded as not credible with supporting evidence; they are not deleted. risk.next identifies the highest-criticality unmitigated failure mode, while readiness.assess checks whether High and Medium residual risks have been reduced and blockers cleared.

The core engine is deterministic and offline, with no model execution or network calls for normal analysis. The vet operation is an exception: it sends an advisory request to Jev through OpenRouter when OPENROUTER_API_KEY is available. Its probabilities supplement the deterministic gate and do not modify scores or analysis state.

Setup and configuration

The server communicates over stdio and can be launched with the npm package, a prebuilt platform binary, Docker, or a Rust installation/build. The npm launcher downloads and runs a matching release binary. Prebuilt releases are provided for Linux, macOS, and Windows on the listed x86_64 and arm64 targets. Docker users should mount the project directory if analyses need to survive container exit.

Configure an MCP client with the server command, such as npx -y @matthew-cochran/fmeca, or use the installed fmeca-mcp binary. Cursor requires the stdio type in its configuration. Codex uses TOML configuration. The optional OPENROUTER_API_KEY enables vet; it is not needed for deterministic analysis. FMECA_STATE_DIR can point the server at a project state directory, commonly .fmeca.

Tools and capabilities

The fmeca MCP server exposes tools for:

• Opening or resuming sessions and recording fixed analysis metadata.
• Appending failure modes, mitigations, rescoring events, and status changes.
• Reading computed state, exporting the FMECA table, and listing stored analyses.
• Inspecting scoring catalogs and identifying the next unmitigated risk.
• Assessing readiness and suggesting policy-based actions without mutation.
• Reviewing observations and coverage through the optional advisory vetting operation.
• Running a complete non-persistent analysis with analyze.

session.list can filter analyses by level, aspect, or parent and reports replay errors rather than hiding logs that cannot be read. policy.list exposes built-in policies and project policy files with their names, hashes, classes, and loading errors.

Limitations and notes

The engine does not provide domain judgment or accept caller-supplied numeric scores. Agents and users must choose observations, describe failure modes, and propose mitigations. Readiness is a computed gate, not an approval workflow; accepted residual risks and exclusions require the stated approver or evidence fields.

Persistent session state depends on the event log and configured state directory. Container deployments without a mounted state directory lose analyses when the container exits. The optional vet capability depends on OpenRouter access and reports vet_unavailable without its key; it does not replace the deterministic calculations.