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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the read-only nature is covered. The description adds meaningful behavioral context: auto-detection of formats, line-count cap ('up to 5000 lines') is in the schema but the description says 'Paste log lines', and the tool's output scope is disclosed (per-line plus rollups and contradiction rows). It doesn't describe failure for oversized pastes or how auto-detection is ambiguous, but with annotations carrying the safety profile, this is adequate.

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?

Dense but front-loaded with the most important fact ('FIRST CALL, needs nothing') and a concrete example at the end. Every sentence earns its place; the inline JSON-RPC example is a bit verbose but functions as a literal invocation template for an agent. Slightly long, yet the density is justified by the need to enumerate accepted formats and outputs.

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 3 parameters, 100% schema coverage, and no output schema, the description covers input formats, output contents, and an example. The main omission is that it does not explain how the 'limit' and 'detail' parameters shape the output, or what 'contradicts its claim' means at a deeper level, but an agent can correctly invoke this tool with the provided information.

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 100%, so the baseline is 3. The description adds value by saying 'auto-detected' for input formats, clarifying that the log parameter accepts mixed formats without configuration, and the example demonstrates the exact syntax and semantics of the log parameter. It also communicates the purpose of the result columns (crawler, operator, purpose, cost), which helps an agent understand what limit/detail will produce.

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 ('Triage') and resource ('a paste of log lines'), and the opening 'FIRST CALL, needs nothing' telegraphs it as the zero-argument entry point to a family of log tools. The description enumerates inputs (paste formats) and exact outputs (per-line crawler/operator/purpose/cost, rollup by operator and category, plus contradiction detection), and the worked example distinguishes it sharply from siblings like robots_from_log and summarize_by_operator.

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 marks itself as the first call ('FIRST CALL, needs nothing'), lists accepted pasted formats, and warns 'Log text, never a URL', which is an explicit exclusion. The sibling list shows routing intent, e.g., the zero-argument sibling does triage on this host's own crawler log, while triage_log separates by noting its own inputs are pasted lines, not its host's log.

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