Run PySCIPOpt optimization code in an isolated sandbox subprocess. Returns execution metrics, solver logs, stdout, and error status.
Executes PySCIPOpt optimization code inside an isolated sandbox subprocess, returning execution metrics, solver logs, stdout, and error status.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| timeout_seconds | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does add real value by disclosing sandbox isolation and the returned artifacts (metrics, solver logs, stdout, error status). It stops short of stating side-effect boundaries (e.g. what the sandbox can touch) or how the timeout terminates or reports a hang, which matters for a code-execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that puts the verb, the resource, and the execution environment first, then the outputs. No filler, nothing to trim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the return-value enumeration in the description is somewhat redundant, and the status of the two inputs plus timeout behavior is left wholly unaddressed. For a sandboxed code-execution tool with zero annotation coverage, that leaves meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are two parameters, yet the description mentions neither `code` nor `timeout_seconds`. The default timeout of 60 seconds and its effect on long-running solver jobs — a genuinely important semantic for this tool — are documented nowhere.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (executes), a specific resource (PySCIPOpt optimization code), and the execution environment (isolated sandbox subprocess), which is far more precise than a generic 'run code'. However, it does not differentiate itself from the near-identical sibling execute_pyscipopt_sandbox, so an agent could reasonably confuse the two.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says what the tool does but never says when to reach for it versus the many siblings in this workflow (generate_model_code, review_model_code, execute_pyscipopt_sandbox, run_end_to_end_workflow). No prerequisites, no exclusions, no alternative routing is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.