Track and calculate total cost, failed/cancelled print waste, filament grams, energy use, and average cost per finished print or printer from Bambu print history over a chosen period.
Spending over a period from the print history: total cost, money wasted on failed/cancelled prints, grams, energy, average cost per finished print (with and without waste), per printer.
| Name | Required | Description | Default |
|---|---|---|---|
| printer_id | No | ||
| since_days | No |
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 full burden. It implies a read-only aggregation and discloses the returned metrics, which is helpful, but it never states that the operation is non-mutating, says nothing about permissions or cost of execution, and does not explain behavior when no prints exist in the window.
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 opens with the core concept before listing metrics. Dense but every clause carries information; only the long enumeration risks readability.
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?
With no output schema, the description usefully enumerates the return metrics, which is good compensation. But with no annotations and zero parameter documentation, an agent still lacks the mutability profile and the meaning of printer_id, so it is not fully self-sufficient.
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 both printer_id and since_days (default 30, max 3650) are undocumented. The description flirts with printer_id via 'per printer' but never says whether it filters to one printer or adds a per-printer breakdown, and 'over a period' does not tell the agent how to set that period.
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 gives a specific resource (spending over a period drawn from print history) and enumerates the exact metrics returned: total cost, wasted money on failed/cancelled prints, grams, energy, and average cost per finished print. That distinguishes it in substance from estimate_cost (forward-looking estimate) and configure_cost (settings), though it never names those siblings explicitly.
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?
Usage is implied by 'from the print history' and 'over a period', which positions this as a retrospective reporting tool, but there is no explicit when-to-use statement, no mention of when to prefer estimate_cost instead, and no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.