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

With no annotations provided, the description carries the full burden for behavioral disclosure. It does reveal one important trait—that the MCP server is not stopped—but it omits other critical details such as whether the job must be active, idempotency, error behavior, or return values. The added context is minimal and insufficient.

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 single, front-loaded sentence with no wasted words. 'Boundedly' and 'without stopping the MCP server' add purposeful information, and the length is appropriately short for a simple, one-parameter tool.

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 simple cancellation tool with one parameter and no output schema, the description is minimally viable but leaves gaps: it does not state what happens on cancellation, whether it is synchronous, or what success/failure looks like. The presence of sibling polling/status tools implies a typical usage pattern, but the description alone is not fully 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 schema has one parameter (job_id) with 0% description coverage, and the description does not mention job_id at all. It only vaguely refers to 'typed job', which fails to explain how the parameter should be used or obtained. Since the schema is minimal and the description does not compensate, this is a significant gap.

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 uses a specific verb 'cancel' with a clear resource 'one typed job' and adds a scoping constraint 'without stopping the MCP server'. This clearly distinguishes it from sibling tools that start, poll, or delegate jobs.

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?

No explicit guidance is given for when to use this tool versus alternatives. The description implies usage via the tool name and purpose, but it does not mention prerequisites, exclusions, or alternative tools. This is below the 'implied usage' threshold.

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

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

With no annotations provided, the description carries the full burden. It does disclose two meaningful behavioral traits: the session is isolated and read-only, and it supports non-git exact allowlisted roots. But it does not explain lifecycle behavior, whether results are polled, session cleanup, or what happens on failure.

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 single sentence and front-loads the core action and safety property. It is concise, though the 'non-git exact allowlisted roots' phrase is jargon-heavy and reduces clarity.

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?

This is a complex tool with nested objects, many interlocking fields, no output schema, and no annotations. The one-sentence description leaves out the entire invocation model, the meaning of task fields, session lifecycle, and how this relates to the sibling session/delegate tools.

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 task object contains over 20 undocumented properties, so the description must compensate. It does not explain lane, transport, role, permission_profile, project_root, or any other parameter. The only oblique reference is 'non-git exact allowlisted roots', which does not map clearly to a schema field.

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 clearly states the action ('Start') and the resource ('an isolated read-only consult session'), and the read-only framing differentiates it from execute/fix siblings. However, it does not explicitly contrast with grok_agent_start or grok_agent_session_begin, and 'non-git exact allowlisted roots' is cryptic.

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?

No explicit guidance is given about when to use this tool versus the many siblings (execute, fix, start, session_begin, delegate). The read-only language implies a consultation use case, but no alternatives or exclusion conditions are named.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It explicitly states 'Read-only, no secrets,' which discloses both the safety profile and a key boundary. 'Call once' also signals that repeated calls are unnecessary and possibly wasteful. This is solid transparency for a zero-parameter informational 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?

The description is three short sentences, front-loads the core purpose, and packs in usage, safety, and scope without filler. Every clause earns its place, making it easy for an agent to scan and act on.

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 zero-parameter informational tool with no output schema, the description provides sufficient context for selection and invocation: purpose, usage, safety, and what topics it covers. It falls just short of full completeness because it does not explicitly state the expected output format, though the phrase 'playbook' strongly implies instructional content.

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 tool has zero parameters, so parameter-level semantics are not applicable. Per the calibration guidance, zero-parameter tools receive a baseline of 4, and the description appropriately avoids inventing parameter details that do not exist.

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 clearly identifies the tool as a token-economy playbook for host agents and enumerates the specific guidance it provides: when to consult vs execute, polling compact receipts, and VPS offload tips. This makes the purpose readily understandable and distinguishes it from the action-oriented sibling tools, though it lacks an explicit verb like 'retrieve' or 'display'.

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 gives concrete usage guidance: 'Call once; prefer over re-planning.' It also frames the tool as the source for deciding between consulting and executing, which implies when it should be used relative to those sibling tools. It could be stronger by naming explicit alternatives, but the context is clear.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does add one meaningful behavioral fact: completion requires 'a real diff and requested evidence.' However, it does not mention side effects, asynchronous behavior, required permissions, workspace setup, or what the response contains, leaving significant gaps.

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 short and front-loaded with the primary action. Both sentences contribute value: the first states the operation and context, and the second states a completion requirement. The phrasing of 'completed requires a real diff and requested evidence' is slightly awkward but not wasteful.

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?

This is a complex tool with a large nested task object and no output schema, yet the description offers only minimal context. It does not explain how to construct a valid task, what happens after execution starts, whether results are returned or polled, or how completion is surfaced. For an execution tool of this complexity, the description is far from 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?

Schema description coverage is 0%, and the description gives no explicit guidance on the three top-level parameters (lane, task, transport) or the many nested task fields. It hints at some semantics through words like 'git worktree' and 'real diff,' but the description does not meaningfully compensate for the lack of parameter documentation.

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 clearly states a specific action and resource: 'Start workspace execution in a git worktree.' This tells an agent what the tool does, and the completion condition adds useful scope. However, it does not explicitly distinguish itself from sibling tools like grok_agent_start or grok_agent_consult, so it stops short of full 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?

There is no guidance on when to use this tool versus the many siblings, nor any stated prerequisites or exclusions. The phrase 'Start workspace execution' implies a use case, and the completion condition is useful, but no alternative tools or conditions are mentioned.

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

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

No annotations are present, so the description carries the full disclosure burden. It usefully reveals that the session is 'separate' and 'scoped,' but it never discloses that a 'fixer' session presumably mutates workspace files, whether it blocks or runs asynchronously, or how it relates to the session lifecycle. For a mutation-implying tool, the absence of side-effect warnings is a significant gap.

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 single 14-word sentence is efficiently written and front-loaded with the verb 'Start'; every word earns its place. However, relative to the tool's deeply nested schema and complete lack of parameter documentation, it is under-sized rather than appropriately sized.

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 with no annotations, no output schema, 0% parameter coverage, and a required nested `task` object with 18 properties, this description is drastically incomplete. It does not explain return values, how to populate required task fields (objective, project_root, correlation_id, expected_artifacts, test_commands), or how this session connects to the session lifecycle siblings. An agent cannot reliably construct a valid call from this text.

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 compensate. It adds one semantic link — mapping the required `task` object to the 'task packet' containing 'confirmed findings' — but leaves the other two parameters (lane, transport) and roughly 18 nested task properties completely unexplained. This does not meaningfully offset the coverage gap.

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 action — 'Start a separate workspace fixer session' — with a clear verb, resource, and scope ('scoped to confirmed findings in the task packet'). The words 'separate' and 'fixer' help distinguish it from consult/review/execute-style siblings, though it never names a specific alternative.

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?

No when-to-use or when-not-to-use guidance is provided. 'Scoped to confirmed findings' implies a precondition (findings must already be confirmed), but with 23 siblings there is no explanation of when to prefer this tool over grok_agent_execute, grok_agent_consult, or grok_agent_review. An agent must infer the selection criteria entirely.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that it reads and can block (from the wait_seconds schema), but does not state important behaviors: what happens when the job is not found, whether it is safe (read-only), or what happens on timeout. The description doesn't contradict annotations (none exist), but it leaves significant behavioral gaps.

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 single, concise sentence that gets straight to the point. It front-loads the primary purpose without extraneous details. Every word earns its place.

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 polling tool with three parameters, no output schema, and no annotations, the description is too sparse. It does not explain the return format, error cases, or when to provide limit versus wait_seconds. It also doesn't clarify how it differs from status tools. At least basic guidance on usage patterns would be expected.

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 only 33% (only wait_seconds has a description). The tool description itself adds no parameter-level meaning beyond the schema, so the agent gains little clarity on how to use limit and job_id. Since coverage is low, the description should compensate, but it doesn't. Baseline is 2, but the parameter names are somewhat self-explanatory, so a 3 is borderline. Given the low coverage, a 2 is more appropriate.

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 ('Read') and resource ('bounded progress/events and the final evidence receipt') for a 'typed job'. It adequately distinguishes from siblings like grok_agent_status (likely just status) and grok_delegate_poll (for delegate jobs), though it doesn't explicitly differentiate. The core purpose is clear but could be more specific about what 'typed job' means.

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 gives no explicit guidance on when to use this tool versus alternatives such as grok_agent_status or grok_delegate_poll. It implies use for polling a job's progress, but lacks clear context like 'use for asynchronous operations' or 'when you need to wait for completion'. No exclusions or alternatives are mentioned, leaving the agent to infer usage.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It discloses that it writes a file when 'preset' is provided (implying a side effect) and that not having a config causes job tools to fail. However, it does not mention potential side effects of writing (e.g., overwriting existing config, file creation behavior, or error handling if file is invalid). The absence of annotations makes this a moderate gap, but the description covers the key behavioral nuance of the read vs. write distinction.

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 sentences, front-loading the core function and then providing essential usage context. Every sentence adds value: the first establishes the dual read/write behavior and lists valid preset values; the second gives a concrete usage trigger. No unnecessary 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?

For a tool with only 3 parameters and an array of sibling job tools, the description is fairly complete. It covers the dual behavior, the trigger for use, and the effect of not having a config. It does not describe the return format, but with no output schema and the tool being a configuration reader, this is acceptable. The only minor gap is the lack of details on what happens after writing (e.g., does it return a success status?), but this is not critical for invocation.

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%, but the description adds meaning for two of the three parameters: 'preset' is explained as the value to write, and 'project_root' is implied as the project location. The 'note' parameter is not mentioned in the description, but its semantics are intuitive given the schema (maxLength 500 suggests a comment). The description compensates well for the low schema coverage.

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 clearly states the tool reads or writes the project's Grok preset configuration, with distinct behavior depending on whether the 'preset' parameter is provided. It mentions specific values ('off, cheap, standard, max') and clarifies this is a config file operation, distinguishing it from sibling job tools like 'start', 'execute', and 'poll'.

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 explicitly states when to call this tool: 'call this first when they report PROJECT_NOT_ENABLED'. It explains the consequence of not having a config (job tools refuse) and differentiates the two modes (read vs. write) based on parameter presence. This gives clear actionable guidance for an agent.

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

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

With no annotations provided, the description carries the behavioral burden and does disclose key traits: the session is 'independent', 'read-only', and 'skeptic'. However, it does not disclose the session lifecycle, whether the call is asynchronous, or what the tool returns, which matters for a 'start' style 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?

The description is a single front-loaded sentence with no filler. Every word contributes meaning: 'Start', 'independent', 'read-only', 'skeptic', and 'evidence/diff inputs' all add distinctive information.

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 tool has a complex nested task schema, no output schema, and no annotations, yet the description is only one sentence. It omits essential context such as return value, session handle, asynchronous behavior, and how to populate the nested task object, making it incomplete for an agent to invoke confidently.

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 description hints at 'evidence/diff inputs', which loosely maps to the task.inputs field, but it does not explain the required nested task fields such as objective, project_root, and correlation_id, nor the lane/transport parameters. With schema_description_coverage at 0%, the description fails to compensate for the schema's lack of parameter explanations.

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 clearly states a specific action ('Start'), a resource ('an independent read-only skeptic session'), and scope ('over supplied evidence/diff inputs'). It distinguishes itself through the 'skeptic' and 'read-only' qualifiers, though it does not explicitly compare against sibling tools like grok_agent_consult or grok_agent_execute.

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 implies the intended use case: when an independent, read-only, skeptical review of evidence or diff inputs is needed. It does not explicitly state when not to use this tool or name alternatives, so the guidance is inferred rather than explicit.

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

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

With no annotations, the description carries the full burden, and it does disclose the operation's return payload and the presence of a 'budget guard'. It does not explain side effects, whether an existing session is replaced, error behavior, or persistence implications of beginning a session, leaving meaningful behavioral gaps.

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 compact and front-loaded with the protocol version and core action before listing parameters and returns. The 'Session Protocol v1.2' prefix adds minor noise, but every other clause earns its place.

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 an 8-parameter tool with no output schema and no annotations, the description is too sparse. It helps an agent make a default 'call first' invocation, but it does not explain how to use five optional parameters, what the returned plan mode means, or how to react to deny_tools, making the description incomplete for the tool's complexity.

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 only 13%, and the description mentions only intent, goal, and host_budget, leaving project_root, test_commands, correlation_id, max_tool_calls, and expected_artifacts unexplained. For those undocumented parameters, the description adds almost no semantic value beyond what the schema already provides.

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 clearly identifies the operation as 'begin session' with a specific protocol resource, and the return fields ('mode, plan, budget, deny_tools, host_script, skill_ref') give it a distinct identity. It does not explicitly compare itself to sibling tools such as grok_agent_start or grok_agent_session_next, so it falls just 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?

'Call first' gives explicit positional guidance within the session lifecycle, which is valuable and actionable. However, it does not state when to prefer this over grok_agent_start or grok_agent_session_tick, nor does it mention any exclusions or preconditions beyond being first.

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

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

With no annotations, the description carries the full disclosure burden. It usefully states that suggest_issue returns a scrubbed draft and does not auto-create an issue, but it does not disclose what ending a session does to session state, job state, cleanup, or whether the operation is irreversible.

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 short and usefully leads with the receipt contract, and the second sentence adds an important side-effect caveat. However, 'Session Protocol v1.2' and the compacted field names are cryptic, making the description concise at the expense of clarity.

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 no annotations, no output schema, and a 0% parameter-description coverage, an ending operation needs substantially more context. The description does not state preconditions such as having a valid session_id, what cleanup or termination occurs, or how this relates to sibling session lifecycle operations.

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 compensate. It explains the suggestion_issue behavior but leaves note, job_id, and session_id semantically undocumented, so three of the four parameters rely on name inference alone.

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 communicates what is returned—a short receipt with status/job/changed/tests/next—and that suggest_issue can optionally return a scrubbed issue draft. However, it never explicitly states the main action with a verb such as 'ends' or 'closes'; the core purpose is only inferable from the tool name and the protocol wording.

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?

There is no guidance on when to call this tool or when to prefer a sibling such as grok_agent_cancel, grok_agent_session_tick, or grok_agent_session_next. The only usage hint is 'optional suggest_issue,' which concerns a parameter rather than the conditions for choosing this operation.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It reveals the return type and the loop-termination flag 'done=true', but it is silent on whether the call advances session state, the effect of the 'advance' parameter, error handling, or session_id requirements. For a session-navigating tool this is a notable gap.

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 compact and front-loaded: it states the core deliverable (ONE next action card) in the first clause and the loop contract in the second. It contains no filler and every sentence contributes information, though it is terse to the point of deficit in other dimensions.

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?

With no output schema and no annotations, the description should supply protocol context, parameter semantics, and return structure. It provides only a terse protocol label and the action-card enum. Missing details include the card payload structure, the meaning of 'done=true' for subsequent calls, and the purpose of the note and advance parameters. The definition is more of a skeleton than an operational guide.

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 description does not explain any of the three parameters (note, advance, session_id). While session_id and advance are somewhat self-explanatory, note is completely ambiguous, and the description adds no meaning beyond the raw parameter names. This is insufficient compensation for the lack of schema 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 names a concrete resource ('Session Protocol v1.2') and a specific action: return ONE next action card of type host_cmd, mcp_tool, or end. It clearly focuses on the 'next action' deliverable, distinguishing it from the sibling tools at a high level. However, it does not explicitly contrast itself with closely related siblings such as grok_agent_session_tick or grok_agent_poll.

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 states the loop context ('Host loops this until done=true'), which is clear usage guidance for a session driver. However, it does not name alternatives or specify when not to use this tool. Given the large set of siblings, the absence of explicit routing makes it slightly harder for an agent to select this tool confidently.

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

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

No annotations are provided, so the description must disclose behavior. It reveals that the tool returns step, steps_left, budget_remaining, and force_end, and mentions that passing tool_used/step_done affects budget counting. However, it does not clarify whether the tool has side effects or requires specific permissions.

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 extremely concise, consisting of a single sentence with key details. It avoids unnecessary words and is well-structured.

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 description lacks essential information about parameter meanings, usage context, and side effects. While it gives a basic idea of progress/budget tracking, it is incomplete for an agent to use confidently without additional context.

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 schema provides no descriptions for the five parameters, and the tool description only mentions tool_used and step_done (and verbose default). job_id and session_id are completely unexplained, leaving the agent without enough information to correctly populate them.

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 it is a 'compact progress + budget' tick for a session protocol, but it is somewhat vague about the exact action. It mentions returning progress metrics and passing tool_used/step_done to count budget, which gives a general idea but not a precise purpose.

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 does not provide any guidance on when to use this tool compared to the many sibling tools (e.g., session_begin, session_next, delegate_*). It lacks context on the typical workflow or scenarios where this tick is appropriate.

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

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.

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

With no annotations, the description carries the full burden for behavioral disclosure. It states 'Read-only', which is a key behavioral trait, and enumerates the specific status categories it reports. However, it does not disclose potential blocking behavior, authentication requirements, or error conditions, which would be valuable for a status tool. The description is minimal but not misleading.

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 single concise sentence that packs in specific details without waste. It is front-loaded with the status categories and concludes with 'Read-only.' While the list is a bit terse and could be more readable, it is efficient and every term adds value. A small deduction for the slightly cryptic 'exact roots' phrase.

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 zero parameters and no output schema, the description is the only source of information. It lists the various status areas but does not describe the return format, potential output structure, or any error/edge-case behavior. For a status tool, it covers the core scope but lacks detail that would help an agent fully anticipate the response. A description that explained the output format or provided usage context would be more 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 tool has zero parameters, and the schema is an empty object. The description adds no parameter details, but none are needed. Per the baseline for 0 params, a score of 4 is appropriate because there is nothing to compensate for, and the description's focus on the status categories is sufficient.

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 clearly identifies the tool as a status query, enumerating specific aspects: version/auth-presence, exact roots, transport router, daemon, and durable job status. The 'Read-only' tag further clarifies its non-mutating nature, distinguishing it from sibling tools like grok_agent_start or grok_agent_cancel. It lacks an explicit verb like 'gets' or 'returns', but the meaning is unambiguous.

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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, context, or when not to use it. The 'Read-only' label is helpful but does not constitute usage guidance, and there is no reference to sibling tools like grok_agent_poll or grok_delegate_status.

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

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

With no annotations, the description carries full responsibility. It discloses the two modes (preview vs. execute), the effect of confirm (pulls and reinstalls), the side effect (asks to restart the MCP host), and the refusal condition (dirty checkout). This is transparent about all behavioral aspects.

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 concise, using clear sentences to cover the purpose, behavior, and conditions. It avoids unnecessary detail while being informative, making it easy to parse.

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?

In the absence of an output schema, the description explains what happens in each mode: preview returns exact steps, confirm performs the update and prompts for restart. It also covers the dirty-checkout edge case, making it complete for an agent to decide and invoke.

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 only parameter, confirm, is described in the schema ('Run the update. Omit to preview it.') and further elaborated in the tool description. The description clarifies that without confirm it returns steps, and with confirm it acts, adding clear semantic meaning.

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 clearly states the tool checks if the running bridge is behind its git remote and updates it. It specifies the action (check and update) and the resource (running bridge), making it distinct from sibling tools like grok_agent_poll or grok_agent_start.

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 explains when to use it (to check for updates and apply them) and how to invoke it (with or without confirm). It also notes the refusal condition (dirty checkout). However, it does not explicitly compare to alternative tools, though the context implies this is the update tool. Slight room for improvement.

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

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

With no annotations present, the description bears the full behavioral disclosure burden. It goes beyond a simplistic statement by revealing return content ('branch + diffstat'), safety guarantees (no push/merge/self-approve), and execution isolation (worktree, grok/* branch). It stops short of describing lifecycle/polling or worktree cleanup, but it is meaningfully transparent for an execution 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?

Four compact sentences: purpose, return value, safety constraints, and dev-only scope. Every sentence earns its place; there is no filler. The most important information is front-loaded in the first sentence, making it easy for an agent to quickly grasp what the tool does.

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 complex tool with 20 parameters, no annotations, and no output schema, the description is solid but not complete. It sufficiently covers the tool's purpose, basic return value, and one clear delimitation, but it leaves a notable gap around workflow: whether a call is synchronous, whether the worktree persists, and how it relates to sibling tools like grok_delegate_poll or grok_delegate_status.

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% parameter description coverage, so the description need not restate parameter details. The high-level description adds useful context (lane implies a grok/* branch, goal is a coding goal for the executor), but it does not add significant semantics beyond what schema descriptions already provide.

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: 'Delegate a coding goal to local headless grok in an isolated git worktree on a grok/* branch.' It clearly differentiates itself from production/admin tooling with 'Dev-only — not the product admin-bridge' and gives a concrete scope for the operation.

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 clearly marks the tool as dev-only and declares a key exclusion: 'not the product admin-bridge.' It also communicates important constraints ('No push, no merge, no --always-approve') that shape when this tool is appropriate. However, it does not explicitly name alternative sibling tools or provide decision criteria relative to the many grok_agent_* and grok_delegate_* siblings.

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

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

With no annotations, the description carries full burden. It discloses that the tool is 'Read-only' and outputs 'diagnostic JSON', which are essential safety traits. It also explicitly warns against 'doctor fix', implying the fix variant could be mutating. It does not go into depth about auth or rate limits, but for a zero-param diagnostic, this is adequate.

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 extremely concise: a single sentence with a parenthetical command, a negation warning, and an output descriptor. Every phrase earns its place, and the most critical information (the exact command) is front-loaded.

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 simple, zero-parameter, read-only tool, the description is almost complete. It tells the agent what command to run, that it's read-only, and the output format. It lacks detail on what specific diagnostics are included, but given the lack of output schema and the low complexity, this is a minor gap rather than a critical omission.

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?

There are zero parameters, and the schema is empty, so the baseline for parameter semantics is 4. The description adds no parameter-specific meaning (there are none), but it does clarify that the command is run with --json, which is part of the tool's behavior rather than a schema parameter. No deductions needed.

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 clearly states the exact action ('Run `grok doctor --json`') and the resource ('grok doctor'), with a specific output format ('diagnostic JSON'). It distinguishes from sibling tools by explicitly excluding 'doctor fix', making the purpose unambiguous.

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?

Provides clear when-to-use context: run this read-only diagnostic command only, never the fix variant. It does not name alternative sibling tools, but the exclusion of 'doctor fix' serves as a usage boundary, which is strong guidance for a tool with zero parameters.

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

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

Given no annotations, the description carries the burden and clearly states 'Read-only' and the 'allowlisted' prerequisite, which are valuable behavioral traits. It could add more about output format or error behavior, but for a simple read tool, this is adequate.

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 sentences, front-loaded with the command, zero waste. Every word earns its place.

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 one-parameter, read-only tool with no output schema, the description is mostly complete. It clearly states the action and the '--json' flag implies JSON output. It could explicitly mention return values, but the command name provides enough context.

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 coverage is 100% and the parameter description already states 'Allowlisted project root to inspect.' The description repeats the same constraint without adding new semantics, so it doesn't go beyond the schema.

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 clearly states the tool runs `grok inspect --json` for an allowlisted project root, which is a specific verb+resource action. It distinguishes itself from sibling tools by focusing on inspection rather than starting, polling, or canceling delegates.

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 implies usage through the tool name and 'allowlisted' constraint, but it doesn't explicitly state when to use this tool over alternatives or provide exclusions. No mention of when to inspect vs. use status or doctor tools.

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

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

With no annotations provided, the description correctly carries the full burden. It explicitly states the operation is 'Read-only' and 'no secrets', covering safety and auth behavior. While it doesn't describe the output format, this is minimal for a simple list operation and adequate for agent decision-making.

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 short clauses: 'List available models via `grok models`' and 'Read-only; no secrets.' Every word contributes meaningful information with no redundancy, and the primary action is front-loaded.

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 parameterless, read-only tool, the description covers what it does, its safety profile, and auth requirements. It doesn't explicitly connect to the delegation workflow, but the tool name and sibling context provide sufficient background. Slightly more context about return values would improve it, but it's not a major gap.

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 tool has zero parameters, so the input schema fully covers everything. The description isn't required to add parameter details, and the baseline of 4 applies to parameterless tools.

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 uses a specific verb ('List') and a clear resource ('available models') while referencing the concrete command `grok models`. This makes the tool's purpose unambiguous and distinguishes it from sibling tools focused on delegation actions like starting or polling.

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: use when you need to list available models. It doesn't explicitly name alternatives or exclusions, but the tool's distinct purpose among the siblings makes the intended usage obvious without needing further guidance.

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

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

With no annotations, the description must carry the behavioral burden, and it does disclose the key trait (no write/edit/shell mutation, aligning with the schema's plan_only const=true). But it omits the async workflow — that this spawns a session to be polled via grok_delegate_poll — and says nothing about what it returns, which is significant for a no-annotation 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?

Two sentences with zero waste, and the defining constraint (read-only plan variant) is front-loaded. It is structurally efficient, though arguably thin for a 20-parameter tool — this is brevity rather than under-specification.

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 highly complex 20-parameter tool with no output schema and no annotations, one sentence is inadequate. The description fails to disclose the async interaction model (session spawning and polling via grok_delegate_poll) and the return shape, leaving an agent to guess the full workflow despite rich schema descriptions.

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 95%, so the schema already thoroughly documents all 20 parameters, including nuanced behavioral notes like lane_verdict's run-end semantics. The description adds no parameter-level detail, but at this coverage the baseline of 3 holds.

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?

Identifies the tool as the read-only plan variant of grok_delegate with plan_only=true, explicitly distinguishing it from the mutation-capable sibling via the write/edit/shell restriction. The verb is implicit rather than explicit (what plan output looks like is unstated), but the resource and its defining scope are clear.

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?

Naming the parent grok_delegate and stressing the read-only role implies when to reach for this tool (planning without mutation). However, there are no explicit exclusions or criteria — e.g., it never says 'use grok_delegate when you need to execute changes' — so the routing is left to inference.

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

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

With no annotations, the description carries full burden and succeeds: it declares read-only, details the phases (preflight/worktree/etc.), explains that a dispatch may initially have no process/lane directory, and tells how to distinguish normal from stuck server via the phase field.

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 information-dense and well-structured: it opens with the core purpose, then details the job_id path, clarifies a normal edge case, and closes with the no-job_id listing mode and read-only note. Every sentence contributes value.

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?

Despite having no output schema and no annotations, the description provides a thorough picture: output fields, phase values, the worker_pid condition, normal behavior for early dispatches, and the read-only nature. It is self-sufficient for an agent to invoke and interpret results.

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?

Although the schema already describes both parameters (100% coverage), the description adds significant meaning: it explains what job_id returns (state, result, live progress fields) and how the tool behaves without job_id. This goes well beyond the schema's basic definitions.

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 clearly states the tool polls a background delegation started with grok_delegate_start, distinguishing it from start/status siblings. It specifies both usage modes (with/without job_id) and the exact output contents.

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 context for use (polling delegations from grok_delegate_start, both with and without job_id) and explains the normal early-phase behavior to avoid false alarms. However, it does not explicitly mention when not to use it or compare to alternatives like grok_delegate_status.

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

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

No annotations are provided, so the description carries the full burden. It discloses genuinely useful behavior: background execution, immediate job_id return, long-running lanes, and a guarded profile with 'no push, no merge.' Gaps remain around failure behavior and job cleanup, but for an async-start tool this is above-average disclosure.

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?

Four compact sentences, each earning its place: purpose, why this variant exists, how to consume the result, and the safety profile. The purpose is front-loaded and there is zero redundant filler.

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 complex 20-parameter tool with no annotations and no output schema, the description covers the essential lifecycle: it starts a job, returns a job_id, and directs the agent to poll. It does not describe error responses or cancellation, but the key contract (start → job_id → poll) is fully stated.

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 100%, so the baseline of 3 applies. The description does not add parameter-level detail beyond the schema, but it doesn't need to — the schema already documents all 20 parameters in depth (e.g., lane_verdict and repo_root have rich 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 a specific verb-resource-mode: 'Start grok_delegate in the BACKGROUND and return a job_id immediately.' It differentiates from the sibling grok_delegate, and the mention of a job_id makes the async contract unmistakable.

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 states an explicit when-to-use condition: 'Use this instead of grok_delegate for real lanes', explains why (the synchronous call is killed by client timeout, leaving an empty worktree), and names the follow-up tool to poll with (grok_delegate_poll). This is exemplary routing guidance.

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

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It does so by explicitly stating 'Read-only' and noting that it checks auth presence 'without reading auth.json,' which is a valuable nuance about avoiding sensitive file access. It also lists the categories of information returned, giving the agent a good expectation of what the tool does and doesn't do. Minor gaps: no mention of whether it makes local calls only, or potential permissions needed, but for a status tool this is adequate.

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 single, well-structured sentence that front-loads the core purpose ('Structured health status') and enumerates the covered areas in a compact list. It ends with 'Read-only,' which is a critical safety qualifier. Every phrase earns its place, with no fluff or redundancy.

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 there is no output schema, the description needs to convey what the tool returns. It lists the major categories of health information, which is sufficient for an agent to know what to expect. It doesn't detail the exact output format or error handling, but for a simple read-only status-check with no parameters, the description is reasonably complete. It also includes the 'without reading auth.json' caveat, which is a crucial edge-case detail.

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 tool has zero parameters, so the baseline is 4. The description adds semantic value by explaining what the (empty) invocation will report—health aspects like binary version, auth, git, roots, and permissions—which goes beyond an empty input schema. This helps the agent understand the tool's output even though it has no arguments.

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 clearly defines the tool as a 'Structured health status' reporter, listing specific components (binary/version, auth presence, git availability, allowed roots/lanes_parent, permission and sandbox profile info). This is a specific resource and purpose, and it reads as a status/health check for the grok delegate system, distinguishable from sibling tools like grok_agent_status (agent-focused) and grok_delegate_doctor (diagnostic).

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 usage is implied: call this tool to get the current health/status of the grok delegate environment. The 'Read-only' qualifier suggests it is safe for routine inspection. However, it does not explicitly state when to use this versus alternatives like grok_agent_status or grok_delegate_doctor, nor does it provide exclusions. Without explicit guidance, the context is clear but not fully disambiguated from sibling tools.

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