print_gcode

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool bypasses the public oauth2-proxy gate, interacts with the printer's web UI, and performs two web actions (upload and start). It also explains the optional upload-only behavior. While it doesn't elaborate on error handling or printer state, it adequately conveys the non-obvious internal process.

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 a single paragraph of three sentences. It front-loads the primary purpose, then explains the mechanism, and finishes with the optional parameter and configuration. Each sentence adds unique value without redundancy or extraneous detail, though slightly verbose with configuration details that could be assumed.

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?

The description covers purpose, mechanism, optional behavior, and configuration variables. It does not detail return values (but output schema exists) or error handling. For a tool that sends a file and starts a print, the description is reasonably complete given the presence of an output schema and the complexity of the operation.

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?

Despite 0% schema description coverage, the description adds substantial meaning to both parameters. It explains that 'gcode_path' is the local file to send (implicitly via 'Send a local .gcode file') and explicitly describes the 'start' parameter (default true to start print, false to only upload). This compensates for the lack of per-parameter documentation in the schema.

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 clearly states the verb 'Send' and the resource 'local .gcode file', with the specific outcome 'start printing it'. This distinguishes it from siblings like export_gcode (exporting) and process_model (processing 3D models), providing unambiguous purpose.

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 explains when to use the tool (to send and print a gcode file), includes an important usage variant (set start=False to upload only), and details the underlying mechanism (via docker container, bypassing oauth). It does not explicitly state when not to use or list alternatives, but the context from siblings and the clear purpose make usage guidelines sufficiently clear.

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