triage_document

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

With no annotations provided, the description carries the full behavioral disclosure burden and handles it well. It discloses exactly what is read, what is returned, and what is NOT checked (hidden text, redaction failures, altered arithmetic, etc.). It also warns that a quiet triage is not a clean bill of health and explains the measured cost output.

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 sentence earns its place: the core purpose is front-loaded, and the caveats and scope differences are critical to correct agent behavior. It could be slightly tightened, but the length is justified by the complexity and by the need to prevent the tool from being treated as a full inspection.

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 the tool's purpose, alternatives, inputs, outputs, limitations, and non-verdict framing. There is no output schema and no annotations, so the description must carry all the information an agent needs to decide whether to invoke this tool and how to interpret the result. It qualifies as common.

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 single parameter 'path' is fully covered by the schema, which already states it is an absolute path, the acceptable file formats, and the 10 MB limit. The description adds incidental context about PDFs versus Office documents but does not add param-specific semantics beyond the schema. The baseline of 3 for full schema coverage applies.

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 specific action: a cheap pre-flight for document intake. It names the resource (document) and its core outcome (is it worth ingesting, what does opening cost), and differentiates itself from the sibling inspect_document by saying it avoids the expensive per-page walk. This is a precise, non-circular statement that an agent can use to decide between the tools.

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 says exactly when to use this tool: to route or reject before a full parse, never as a verdict. It explicitly names inspect_document as the alternative for page-content analysis, and notes that PDFs get a cheap scope while Office documents and images return full reports. That is concrete routing guidance.

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