start_monitored_print

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

With no annotations, the description carries the full burden and delivers a clear step-by-step workflow (starts print, waits, captures snapshots, returns them, optionally auto-pauses). It also mentions the auto_pause behavior driven by failure reports. It could go further by describing what happens after monitoring ends or stopping behavior, but for a print start tool, this is thorough.

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 longer than average, but every part earns its place: a one-line summary, a short rationale, a numbered workflow, and a compact parameter list. It is front-loaded with the purpose. The only criticism is minor redundancy (e.g., 'first layer' repeated multiple times) and the aspirational 'optionally auto-pauses if you report a failure' could be more precise about how the reporting happens.

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 tool with an output schema and complex workflow, the description covers the start-to-finish behavior, all key parameters, and the safety context. It omits any mention of the preview_token parameter and doesn't describe error conditions or what happens if the printer is not available. However, given the sibling ecosystem and the tool's purpose, it is largely 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%, but the description provides meaningful, human-readable semantics for 6 of 7 parameters, including required status for file_name, the default-printer behavior for printer_name, and the units (seconds) and defaults for the first_layer_* parameters. Only preview_token is left undocumented, but its purpose is somewhat inferable from the name.

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 opens with a clear, specific verb+resource: 'Start a print and automatically monitor the first layer.' It immediately differentiates itself from the sibling tool start_print by stating it is the recommended way to start prints autonomously, and references the specific Level 1/2 autonomy requirement.

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?

Explicitly states when to use this tool: 'Use this instead of start_print when operating autonomously (Level 1/2) to satisfy the first-layer monitoring safety requirement.' This directly contrasts with an alternative and gives a concrete condition for selection. The tool's position as the recommended autonomous path is unambiguous.

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