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

Annotations already declare readOnly, idempotent, non-destructive, open-world, but the description adds real behavioral context: the wait semantics, the requirement to re-call while IN_PROGRESS, the incremental log-reading protocol via after_log_line/next_after_log_line, and the ProjectBusy-wait/UNAVAILABLE outcome. These are operationally important traits not conveyed by the annotations. It stops short of describing return shape or pagination limits in full.

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 content is dense and mostly earned, but the sentence fragments and mid-sentence pivots ('then the project as it is, and the log's end if it FAILED') make it hard to parse. The most important concept, that this is a polling operation-status tool, is not front-loaded clearly.

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?

There is no output schema, so the description must explain what comes back. It references the project state and the log's end (on FAILED) and the UNAVAILABLE outcome, giving partial return context, but the actual response shape (fields, how IN_PROGRESS vs FAILED results differ) remains underspecified for a 5-parameter tool with no output schema.

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 80%, so the baseline is 3, but the description meaningfully extends it: it explains the wait_seconds behavior, the after_log_line chaining ('0' to start, then each next_after_log_line, oldest first), and the ProjectBusy wait semantics. This adds non-obvious protocol detail beyond the schema descriptions.

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 title and name say 'Get an operation,' and the description implies fetching an operation while waiting for it to finish, but the opening fragment 'An operation, after waiting for it to end' never states a clean verb+resource. It does distinguish a polling/status-read tool from siblings like QueryContainerLogs and GetProject by mentioning IN_PROGRESS and log reading, but the telegraphic phrasing leaves the core purpose partly to inference.

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?

'Call again while it is IN_PROGRESS' gives explicit polling guidance, and the ProjectBusy/UNAVAILABLE note hints at retry conditions. However, it offers no guidance on when to prefer this over siblings such as GetProject or QueryContainerLogs, so usage is only implied.

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