Get a GPTProto task

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds meaningful behavioral context beyond those annotations: it specifies the tool performs exactly one status query, never resubmits or loops internally, and is intended for recovery after an interrupted wait. This is valuable operational detail that an agent needs to know and is not present in the annotations or schema.

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 two sentences long, with the primary purpose and distinguishing behavior front-loaded. Every word contributes value: 'exactly one status query' sets scope, 'after an interrupted automatic wait' gives context, and 'never resubmits or internally loops' clarifies behavior. There is no fluff or redundancy.

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 simple query tool with annotations covering safety, the description conveys the core purpose and behavior adequately. However, it lacks any explanation of the parameters (task_id is required but not described, and video/output_json are unexplained), and there is no output schema to clarify return values. Given that 75% of the schema is undocumented, the description should have filled that gap but does not, leaving the tool incomplete for an agent that needs to invoke it correctly.

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 only 25% (only the 'path' parameter has a description; task_id, video, and output_json have none). The description does not mention any parameters or their semantics. It implies task_id is the identifier but never explains it, nor does it clarify the role of video or output_json flags. With low coverage, the description was expected to compensate but does not, leaving the agent to infer parameter usage.

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 states a specific verb ('perform') and resource ('status query for a saved task'), and immediately distinguishes itself from sibling tools by noting it runs exactly once 'after an interrupted automatic wait' and 'never resubmits or internally loops.' This clearly separates it from gptproto_task_wait, which likely handles waiting and resubmission. The purpose is unambiguous and differentiates well.

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 explicitly states when to use it ('after an interrupted automatic wait'), providing a clear trigger condition. It also tells the agent what it does not do ('never resubmits or internally loops'), which implicitly signals that normal waiting and resubmission should go to gptproto_task_wait. However, it does not name the alternative tool explicitly or provide a direct when-not-to-use comparison, so it falls short of the top tier.

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