skip_objects

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so: it flags irreversibility in caps, discloses the dry-run/confirm protocol so the agent knows the first call sends nothing, and states the LAN-only + Developer Mode firmware precondition. These are exactly the traits an agent cannot infer from the schema.

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?

Leading sentence establishes action and irreversibility, followed by parameter semantics, exclusions, workflow, and preconditions in that order. Dense but every line carries operational weight; nothing is redundant.

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?

No output schema exists, yet the description tells the agent what a confirm-less call returns (what would be skipped plus a confirm code). For a destructive two-step printer operation, the agent has everything needed to call it correctly and safely.

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 coverage is 0%, but the description compensates fully: 'ids' is defined as printer-side object identifiers with sourcing hints (identify_id, Bambu Handy skip list, printer_status 'skipped_objects'), and 'confirm' is explained as the code returned by the first call rather than an opaque string.

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+resource: stop printing selected objects on the currently running print, with a concrete example (a part that came off the plate). The 'print running now' scope implicitly separates it from model-side siblings like delete_object and remove_part, though it never names them 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?

Gives explicit when-not guidance ('Do not list every object: to stop the whole print, cancel it on the printer'), names alternative venues (Bambu Handy, the printer itself) when firmware preconditions fail, and prescribes the exact two-call sequence the agent must follow, including getting user agreement before confirming.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.