warrant 0.8.0 — the MCP server ships in the package

pip install warrant-verify now gives you the MCP server as a command:

pip install warrant-verify
claude mcp add warrant -- warrant-mcp-server --store .warrants

Until now the server lived in integrations/mcp-server/, outside the one root setuptools' flat layout allows, so it could not be in the wheel at all — the registry entry published yesterday offers a clone and nothing else. It is now impl/warrant_mcp_server.py with a warrant-mcp-server console script, and its CLI resolution stops pointing at a path that resolves to nothing once installed.

Two similarly-named programs, and the guard is executable rather than documentary. warrant-mcp is the sealing proxy — it wraps someone else's MCP server and seals the traffic. warrant-mcp-server is this server. Confusing them would be worse than shipping neither, so warrant-mcp refuses to start without a downstream command after --, warrant-mcp-server refuses one, and three release-gate cases assert that against the wheel's own parsers.

Verified as a stranger, not as an author. The wheel was built, installed into a clean virtualenv, registered with a real MCP host (✔ Connected, then removed), and all three tools were driven over stdio against the installed copy — including a decision whose ski@v1 reason re-executed (reproduced: true, atp_spent=18) and a one-byte tamper that correctly flipped the store to ok:false with a WarrantID mismatch.

A dropped plan item worth naming. The manifest was going to carry runtimeHint: "uvx". Measured against the built wheel, uvx --from <wheel> warrant-verify answers "An executable named warrant-verify is not provided by package warrant-verify" — a client composes runtime + identifier, and the identifier is the distribution, not the script. The schema has no field naming which console script to run, so the hint would have encoded a command that does not start. Omitted, as it is in 262 of the registry's 267 PyPI entries.

Also in this release: LISTINGS.md said this project was listed nowhere, hours after it was listed — corrected with the old sentence quoted rather than overwritten, and the registry's valid: true restated beside the measurement that a manifest naming a nonexistent package gets the same answer. And repo_map.py resolved the sibling repository only when the checkout directory was literally named warrant, so regenerating from a worktree silently rewrote every cross-repo citation to "resolves nowhere".

Not done here: the registry entry still points at a clone. Updating it needs this release on PyPI first — the registry 404s on a manifest version it cannot find, and proves package ownership by reading an mcp-name: marker out of the published README, which this release adds. No external party has implemented the conformance contract, and no independent gate has reviewed any of this.