查询 Gemini 子代理任务

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that the tool returns status and final result, which is useful context, but it doesn't disclose potential error states, whether the task must be completed, or any behavior around unfinished tasks.

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 a single, front-loaded sentence with no wasted words. It immediately states the action, the resource, and the parameter without redundant phrasing.

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 read-only lookup with one parameter and annotations covering safety, the description is mostly complete. It names the high-level return content (status and final result), though it lacks output shape details and relationship to sibling tools. These are minor gaps given the low complexity and available annotations.

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 0%, but the single parameter job_id is self-explanatory and is further constrained by uuid format and pattern. The description confirms job_id is the lookup key, yet it doesn't explain where the id comes from or what values are valid beyond the schema pattern, so compensation for missing schema descriptions is partial.

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 (查询/query), a resource (后台 Gemini/Teamwork 任务状态和最终结果), and the key parameter (job_id). It is clear and distinct from mutation siblings like start_gemini_task and cancel_gemini_task, though it doesn't explicitly differentiate from antigravity_status.

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 implies usage when you need the status or final result of a Gemini task by job_id, but it provides no explicit guidance on when not to use this tool or which sibling to choose instead. It doesn't mention that job_id would come from start_gemini_task or delegate_to_gemini.

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