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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuine behavioral value by disclosing the result shape: ordered Function invocations with status, error text, and captured print() output. It stops short of noting retention windows, result size limits, or behavior when the request id is unknown.

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?

Two sentences, front-loaded with the payload of the response and followed by the decision rule. The em-dash enumeration is dense but each clause earns its place; the only minor cost is a slightly sprawling first sentence.

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?

With no output schema, the description must carry the return-value burden, and it does — enumerating request-level fields and the per-invocation fields. Combined with annotations covering safety, an agent has enough to call it correctly; only error/not-found and volume behavior are unaddressed.

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 50% — project_id is documented in-schema, but request_id carries no schema description. The description compensates by explaining what a request_id is and where to obtain it (client error, support ticket, list_logs), which is meaning the schema does not supply. project_id's conditional nature is left to 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?

Specific verb+resource+scope: 'Everything about ONE request in a single call' with an explicit enumeration of what is returned (own status/latency/payload plus every triggered Function invocation, in order). It clearly separates itself from list_logs, which is named as a source of the requestId rather than as an equivalent.

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?

Explicit when-to-use framed as a scenario ('a request failed, was it my code') plus the precondition (pass the requestId you already have) and three concrete sources for that id: a client error, a support ticket, or list_logs. This routes the agent without ambiguity.

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