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

The description goes beyond the annotations by explicitly stating that cancellation includes the child process tree, which clarifies the destructive scope. It aligns with destructiveHint=true and idempotentHint=true, adding specific behavioral detail without contradicting annotations.

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 action and includes the key effect. No wasted words.

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 one-parameter tool with no output schema, the description covers the core purpose and the key destructive effect (child process tree). It is sufficiently complete for an agent to invoke correctly, though it lacks explicit mention of using grok_list to discover job IDs.

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?

With schema description coverage at 0%, the description only indirectly references the job_id through 'one known', but it does not explain where to obtain it or any additional constraints. The schema already provides UUID format, so the description adds minimal semantic value beyond that.

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' and identifies the resource 'one known Grok Bridge background job and its child process tree', clearly distinguishing it from siblings like grok_start, grok_poll, and grok_list. It explains both the action and the scope.

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 when a known job ID exists and you want to cancel it, but it does not explicitly mention alternatives (e.g., use grok_list to find job IDs) or when not to use it. The phrase 'one known' hints at a prerequisite but provides no direct 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?

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds 'synchronous' and 'uses xhigh reasoning by default,' which are useful behavioral details beyond what annotations provide. It also reiterates 'cannot edit files,' reinforcing the read-only nature without contradicting the annotations.

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-loaded with the primary action and followed by a key behavioral note. Every phrase adds value—there is no repetition or 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?

The tool has 9 parameters and no output schema, yet the description does not hint at what the tool returns or how the response is structured. It provides enough context to use the tool but leaves significant gaps about the result format and error behavior.

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 22%, with most parameters undocumented. The description does not explain the meaning or usage of the parameters beyond mentioning the default effort ('xhigh reasoning'), which is already present in the schema. It fails to compensate 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 starts with a specific verb ('Run') and identifies the resource ('Grok second opinion') and scope ('synchronous, read-only'), with explicit use cases (planning, research, analysis, code review). It distinguishes from sibling tools like grok_start and grok_poll by emphasizing synchronous behavior.

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 clearly implies the intended use case (a one-off, synchronous consultation) and contrasts with the asynchronous workflow implied by sibling tools. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of a full 5.

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 already declare readOnly, idempotent, and non-destructive behavior. The description adds context about the scope of the check (specific components), but does not disclose additional behavioral traits such as what happens if something is not ready or whether it returns a report. It neither contradicts annotations nor adds rich behavioral detail.

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 that lists exactly what is checked. Every word carries meaning and there is no fluff. It is appropriately concise for a zero-parameter health-check 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?

Given the simplicity (0 params, annotations covering safety), the description is mostly adequate, but it does not mention what the tool returns or what 'ready' means in practice. Since there is no output schema, the description should clarify the result format (e.g., a summary, a boolean, error indications). This gap prevents a high completeness score.

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 zero parameters, so the baseline for parameter semantics is 4. The description does not need to explain parameters, and it doesn't add any misleading parameter info. This score reflects the fact that no parameters exist and no clarification is required.

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 the verb 'check' and names the resource 'Grok Bridge' (from the title), specifying four readiness aspects. It clearly distinguishes this tool from siblings like grok_start or grok_consult because it is a diagnostic check. A slight deduction because 'ready' is not precisely defined, but the intent is 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?

The description implies usage when you need to verify readiness of Grok Build, local auth, bridge runtime, and xhigh defaults. No explicit when/when-not alternatives are given, but the imperative 'Check whether' conveys a diagnostic scenario. This is an implied-usage situation, not a clearly contrasted one.

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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the output format (Markdown) and the purpose, but does not disclose behaviors like truncation via max_chars or error handling. With annotations present, this modest addition merits a 3.

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 that front-loads the action and output format, with no unnecessary words. It earns every word and stays compact.

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 two-parameter export tool with strong annotations, the description covers the core function and return format. It could be more complete by explaining max_chars behavior and edge cases, but it is largely sufficient for selection and 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%, so the description must compensate. It only implies the role of session_id via 'a Grok session transcript' and never mentions max_chars or its effect on the output. The agent is left to infer the meaning of max_chars from the schema's min/max/default values, which is insufficient.

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 ('Export'), identifies the resource ('a Grok session transcript'), and specifies the output format ('as Markdown'). It also states the intended purpose ('so another ChatGPT session can inspect prior delegated work'), clearly distinguishing it from sibling tools like grok_list or grok_cancel.

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 for when to use the tool: when you need to share a Grok session transcript with another ChatGPT session. However, it does not explicitly mention when not to use it or point to alternative tools, so it stops short of a 5.

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 already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds that it lists 'recent' items and a 'local session index,' which gives some behavioral context but does not explain pagination, output format, or what 'recent' means.

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 long, front-loaded with the action and resource, and every word contributes meaning. It is concise and 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?

For a simple list tool with good annotations, the description is adequate but has gaps: it doesn't define 'recent' or 'bridge jobs,' and it omits any explanation of the limit parameter. These omissions leave some ambiguity for an AI agent.

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 mention the 'limit' parameter at all. Although 'limit' is self-explanatory by name, the description should compensate for the missing schema description by stating it controls the number of returned items.

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 ('List') and the resources ('recent bridge jobs plus Grok's local session index'), which is specific and distinguishes it from sibling tools like grok_start or grok_cancel. However, it doesn't explicitly differentiate itself from siblings by naming alternatives, so it falls short of 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 phrase 'useful for resuming work across ChatGPT sessions' provides a clear use case but does not explicitly state when not to use the tool or mention alternatives. This is implied usage guidance rather than explicit when/when-not/alternatives.

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 already indicate a safe read-only, idempotent operation. The description adds valuable context by explaining that polling should continue while the job is queued/running and that log tails are bounded, which helps the agent understand the expected call pattern.

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 two-sentence summary that front-loads the core action and provides essential polling guidance without any 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 simple read/poll tool with annotations covering safety and idempotency, the description covers the key behavior (what is read, when to poll). It could mention return values in more detail, but there is no output schema, and the description gives enough to use the tool correctly.

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 for parameter meanings. It mentions 'bounded log tails' but doesn't explicitly connect it to max_chars, and job_id is only implied. The parameter names are somewhat self-explanatory, but the description adds little beyond the schema constraints.

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 read operation for background Grok jobs, specifying that it retrieves state, final result, and bounded log tails. It distinguishes itself from siblings like grok_start and grok_cancel by focusing on polling an existing job's 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 usage context: poll repeatedly while the job state is queued or running. It doesn't explicitly name alternative tools, but the sibling names (e.g., grok_list, grok_cancel) and the polling nature make the intended use 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?

The description adds behavioral details beyond the annotations: it states the job is durable and background, may edit files/run commands in cwd, and requires polling. These specifics align with the destructiveHint and openWorldHint annotations without contradiction.

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 concise sentences front-load the verb and core purpose, with no fluff or redundancy. Every sentence adds value (purpose, side effects, workflow).

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 covers the essential workflow, safety, and return via job_id, but given no output schema and 9 parameters, it omits details about optional parameters and the meaning of 'terminal.' It is sufficient for a basic agent but not fully complete for complex usage.

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?

With schema description coverage at only 22%, the description must compensate but only touches on cwd ('inside cwd') and role (via 'implementation, debugging, testing, or review'). It does not explain parameters like effort, model, max_turns, web_search, timeout_seconds, or resume_session_id, leaving them ambiguous.

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 the verb 'Start' to indicate an action, specifies the resource as 'durable background Grok job,' and lists intended purposes (implementation, debugging, testing, review). This clearly distinguishes it from siblings like grok_consult or grok_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 provides clear context that this is for long-running background jobs and advises polling the job_id, but it does not explicitly state when to use this over alternatives such as grok_consult for shorter interactions. No when-not guidance is given.

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