Retrieve simulation status and details, with optional log lines and diagnosis of cloudHPC errors and fixes for completed runs.
Get status and details of a simulation.
include_log: add the last output/log lines and a diagnosis of known cloudHPC errors and warnings with their fix. Use it whenever a run ends, since a run can be COMPLETED even if the solver failed.
| Name | Required | Description | Default |
|---|---|---|---|
| include_log | No | ||
| simulation_id | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=truelint. The description adds valuable behavioral context beyond annotations by explaining that include_log appends log lines and diagnoses known cloudHPC errors with fixes, and that a simulation can be COMPLETED even if the solver failed. This helps agents understand non-obvious status semantics.
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?
The description is compact and front-loaded: the first sentence states the tool's purpose, and the second paragraph explains the one nuanced parameter with a concrete usage rule. Every sentence earns its place without redundant filler.
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?
For a read-only status tool with two simple parametersley, the description covers the essential behavior and the edge case around successful completion versus solver failure. It does not describe the full return shape, but no output schema is provided and the status/details are implied sufficiently for an agent to call it correctly.
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%, so the description must compensate. It meaningfully explains include_log, describing the added log lines and diagnostic content, which goes beyond the schema's bare boolean flag. simulation_id is not elaborated, but its meaning is clear from its name and integer type.
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?
The description states 'Get status and details of a simulation', which clearly identifies the verb and resource. It does not explicitly differentiate from siblings like wait_for_simulation or sync_simulation, but the direct phrasing makes the tool's core purpose understandable.
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 gives clear contextual guidance for the include_log parameter: 'Use it whenever a run ends, since a run can be COMPLETED even if the solver failed.' This is useful and specific, though it does not compare get_simulation against alternative sibling tools such as wait_for_simulation or list_simulations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.