Continue Grok Build session [experimental]

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

Beyond annotations, the description discloses important behaviors: session pinning via grok_ask's id, fallback to cwd, persistence across server restarts, per-invocation permission flags, and the sandbox's effect. It also notes the experimental caveat and auth requirement, adding value over the structured annotations which only indicate openWorld and read-only state.

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 compact paragraph that front-loads the purpose and then provides necessary technical details. Each sentence contributes useful information — purpose, session mechanism, permission behavior, and experimental caveat — without redundancy or fluff.

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?

Given the presence of a detailed input schema, annotations, and an output schema, the description is complete enough. It covers the core behavior, session continuity, permission handling, and caveats. It doesn't discuss edge cases like missing prior sessions, but the fallback mechanism partially addresses that, and the experimental tag signals volatility.

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?

All 5 parameters are fully described in the schema (100% coverage), so the description has little additional semantic burden. It adds one clarifying note that 'sandbox takes effect here too' and ties it to a workflow, but this is marginal relative to the schema's already explicit parameter descriptions.

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 opens with 'Continue the Grok session rooted at this workspace', which clearly specifies the verb (continue), the resource (Grok session), and the scope (rooted at this workspace). It further explains the mechanics (resuming via session id or fallback to cwd), distinguishing it from sibling tools like grok_ask and grok_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 provides clear context: it is for continuing an existing session, references the companion grok_ask for read-only analysis, and explicitly recommends using 'workspace-write' to apply fixes. It lacks explicit 'when not to use' or named alternatives beyond grok_ask, but the workflow guidance is strong.

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