后台启动 Gemini 子代理

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

Annotations already mark this tool as non-read-only and destructive, so the description does not need to restate mutation risk. It adds useful behavioral context beyond the annotations: the tool returns immediately with a job_id and the background task depends on the current MCP service process staying alive. No contradiction with the annotations.

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 compact sentences with the core behavior front-loaded: background start and immediate job_id return. The second sentence adds the use case, follow-up tool, and process-lifetime caveat without filler or repetition.

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 13-parameter background-launch tool with no output schema and destructive annotations, the description supplies the essential runtime model: immediate job_id, suitability for long tasks, polling via get_gemini_task, and the service-lifetime dependency. The remaining details are already in the schema. It could add an explicit contrast with delegate_to_gemini, but overall it is sufficiently complete.

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?

The input schema has 100% description coverage across all 13 parameters, including enums, defaults, the prompt format, and the working directory requirement, so the schema carries the parameter semantics. The description adds no parameter-level detail beyond the intended use case, which is fine under the high-coverage baseline.

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 and resource: it launches an Antigravity/Gemini task in the background and immediately returns a job_id. It also scopes the tool to long-running /teamwork-preview tasks and names get_gemini_task as the follow-up, so an agent can distinguish it from the query and dashboard sibling tools.

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?

It gives clear when-to-use context by saying the tool is suitable for long-running tasks like /teamwork-preview and explicitly instructs the agent to query results later with get_gemini_task. It also flags the operational prerequisite that the MCP service process must remain running. However, it does not explicitly contrast with delegate_to_gemini or state when not to use this tool.

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