gemini_agent_submit

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

Annotations only say destructive/openWorld/non-idempotent; the description adds substantial context beyond them — thinking-level selection per kind, default JSON-mode reads scoped to workspace, native_tools running with local user privileges and *not* tracking native effects, and command grants being exact executable + fixed args requiring review. That is exactly the privilege and side-effect disclosure an agent needs for a destructive, open-world tool.

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?

Dense but front-loaded: purpose first, then permission constraints, then the return/polling contract. Every sentence carries behavioral information; the only friction is that the permission clauses are compressed into a single long sentence that is harder to scan than the rest.

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 behavior and privilege model are well covered for a destructive, no-output-schema tool, and the return contract (task ID + polling) is stated. However, for a six-parameter tool with a deep nested browser/checks/assertions block and a required workspace, the description leaves key inputs and their effects undocumented.

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%, so the description must carry the load; it does explain kind (via thinking levels), permissions.write, native_tools, and the commands structure (id/executable/args semantics). But workspace, task, max_turns, idempotency_key, and the entire nested browser/checks/assertions structure are left unexplained in both schema and description.

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?

Opens with a specific verb+resource: "Delegate an autonomous frontend/general/writing task," matching the kind enum exactly. It distinguishes the three task kinds via thinking levels, though it never contrasts itself with close siblings like gemini_spawn_agent or gemini_followup_task.

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?

Gives clear conditional guidance: writes require write=true, native_tools=true requires write=true, and commands must be reviewed before granting. Also routes the agent to polling ("poll status for progress and results") rather than treating the call as synchronous. It falls short of naming alternatives such as gemini_wait_agent or gemini_agent_status.

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