grok_agent_start

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

Annotations are absent, so the description carries the full disclosure burden. It does disclose the asynchronous, non-blocking nature and the auto-means-stdio transport nuance, which is genuinely useful. However, it says nothing about side effects of starting an autonomous agent (filesystem mutation, command execution), what the call returns immediately (no output schema exists), or how the started work is later monitored given sibling poll/status tools.

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?

Two short sentences with the primary action front-loaded and no filler. The second sentence ('auto means stdio only') earns its place by resolving an ambiguity in the transport enum. Slightly more structure could have been added given the tool's complexity, but what is present is efficient and well-ordered.

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 tool of this complexity — required nested task object, conditional role-based requirements, no annotations, no output schema, and 25 siblings — the description is incomplete. It does not explain what a task packet is, what the start returns, how results are later retrieved, what the transport choices actually imply, or how this workflow relates to the sibling session, poll, and execute tools. The rich schema partially compensates, but the workflow context is missing.

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% and the required 'task' parameter is a nested object with 16 undocumented properties (objective, role, correlation_id, mount_paths, review_lane, permission_profile, etc.). The description adds meaning only for the transport parameter ('explicit legacy|stdio|websocket', 'auto means stdio only'); it does not compensate for the complete absence of guidance on how to construct a valid task packet, the meaning of roles, or the conditional requirements the schema encodes.

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 names a specific verb ('start'), a specific resource ('versioned typed task packet'), and a distinctive dimension (explicit legacy|stdio|websocket transport), so an agent can tell what operation is being performed. It is not a tautology and it is semantically distinct from the sibling names, though it never explains how this differs from grok_agent_execute, grok_agent_consult, or grok_agent_session_begin, so it stops short of full sibling differentiation.

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 guidance is the transport clarification ('auto means stdio only'), which is a parameter-behavior note rather than tool-selection guidance. With 25 sibling tools including grok_agent_execute, grok_agent_fix, and grok_agent_session_begin, there is no statement of when this start entry point is preferable, when it is not, or what alternatives exist for launching agent work.

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