Pin mcp below the release that masks validator refusals

[exploitintel]

Restores main to green and, more importantly, stops shipping a degraded package to PyPI.

What broke

Every refusal this server words for itself is raised from a Pydantic WrapValidator - the bounds, the enum listings, the whole-number distinction. server.py:195-205 calls that wording deliberate: "What stays ours is the wording."

mcp 2.1.0 stopped propagating anything raised during argument validation. The SDK docstring for its wrapper is explicit: "nothing from the original reaches the client."

Proved with a minimal probe rather than inferred:

ToolError raised in the tool BODY   -> "Error executing tool X: body: this message should survive"
ToolError raised in a VALIDATOR     -> UnexpectedToolError: "Error executing tool X"

Exception type is irrelevant; the raise site is what matters.

Which versions

Bisected, not guessed:

mcp	validator message
2.0.0	survives
2.0.1	survives
2.1.0	masked
2.1.1	masked
2.2.0	masked

So the break is 2.1.0. A <2.2 pin would have looked right and still shipped the bug.

Exposure

The declared range was mcp>=2.0.0,<3, so a fresh pip install eip-mcp has been resolving to a masked build since 2.1.0 shipped. Production on ovh2 is unaffected only by luck: it installed 2.0.0, and a live call still returns limit must be between 1 and 100.

Result

1970 passed, 232 skipped, 0 failed.

Lifting this

The pin is a stopgap. The durable fix is moving the refusals out of validators into the tool bodies, where a ToolError message survives on every version tested, and that is a deliberate change rather than something to fold in here.

[claude]

Reviewed against the read-only MCP client's usual concerns (corpus text escaping into live Markdown/HTML, derived judgment/scores, PoC token leakage, unbounded output, host-validation/transport weakening, scope creep). This diff is a single-line dependency pin in pyproject.toml (mcp>=2.0.0,<3 → mcp>=2.0.0,<2.1) plus an explanatory comment — none of that surface is touched.

Sanity-checked the surrounding claims:

• No lock file in the repo to drift out of sync with the new pin.
• requirements-dev.txt and the release/quality workflows don't independently pin or reference mcp, so nothing else needs updating to match.
• The bisection table in the description (2.0.0/2.0.1 good, 2.1.0+ masked) matches the chosen <2.1 upper bound exactly — the pin isn't over- or under-shooting the known-good range.

No findings. The follow-up mentioned in the description (moving refusals from validators into tool bodies so the pin can eventually be lifted) is correctly scoped out of this PR.