Concepts
Mend finds manifest faults in your MCP server, drafts a fix, tests it on live traffic, and carries the winner until you ship it upstream.
Mend is the part of Spanly that fixes MCP manifest problems. Spanly
already sits in-line on your JSON-RPC stream through the SDK or CLI you
run in front of your server. Mend uses that position to rewrite
tools/list responses: when a scanner finds a manifest-fixable fault, it
drafts a fix, serves it to a slice of sessions as a live A/B test, checks
that nothing regressed, and promotes the winner. The promoted fix rides
on the wire until you ship the same change in your own source.
Everything Mend can do is deliberately narrow. It only ever clarifies or
tightens what a client is told about your tools. It never renames a tool,
removes a tool, loosens a schema, or touches a tools/call. If anything
about Mend fails, your original manifest is served untouched. Those
guarantees are the whole point, and they are spelled out on the
Trust and safety page.
The loop
Mend runs one loop, from a scanner finding to a fix you own:
probes -> faults -> patches -> canaries -> shims -> upstreamProbes
Probes are the scanner checks, static and live, that watch your server.
They are the same checks that power the Faults view. A probe describes a
manifest problem worth fixing, for example a parameter with no
description, a missing outputSchema, or a schema looser than the
arguments your tools actually receive.
Probes only observe. They open and close faults. They never change what is served.
Faults
A fault is a single scanner result: one problem on one tool, on one version of your manifest. (Faults were previously called Findings in the product; the concept is unchanged.) A fault carries a severity and, where Mend can help, a suggested patch.
A fault records what is wrong. It does not change anything on its own.
Patches
A patch is a candidate fix: a small list of typed overlay operations against exactly one version of your manifest. A patch is authored against a specific manifest content hash and is only ever applied to that version (see manifest-hash anchoring on the Trust and safety page). Every operation is client-facing only, so a patch can set a description, add an annotation hint, tighten a parameter schema, mark a parameter required, or set an output schema, and nothing else.
A patch is validated by re-scanning against it before it goes anywhere. A patch that does not clear validation is rejected and never served.
Canaries
A canary is a live A/B test of one patch. Sessions are split into a Baseline arm (your original manifest) and a Candidate arm (the patch applied), bucketed deterministically by session. Mend measures the fault's own metric plus a set of always-on guardrail gates, and reaches a verdict as early as the data allows.
A canary measures. It does not decide policy: a passing verdict makes a patch eligible to promote, but whether promotion is automatic depends on your environment mode.
Shims
A shim is a promoted patch being carried on the wire. Once a canary concludes in favor of the candidate and the patch is promoted, it serves to every session at 100 percent. A shim is a stopgap: it makes clients see the better manifest while you still run the old one.
A shim changes only the tools/list response. It does not change your
server, and it stays anchored to the manifest version it was written for.
Upstream
Upstreaming is you shipping the same fix in your own source. When your
server starts serving the improved manifest itself, Mend detects it on
the next scan, retires the shim, and resolves the fault as
fixed_at_source. The wire goes back to pure pass-through for that fix,
because your server now does the right thing on its own. The
Upstreaming guide walks through reading the
diff and applying it.
Glossary
These terms are used consistently across the product and these docs.
| Term | Meaning |
|---|---|
| Probe | A scanner check, static or live. The watchers. |
| Fault | A scanner result (called Finding in older copy). |
| Patch | A candidate fix: a list of typed overlay operations against one manifest version. |
| Canary | A live A/B of a patch: Baseline arm against Candidate arm, split by session. |
| Gates | Always-on guardrail metrics a canary must not degrade. |
| Rollback | Automatic, immediate revert when a gate is breached. |
| Promoted | Canary verdict accepted; the patch serves at 100 percent. |
| Shim | A promoted patch carried on the wire, awaiting upstream. |
| Upstream | You ship the fix in your source; the shim retires. |
| Pulse | The Spanly-Pulse response header that keeps collectors in sync with delivery state. |
| Delivery state | The per-environment document (active shims, running canaries, kill switch) the SDK and CLI fetch. |
Modes
Every environment has a Mend mode, and the default is suggest.
- suggest (default): Mend opens faults and drafts patches, and stops there. Nothing is served until a human applies a patch as a shim or launches a canary. This is where every existing and new environment starts.
- auto-canary: Mend may launch canaries within your policy, but promotion to a shim still needs a human.
- autopilot: Mend may launch canaries and promote winners within your policy, hands-off.
Modes, policy, and the kill switch are covered on the Trust and safety page.