mcp-solver
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| select_backendA | Start solving a constraint problem: call this FIRST, once per problem. Sets up a persistent IPython kernel preloaded with the backend's solver library and helper functions, and returns the modeling instructions for that backend. Calling it again recycles the kernel for a new problem (previous session state is cleared). Backends:
Unsure which backend fits? Read the resource mcp-solver://guide first. Then iterate with python_exec (write, run, verify against the problem statement), and finish by calling submit_code with the final, verified, self-contained program. UNSAT / "no solution exists" is a valid outcome. |
| python_execA | Execute Python code in the persistent solving kernel. Runs in the kernel set up by select_backend unless kernel_id overrides it. State persists across calls (variables, imports). Raise timeout (seconds, max 300) for long solver runs. |
| python_resetA | Create a new kernel (no kernel_id) or reset one (with kernel_id). Prefer select_backend, which installs the right solver packages for you. The kernel created or reset here becomes the target of bare python_exec calls. |
| python_statusC | Check kernel state: active kernels, defined variables, packages. |
| python_interruptB | Interrupt running code in the solving kernel (state is preserved). |
| submit_codeA | Submit the final, verified, self-contained solver program. Call ONCE at the end, only after executing the program via python_exec and passing your verification. The code is syntax-checked; on success it is stored and linked as a resource (the server keeps the last 50). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| guide | Backend selection and solving workflow guide. |
TDQS
Scored across 6 tools
Most tools are clearly distinct: python_status, python_interrupt, python_exec, and submit_code each have a unique role. The only mild overlap is between select_backend and python_reset (both create/configure kernels), but descriptions explicitly steer users to prefer select_backend, resolving the ambiguity.
Four tools share a consistent python_<action> prefix (python_status, python_interrupt, python_exec, python_reset), but select_backend and submit_code break this pattern with a verb_noun convention. Two coexisting conventions make it mixed but still readable.
Six tools is well-scoped for a constraint-solving workflow: backend setup, execution, kernel management, and final submission. Each tool earns its place with no redundancy.
The lifecycle (select_backend -> python_exec iterate -> submit_code, with status/interrupt/reset for kernel control) is well covered. Minor gaps: no tool to list or retrieve previously submitted solutions (only a resource mention), but core workflows are complete.