feat(mcp): add a Model Context Protocol server for pruna

[Joystonm]

Adds a Model Context Protocol server so an LLM can discover and validate Pruna's optimization catalogue without loading a model.

The server has two tiers. Seven discovery and validation tools (list_tags, list_algorithms, describe_algorithm, list_benchmarks, list_metrics, list_datasets, validate_config) are read-only and need neither a GPU nor network access, so they are always registered. smash_model and evaluate_model load a model and are registered only when the server is started with --allow-execute, so a client can discover that execution is unavailable rather than being offered a tool that would download gigabytes of weights.

validate_config reuses check_argument_compatibility and check_algorithm_packages_availability from pruna.config.pre_smash_routines, plus a static mirror of the pairwise branch of check_algorithm_cross_compatibility. These surface missing pip extras, missing tokenizers, and incompatible algorithm pairs before any device is touched. The two checks that genuinely need a loaded model are reported in notes rather than guessed at.

Install with pip install "pruna[mcp]", then register pruna-mcp as an MCP server.

Related Issue

<!-- If this PR addresses an existing issue, please link to it here -->

Fixes

Type of Change

<!-- Mark the appropriate option with an "x" (no spaces around the "x") -->

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactor (no functional change)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

Testing

<!-- How did you verify your changes? Which tests did you run? -->

• I added or updated tests covering my changes
• Existing tests pass locally (uv run pytest -m "cpu and not slow")

57 tests added under tests/mcp_server/, run against Pruna 0.3.4 (48 registered algorithms). The suite was also driven end-to-end over real stdio JSON-RPC in both modes: handshake, tools/list, tools/call, plus ping, resources/list, and prompts/list using the mcp SDK's own ClientSession, against a subprocess running pruna-mcp.

Notable coverage:

• Round-trip tests feed every default and every allowed value that describe_algorithm advertises back into SmashConfig and assert Pruna accepts it, so the server cannot report a value it would then reject.
• Signature-binding tests assert the execution tools call smash, save_pruna_model, the loaders, and EvaluationAgent with arguments those functions actually accept. These need no device, and they are what caught PrunaDataModule being called with a data_name it does not have.
• Tests cover a Pruna installation without the mcp extra, asserting the failure names pruna[mcp] and does not surface a traceback.

Not yet verified: smash_model and evaluate_model have not been executed against a real model. Every call they make is signature-checked, but the paths after smash() runs need a device to confirm.

Checklist

<!-- Mark items with "x" (no spaces around the "x") -->

• My code follows the style guidelines of this project
• I have performed a self-review of my code, especially for agent-assisted changes
• I updated the documentation where necessary