team_run_task

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

With zero annotations the description carries the full burden, and it does add real value: it discloses that an optional real verification command may execute, and that outcomes include unavailable, deadlocked and failed states honestly. However, it says nothing about runtime duration, cost of a multi-round loop, filesystem writes to workspace_path, or credential/desktop-app requirements that matter for a default 3-round adversarial pipeline.

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?

Three dense sentences with the capability statement front-loaded, followed by the transport variant and the failure-reporting guarantee. Nothing is padding, though the phase list is a compressed run-on that must be parsed carefully.

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?

The output schema relieves the description of explaining return values, and the honest-failure note is valuable. But for a 16-parameter orchestration tool with no annotations and no parameter documentation, an agent still cannot confidently set review_with/judge_with/veto_agents or predict what the run will do to its workspace.

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% across 16 parameters, so the schema labels alone (plan_with, judge_with, veto_agents, reviewer_weights) give no meaning. The description explains only codex_thread, leaving 15 parameters undocumented, including consequential ones like require_unanimous, max_rounds and verification_retries whose defaults silently change semantics.

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 definition names a specific verb ('Run') and resource ('two-way Codex+Antigravity team') and enumerates the phases (plan, review, cross-examination, consensus, verification), so an agent knows this is a multi-agent orchestration pass rather than a single call. It never explicitly contrasts itself with siblings like team_compare or team_send_message, which keeps it from a 5.

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 only routing guidance is 'Pass codex_thread to use the ChatGPT/Codex desktop app instead of the CLI,' which selects between transport modes inside this tool rather than against a sibling. There is no statement of when to prefer this tool over the many adjacent team_* tools, so usage is implied rather than prescribed.

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