Retrieve purge (flush) volumes in mm³ and multipliers per filament slot to review filament waste at color changes on the prime tower or into infill/objects.
Purge (flush) volumes between filament slots, in mm³, and the multiplier: the filament wasted at each change on the prime tower (or into infill/objects, see set_purge_volumes).
| 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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It adds useful domain context about units (mm³), filament changes, prime tower, and infill/objects, but it does not explicitly state that it is a read-only getter or describe the output structure.
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?
It is a single sentence with little wasted text, but it is a dense run-on with nested parentheses and a colon rather than being front-loaded with a clear action. It is concise but structurally awkward.
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 zero-parameter getter with no output schema, the description should clearly say what is returned. It conveys the returned concepts (volumes and multiplier) and their meaning, but it does not explicitly describe the return format or confirm that it retrieves current settings.
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?
The tool has zero parameters, so baseline 4 applies. There are no parameters whose semantics need explanation in the description.
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 identifies the resource as purge/flush volumes between filament slots and the multiplier, but it is written as a noun phrase rather than stating 'gets' or 'returns' current values. The verb is only implied by the tool name, so the purpose is understandable but not crisply stated.
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 only guidance is a parenthetical cross-reference to set_purge_volumes, which indicates an alternative exists but does not state when to use this tool versus the setter. There is no explicit read-vs-write guidance for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.