fix(deps): cap the mcp extra below 2.0

[EfeDurmaz16]

The problem

mcp 2.0.0 was published today and renamed McpError to MCPError with no compatibility alias
(modelcontextprotocol/python-sdk#1956).
The mcp extra declares mcp>=1.1.0 with no upper bound, so a fresh install picks up 2.0.0 and
mpp/extensions/mcp/errors.py:15 fails to import.

Because the extension loads lazily, import mpp.extensions.mcp still succeeds. The failure only
appears on first attribute access, so a smoke test will not catch it.

Reproduction

Clean venv, published package, nothing local:

python3 -m venv .venv && ./.venv/bin/pip install "pympp[mcp]"
# pympp 0.9.1, mcp 2.0.0

Both usage paths from the module docstring fail:

>>> from mpp.extensions.mcp import verify_or_challenge, create_challenge, MCPChallenge, PaymentRequiredError
ImportError: cannot import name 'McpError' from 'mcp.shared.exceptions'. Did you mean: 'MCPError'?

>>> from mpp.extensions.mcp import pay, payment_capabilities
ImportError: cannot import name 'McpError' from 'mcp.shared.exceptions'. Did you mean: 'MCPError'?

6 of the 13 public exports are affected:

broken	pay, verify_or_challenge, create_challenge, PaymentRequiredError, PaymentVerificationError, MalformedCredentialError
working	payment_capabilities, McpClient, McpToolResult, PaymentOutcomeUnknownError, MCPChallenge, MCPCredential, MCPReceipt

That leaves the client side and the data types, but no way to issue a challenge, verify a credential,
or raise a payment error. A paid MCP tool cannot be built on the current release.

A script that reproduces both states is at the bottom.

The change

One line, capping the extra at <2, matching the bound style already used for eth-abi>=5.0,<6.

This is also what the SDK's own migration guide recommends for projects that have not migrated yet.
I kept the >=1.1.0 floor rather than raising it to >=1.28, so nobody currently on an older 1.x
gets pushed forward. Happy to raise the floor instead if you prefer.

Testing

On main, uv sync --all-extras resolves mcp 2.0.0 and tests/test_mcp.py fails to collect, with
5 further failures in tests/test_mcp_client.py. With this change it resolves 1.29.0:

778 passed, 41 skipped

and all 13 exports import.

Not included

Actual 2.x support is a larger piece of work and I did not attempt it here. The rename and the
flattened MCPError(code, message, data) constructor are mechanical, but the migration guide also
notes that raising MCPError from a tool handler now surfaces as a top-level JSON-RPC error instead
of CallToolResult(is_error=True). The payment flow relies on the client reading challenges out of
the error, so that needs measuring rather than a shim. Happy to open a tracking issue.

Reproduction script

#!/usr/bin/env bash
set -u
python3 -m venv /tmp/pympp-mcp2 && cd /tmp/pympp-mcp2
./bin/pip install -q "pympp[mcp]"
echo "installed:"; ./bin/pip list 2>/dev/null | grep -Ei "^(pympp|mcp) "

probe() { ./bin/python - <<'PY'
import mpp.extensions.mcp as m
ok, bad = [], []
for _mod, names in m._LAZY_EXPORTS.items():
    for n in names:
        try: getattr(m, n); ok.append(n)
        except Exception: bad.append(n)
print("  broken:", bad or "(none)")
print(f"  {len(ok)}/{len(ok)+len(bad)} public exports import cleanly")
PY
}

echo "--- with mcp 2.0.0 (what a fresh install gets)"; probe
./bin/pip install -q "mcp>=1.28,<2"
echo "--- with mcp pinned below 2"; probe

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[EfeDurmaz16]

@brendanjryan flagging this one as time sensitive: mcp 2.0.0 went out today, so this affects anyone installing pympp[mcp] right now, and the next CI run on main will hit it too.

Reproduced on the published package in a clean venv, not just locally. One line, no code change.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	pypi/​mcp@​1.29.0

View full report