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 several important traits: it applies a patch directly to the local repo, can create branches, run tests, and auto-commit using a 3-way merge. It does not mention error handling, failure modes, or side effects on an unclean working tree, which keeps it from a 5.

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 dense sentence with no wasted words, front-loading the core action and then listing optional behaviors. It could be slightly more scannable with a second sentence, but it remains efficiently sized and informative.

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 five-parameter tool with no output schema and no annotations, the description should explain more about expected results, such as what is returned after applying the patch, test results, or commit status. It covers the main workflow well but omits output/return behavior and practical prerequisites, leaving the agent to infer critical operational details.

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 is 3. The description adds only modest semantic context beyond the schema, such as 'clean git unidiff patch' for session_id and '3-way merge' for the application process, but does not systematically add meaning to each parameter.

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 (fetch and apply), a specific resource (clean git unidiff patch from a completed Jules session to a local repository), and the optional actions (branch creation, tests, auto-commit). It clearly differentiates from sibling tools like jules_get_patch, which only fetches a patch, by emphasizing direct application to the workspace.

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 context: you should use this when you have a completed Jules session producing a patch and you want it applied locally. However, it never explicitly states when to use this tool instead of alternatives like jules_get_patch or jules_verify_patch, nor does it give any exclusions or prerequisites such as requiring a clean working tree.

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 behavioral disclosure. It does state a meaningful effect ('so it can begin implementing changes'), but it does not clarify whether approval itself starts implementation or merely enables it, nor does it mention irreversibility, prerequisites, or possible side effects.

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, efficient sentence that front-loads the action and resource, and includes the intended consequence without any filler or repetition.

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 effect well. It lacks details about return values or error conditions, but the tool's simplicity makes the description reasonably 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 coverage is 100% and the only parameter, session_id, is already described in the schema as 'The session ID.' The description adds no additional parameter-level meaning, so the baseline of 3 applies.

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 ('Approve') and a specific resource ('multi-step execution plan generated by Jules'), and clearly states the purpose: enabling implementation. It is easily distinguishable from sibling tools like jules_get_plan (viewing a plan) and jules_dispatch_and_wait (triggering execution).

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 when to use the tool: after a multi-step plan has been generated and the user wants implementation to proceed. However, it does not explicitly state when not to use it or mention alternative tools, so the usage context is implied 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 full responsibility for behavioral disclosure. It states the core mutation action but does not mention side effects, whether the session disappears from lists, permission requirements, or what happens on success/failure. The existence of 'unarchive' implies reversibility but little else is transparent.

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?

A single, front-loaded sentence states the operation and resource with zero wasted words. It is appropriately terse for a simple two-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?

The tool is simple and the schema covers all parameters, but there is no output schema or description of return behavior. For an archive operation, the description is minimally adequate but leaves the agent without context on expected outcomes or edge cases.

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 is 3. The description adds no parameter-level meaning beyond what the schema already provides for session_id and unarchive.

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 pair (archive/unarchive) with a clear resource (session) and platform (Google Jules). It distinguishes itself semantically from sibling tools like jules_list_sessions or jules_delete_session by indicating a state-changing but reversible 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?

No guidance is provided about when to use this tool versus alternatives. It neither mentions sibling tools nor describes conditions for archiving vs unarchiving beyond the parameter default, which is already in the schema.

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 does disclose the key behavior: it targets all sessions in AWAITING_USER_FEEDBACK and sends them an unblocking directive. However, it omits potential side effects, idempotency, whether it can overwhelm sessions, or what happens when no sessions are stuck.

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 one dense, well-structured sentence. It front-loads the core purpose ('Autonomous unblocker') and the scope ('across the entire pool') without any filler or redundant wording.

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 tool with one optional parameter, the description is mostly sufficient for an agent to understand the operation. However, because it is a bulk action with no annotations and no output schema, it would benefit from more guidance on intended use, risks of nudging all sessions, and expected 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?

The input schema already documents the single optional custom_instruction parameter with a default value, and schema description coverage is 100%. The description adds no additional parameter-level meaning, so the baseline of 3 is 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 and resource: it automatically finds all sessions stuck in AWAITING_USER_FEEDBACK across the entire pool and sends a pre-emptive unblocking directive. It clearly differentiates from siblings by emphasizing the autonomous, pool-wide scope rather than single-session or manual interactions.

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 use case: unblock all stuck sessions without manual CLI nudging. However, it does not explicitly state when to prefer this over similar siblings like jules_reply_feedback, nor does it provide exclusions such as 'use only when many sessions are stuck' or 'avoid when human review is required.'

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 adds one useful behavioral trait—automatic load-balancing across the account pool—but it does not disclose whether dispatch is asynchronous, whether it returns immediately, what sessions/artifacts it creates, how failures are handled, or how to monitor progress. This is a significant gap for a tool that likely spawns long-running work.

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?

A single, front-loaded sentence conveys the core purpose and the key differentiating behavior, with no filler or redundant restatement of the tool name. Every phrase 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?

This tool has no annotations and no output schema, so the description is the sole source of operational context. It is not complete enough for an agent to know what happens after dispatch, whether it should wait, how to check results, or what constitutes success. Given the large sibling set around waiting, streaming, and sessions, the missing behavioral context is material.

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 description already covers the 'tasks' parameter at a high level, listing source, prompt, and optional title/auto_create_pr. The tool description adds contextual meaning by tying tasks to repositories and account-pool load-balancing, but it does not add per-field detail beyond the schema. Notably, the nested 'require_plan_approval' field is omitted from the schema's task description as well, but the description does not compensate.

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 ('dispatch') and resource ('multiple coding tasks across repositories'), plus a distinctive feature: automatic load-balancing across Google accounts. The batch/parallel nature implicitly differentiates it from single-task siblings like jules_dispatch_and_wait, but it does not explicitly name an alternative or exclusion.

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 'dispatch multiple coding tasks across repositories simultaneously' implies the intended use case: when an agent has several tasks to run in parallel. However, there is no explicit guidance about when not to use this tool, whether to prefer queue_tasks or dispatch_and_wait for sequential or single-task flows, or how this relates to the other dispatch 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 at all, the description carries the full burden of behavioral disclosure. It adds useful context: real-time monitoring, all-account scope, and the kinds of outcomes surfaced. However, it does not clarify whether this is a long-polling stream or a snapshot query, whether it can block, what the output shape is, or any rate-limiting/resource implications of scanning 'all Google accounts in the pool.' This is adequate but not rich.

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, both information-dense. The first sentence states what the tool does and what it detects; the second gives the canonical use case. No filler, and the most important scope detail ('across all Google accounts') 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?

Given the tool's high-level monitoring purpose and 100% schema coverage for its two optional params, the description covers most of what an agent needs to select and invoke it. The lack of an output schema makes the sparse return-format guidance slightly limiting, but the enumerated event categories partially compensate. An agent can reasonably tell this is a status-monitoring tool distinct from action-oriented siblings.

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 schema already documents both parameters well. The description does not add param-level meaning, but it does provide context for interpreting the results: completed sessions include PR/patch details. Since the schema carries the param documentation load, a baseline of 3 is 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 identifies a specific verb ('monitors/detects'), a clear resource ('events across all Google accounts in the pool'), and enumerates the exact event categories it surfaces: stuck, awaiting approval, completed, or failed. It also frames itself as the primary harness tool for status questions, which distinguishes it from siblings like jules_wait_for_task or jules_list_sessions.

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 names the intended use case: answering 'Is Jules done? Is Jules stuck?' It positions itself as the primary harness tool, which gives an agent guidance on when to prefer it over alternatives. It does not explicitly state when not to use it, but the primary-tool framing and status-oriented scope provide clear context.

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 does disclose meaningful behavior: uses 3-way unidiff application, runs tests, and creates a single PR. However, it does not mention side effects like pushing branches, modifying local repo state, GitHub auth requirements, or failure behavior.

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 core purpose, followed by a brief mechanism explanation. It avoids major fluff, though terms like 'clean' and 'without merge conflicts' are somewhat redundant.

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 7-parameter tool with no annotations and no output schema, the description gives a solid operational overview but leaves gaps around prerequisites, side effects, return/result shape, and when to avoid using the tool. The schema fills parameter details, but the agent still has to infer important operational constraints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 7 parameters have schema descriptions, so the baseline is 3 and the schema carries the parameter documentation load. The description adds high-level context about consolidation, drift resolution, and tests, but it does not add meaningfully to any specific parameter beyond what the schema 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 states what the tool does: reconcile and merge multiple concurrent Jules sessions on the same repository into a single local branch or unified PR. It uses a specific verb and resource and is clearly distinct from sibling tools like list/get/rebase/merge, though it does not name them explicitly.

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 a clear usage context: use it when there are multiple concurrent Jules sessions on the same repository that need consolidation. It implies this is for merging/session-reconciliation workflows, though it does not explicitly state when not to use it or name alternative 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?

No annotations are provided, so the description carries the full burden. It discloses that the dispatch is asynchronous and that the prompt is automatically decorated with system invariants, sandbox test runners, and anti-pause directives. This surfaces useful hidden behavior, though it does not mention PR side effects or return values.

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 purpose, and no filler. The second sentence earns its place by revealing automatic behavior that an agent would otherwise not know.

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 9-parameter, side-effecting, asynchronous tool with no output schema and no annotations, the description is thin on post-dispatch behavior—such as how results are tracked or which sibling tool should be used for follow-up. However, the asynchronous intent is clear and required parameters are obvious from the schema, making it minimally viable.

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 schema already documents all 9 parameters. The description adds no parameter-specific semantics beyond a general 'coding chore,' so the baseline of 3 is 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 opens with a specific verb ('Dispatch') and a concrete resource ('Google Jules'), and characterizes the operation as an asynchronous coding chore. It does not explicitly name sibling tools, but 'asynchronous' helps separate it from wait/recipe/batch variants.

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 given about when to use this tool vs. jules_dispatch_and_wait, jules_queue_tasks, jules_recipe_dispatch, or jules_batch_dispatch. 'Asynchronous' weakly implies fire-and-forget, but there is no explicit when/when-not or alternative naming.

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 burden of behavioral disclosure. It does state the operation is permanent and spans accounts, which conveys irreversibility and scope. It does not mention permissions, side effects on related data, or whether the action can be undone beyond the word 'permanently', so it is only moderately transparent.

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, tightly-worded sentence that conveys the essential action, scope, and irreversibility without any filler or repetition of schema details.

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 destructive tool, the description covers the key aspects: what is deleted, permanence, and cross-account scope. Minor gaps such as authentication requirements or effects on dependent resources remain, but they do not critically impair an agent's ability to call it 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 100% and the only parameter, session_id, is described as 'The session ID.' The description adds no further meaning about how to obtain or format the session ID, so the baseline of 3 applies.

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 clear verb ('delete'), a specific resource ('session from Google Jules'), and adds distinguishing scope ('across accounts') and permanence ('permanently'). This clearly differentiates it from related tools like jules_archive_session.

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: use this when you want a permanent, cross-account session deletion. However, it does not explicitly state when to avoid this tool or mention that archive_session is the non-destructive alternative, leaving the choice partially 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 the disclosure burden. It discloses that the call blocks/wait, and that it automatically injects architectural invariants, sandbox test runner commands, and anti-pause directives - useful non-obvious behavior. It does not cover failure or output behavior, so not a 5.

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, no filler, with the core purpose front-loaded and the behavioral note second. Every sentence 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?

Core dispatch/wait semantics and automatic injections are covered and all parameters are schema-documented, but with no output schema the description leaves the return value/result shape undisclosed and does not mention error/timeout outcomes; adequate but incomplete.

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?

Input schema has 100% description coverage for all 7 parameters, so the baseline is 3. The description adds no parameter-specific meaning 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 immediately states the specific action ('Create a new Jules coding task') plus the distinctive synchronous behavior ('immediately block/wait for it in a single MCP tool call'), which clearly separates it from siblings like jules_create_task and jules_wait_for_task.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'in a single MCP tool call' gives the agent a clear use context: use this when a combined dispatch-and-wait is wanted. It does not explicitly name alternatives or exclusions, so it falls 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?

The verb 'Retrieve' signals a read-only fetch, and the description narrows the scope to a single payload, which is useful. With no annotations, the description carries the burden, but it does not mention error behavior, response format, or any side-effect caveats.

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?

A single front-loaded sentence that states the action, object, and required identifiers with no filler. 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 simple two-parameter read operation, the description plus fully documented schema cover the essential call requirements. The lack of an output schema is partially mitigated by the phrase 'activity event payload', though error and edge-case behavior are not addressed.

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%, so the parameters are already documented by name and description. The description only restates that the tool uses session ID and activity ID as selectors and adds no extra format or constraint details.

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 ('Retrieve'), a specific resource ('single specific activity event payload'), and the identifiers that select it. It does not explicitly contrast with sibling tools like jules_list_activities, but the word 'single' distinguishes the getter from listing operations.

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?

Usage context is implied: use this when you already have both a session_id and an activity_id and need one specific activity payload. However, there is no explicit statement of when not to use it or which sibling, such as jules_list_activities, should be used instead.

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 behavioral disclosure. It scopes what artifacts are returned, but it does not disclose whether the operation is read-only, what the output format is (e.g., file paths, URLs, binary data), or any side effects. This is a significant gap for a tool with zero annotation coverage.

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?

A single sentence that is front-loaded with the action and resource, with no filler. Every word contributes meaning, including the examples that clarify the artifact types.

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 simple signature (one required parameter) and no output schema, so the description should explain what the caller receives. It says 'extract' but does not clarify whether the result is a list, files, or inline content. Given the lack of output schema and annotations, the description is not fully complete for an agent to confidently invoke it.

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 only parameter session_id has a description in the schema, so the baseline is 3. The tool description does not add extra meaning about how session_id is used beyond implying it identifies a Jules session. That is adequate but not additive.

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 ('Extract') and a clear resource ('visual media artifacts'), with concrete examples (screenshots, UI renderings, test failure images). This distinguishes it from sibling tools like jules_get_session or jules_get_patch, so an agent can tell what it does without ambiguity.

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 context: use it when you need visual artifacts generated in the sandbox. However, it does not explicitly state when to use versus alternatives, nor does it mention any conditions or exclusions. The context is clear but not 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?

No annotations are provided, so the description carries the behavioral burden. The verb 'Extract' reasonably signals a read-only operation and the description names the expected outputs, but it does not explicitly confirm no side effects or describe behavior when the session is not completed.

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?

A single 13-word sentence conveys action, resource, and precondition with no filler. Every element earns its place and the key output 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 one-parameter getter with no output schema, the description covers the input precondition and the main return content. It does not detail error conditions or the exact return envelope, but the tool is simple enough that this is a minor 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?

Schema coverage is 100% with a simple session_id description, so the baseline is 3. The description adds useful context beyond the schema by specifying the session must be completed and that the tool returns a cleaned patch plus commit message, which helps interpret valid inputs.

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 action ('Extract'), a concrete resource ('clean git unidiff patch and suggested commit message'), and a source ('completed session'). This clearly distinguishes it from siblings like jules_apply_patch, jules_verify_patch, and jules_get_session.

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 implies the tool is meant for sessions that have already completed, which is a useful usage condition, but it does not explicitly state when to prefer it over alternatives or mention any exclusions. The guidance is mostly implied rather than spelled out.

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 does disclose the output's nature (structured, numbered execution plan) and provenance (generated by Jules). However, it does not explicitly state whether this is a read-only operation, what happens when no plan exists, or whether any side effects occur.

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. It immediately identifies the action, the resource, and the scope, making it easy for an agent to parse quickly.

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 tool with no output schema, the description adequately conveys what is returned and for which session. It does not cover error cases or format details beyond 'structured, numbered,' but the tool is simple enough that this is a minor 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?

Schema description coverage is 100%, and the single parameter session_id is already described as 'The session ID.' The description adds only that the plan belongs to that session, which is mild extra context. The baseline of 3 is appropriate because the schema already handles 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 states a specific verb ('Extract') and a specific resource ('structured, numbered step-by-step execution plan generated by Jules for a session'). This clearly distinguishes it from sibling tools like jules_get_session or jules_get_activity, which retrieve different session-related information.

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 'for a session' gives clear retrieval context, indicating this is the tool to use when the structured plan for a session is needed. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to select it over obvious siblings like jules_check_events or jules_list_activities.

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. 'Retrieve' clearly signals a read-only operation, and the field list tells the agent what to expect in terms of content. It does not mention rate limits or failure behavior, but for a simple getter the core behavior is transparent.

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 verb and resource, then lists the payload in a compact colon-separated enumeration. Every word adds value and there is no repetition of schema 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?

For a low-complexity, single-parameter getter with no output schema, the field list gives an agent enough information to know what will be returned. It could still explicitly note that the operation is read-only and describe not-found behavior, but the core context is complete enough for correct 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?

The schema already provides full coverage for the single session_id parameter, including format examples. The description adds little beyond reusing the phrase 'session ID' and does not introduce defaults, constraints, or dependency semantics beyond what the schema already states.

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 ('Retrieve') and a clear resource ('a specific session ID'), then enumerates the exact details returned: status, PR URL, git patch diff, Jules Web URL, failure reason, and activity timeline. It distinguishes itself from list-style siblings by focusing on one session, though it does not explicitly separate itself from jules_get_patch or jules_get_activity.

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 tool is for fetching the full detail bundle for one session, which provides clear context. However, it gives no explicit guidance on when not to use it or which sibling to prefer, such as jules_get_patch for patch-only needs or jules_list_sessions for browsing multiple sessions.

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. It discloses that the operation retrieves metadata, branches, default branch, and privacy status, which clarifies the read-only nature and the general scope of returned data. However, it does not describe response structure, possible errors for unknown sources, or any access prerequisites beyond 'connected.'

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, tightly packed sentence that front-loads the core action and usefully enumerates the key returned categories. There is no filler or repetition of the tool name and 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 getter, the description covers the operation and the scope of returned data, and the schema fully documents the only parameter. However, with no output schema and no annotation context, the agent lacks information about the result shape, failure behavior, or how this tool relates to jules_list_sources, leaving some contextual gaps.

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 already has 100% coverage, describing the 'source' parameter with a concrete example and the alternative of using a bare repo name. The description adds no additional parameter-specific meaning beyond confirming the target is a 'specific connected repository,' so the schema-heavy baseline of 3 is 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 names a specific verb ('Get'), a clear resource ('source'), and lists concrete returned information: detailed metadata, branches, default branch, and privacy status. It explicitly scopes to 'a specific connected repository,' which distinguishes it from listing tools like jules_list_sources.

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 'for a specific connected repository' implies this tool should be used when the agent already has a source in mind and wants its details. However, it does not explicitly mention when to prefer jules_list_sources for discovery or name any exclusions, so usage guidance remains implied rather than stated.

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 implies a read-only operation and specifies what is returned, but it does not state the absence of side effects, failure behavior for invalid session IDs, availability constraints, or any pagination/limits despite saying 'all' commands.

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 with no filler. It front-loads the core action, resource, and output components, making it easy for an agent to quickly parse the tool's purpose.

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 inspection tool, the description adequately covers the main purpose and return content, especially given that there is no output schema. It falls slightly short of full completeness by omitting edge-case behavior such as empty logs, invalid sessions, or whether results are ordered or paginated.

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 covers the single parameter with 100% description coverage, so the description does not need to repeat it. However, the schema only says 'The session ID,' and the tool description adds no clarification about what kind of session ID is expected or how to obtain it, so parameter semantics remain at the baseline.

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 ('Extract') and clearly identifies the resource: all terminal shell commands executed inside Google's cloud sandbox, along with exit codes and stdout/stderr output. This unambiguously distinguishes it from sibling tools like jules_get_session or jules_list_activities, which deal with different data.

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 over alternatives, nor any exclusions or prerequisites. An agent must infer from the name and subject matter that it is for bash log inspection; the large sibling list provides no routing help.

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, and it discloses useful behavior: chronological ordering, multiple activity types, list/stream capabilities, pagination, and filter support. It stops short of fully explaining stream semantics, output shape, or error behavior, but it is substantially transparent for a read-oriented 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?

One dense, front-loaded sentence that communicates the resource, scope, event types, ordering, streaming, pagination, and filtering. Every phrase earns its place, and there is no filler 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?

For a tool with four schema-documented parameters and no output schema, the description covers the main invocation context: what activities are included, ordering, filtering, and pagination/streaming. It is slightly incomplete on output shape and streaming lifecycle, but it is sufficient for correct selection and basic 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 100%, so the baseline is 3. The description adds the context that filters are 'AIP-160' and that the result is paginated, but the schema already documents each parameter, so the description does not materially extend parameter 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 names a specific verb+resource: 'List and stream the full chronological activity trail for a session.' It enumerates event categories and adds distinguishing features (pagination, AIP-160 filters) that separate it from siblings like get_activity, stream_progress, and get_session.

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 makes the use case clear: an agent needing the full chronological activity trail of a session should use this tool. It does not explicitly say 'use X instead for a single event' or mention exclusions, but the event scope and pagination/streaming language provide strong contextual 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 present, so the description must carry behavioral disclosure. It transparently states the cross-account aggregation scope ('all pooled Google accounts') and the list/filter nature, which implies a read-only operation. It doesn't disclose pagination semantics beyond the token, sort order, or potential for large result sets, so it stays at the minimum viable level.

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?

A single sentence with no filler, front-loading the main action and scope before enumerating the filter dimensions. Every phrase 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?

The description is adequate for a list/filter tool whose five optional parameters are fully documented in the schema. However, with no output schema and no annotations, it doesn't describe the return format, pagination behavior across accounts, or filter combination semantics. For a moderate-complexity tool this is a visible gap, so 3 rather than higher.

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 is 3. The description adds no additional parameter meaning beyond paraphrasing the filter categories; all detail is already in the input schema. It doesn't compensate beyond the schema, but it doesn't need to.

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 verb ('List') and resource ('coding sessions'), and adds a distinguishing scope: 'across all pooled Google accounts' and specific filter dimensions. It separates this from siblings like jules_get_session (single session) and jules_list_activities without naming them, though it doesn't explicitly invoke a sibling.

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 when to use it—whenever you need to list or filter coding sessions across accounts—but gives no explicit exclusions or alternatives. It doesn't mention that jules_get_session should be used for a single session or jules_list_activities for activity logs. The guidance is implied, not stated.

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. It discloses the read-only listing nature, the cross-account aggregation behavior, and the presence of pagination and AIP-160 filtering. It does not detail auth requirements or exact response structure, but for a list operation the disclosed behavior is reasonably transparent.

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 entire description is one tightly packed sentence with no filler. It front-loads the core purpose and scope, then appends the extra capabilities it supports. Every clause adds 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?

For a read-only list tool with no required parameters and full schema coverage, the description is largely sufficient: an agent can call it with no arguments and understand what it returns at a high level. However, because there is no output schema, it would be stronger if it stated the exact shape of the returned source list rather than only mentioning branch metadata.

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 schema already documents all three parameters (filter, page_size, page_token). The description only references AIP-160 filtering and pagination at a high level, adding no new meaning beyond what the parameter descriptions already provide. This matches the baseline of 3 for fully covered schemas.

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 action ('List'), a specific resource ('connected GitHub repositories and sources'), and a clear scope ('across all configured Google Jules accounts'). It also lists distinctive features (branch metadata, pagination, AIP-160 filters) that distinguish it from sibling tools like jules_get_source or jules_list_sessions.

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 establishes when to use the tool: when an agent needs an aggregate listing of GitHub sources across all configured accounts. It does not explicitly name alternatives or exclusions, but the 'all ... across all configured accounts' framing provides enough contextual guidance to differentiate it from single-source 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It discloses the key side effect: deletion of the remote branch, and notes the external 'gh' dependency. It does not cover permissions, failure modes, or PR state after merge, but the main destructive behavior is explicit.

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?

A single sentence with the verb and target front-loaded; every phrase earns its place. The scope qualifier ('verified... opened by Google Jules') and the destructive side effect are included without 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 simple merge tool with complete schema coverage, this is nearly sufficient, but it lacks explicit preconditions, alternatives, or expected outcome guidance. Since there is no output schema, the description does not describe what a successful merge returns or how failures surface.

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 schema already documents all four parameters. The description adds no parameter-level detail beyond restating the default merge behavior and branch deletion that are already in 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 names a specific verb ('squash-merge'), a specific resource class ('GitHub PR opened by Google Jules'), and an explicit destructive follow-up ('delete the remote branch'). This clearly distinguishes it from siblings like jules_rebase_pr and jules_review_pr.

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 establishes a context: only verified PRs opened by Google Jules should be merged here. However, it does not explicitly name the verification workflow or say when NOT to use this tool, nor does it route to alternatives such as jules_verify_patch or jules_rebase_pr.

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 behavioral burden. It discloses that the operation is a read/check, and it specifies exactly which behavioral aspects are inspected (health, quota ledger, counts, capacity). It stops short of describing side effects or authentication needs, but for a status tool the non-mutating behavior is strongly implied.

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?

A single sentence delivers a complete, front-loaded description without any filler. The list of inspected dimensions is compact and every phrase adds 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?

For a zero-parameter, no-output-schema status tool, the description provides the essential context: the tool's scope (all Google accounts) and the expected content (health, quota ledger, counts, capacity). An agent has enough information to select and invoke it appropriately.

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 empty, so the default baseline of 4 applies. The description adds semantic value by explaining what the status output refers to, even though there are no parameters to clarify.

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 ('Check') and a specific resource ('pool status across all Google accounts'), then enumerates the concrete data dimensions: health, rolling 24-hour quota ledger, active vs completed counts, and remaining capacity. This makes it easy to distinguish from sibling tools that target events, tasks, sessions, or PRs.

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 scope is made clear: this is a pool-wide monitoring/status check across all Google accounts, which is a distinct context from the sibling tools. It does not explicitly name alternatives or exclusion conditions, but the use case is self-evident and no sibling appears to cover the same function.

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 does expose the key sequencing behavior: waiting for Task N to complete before launching Task N+1. However, it does not describe failure behavior, timeout handling, or the repository mutation side effects beyond executing tasks.

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 with the core operation front-loaded. There is mild redundancy between 'sequence of chores sequentially' and the explicit wait-before-next explanation, but no filler or irrelevant detail.

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 3-parameter tool with no annotations and no output schema, the description covers why and how the tool sequences tasks but omits return values, failure modes, and timeout consequences. It is sufficient for selecting the tool, but less complete for predicting the full call experience.

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 schema already documents tasks, source, and timeout_per_task adequately. The description adds no meaningful parameter semantics beyond referring to tasks as 'chores', which is not especially informative.

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 and resource: executing a sequence of chores sequentially on a repository. The wait-for-previous-task semantics clearly distinguish it from sibling tools like jules_batch_dispatch or jules_dispatch_and_wait. It fully conveys the tool's purpose without relying on the name alone.

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 a clear use context by explaining the sequential execution prevents branch drift and merge conflicts across PRs. It does not explicitly name alternative tools or state when not to use this tool, so it stops short of full 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?

With no annotations provided, the description carries the full burden. It discloses the key behavior: rebasing locally and force-pushing with lease, which implies history rewriting. However, it does not mention potential conflicts, required working-tree state, permission implications, or what happens on failure. The force-push-with-lease detail helps but is not fully comprehensive.

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?

A single, dense sentence that front-loads the core operation, includes the method (force-push with lease), and states the intended outcome. No filler or redundant 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?

For a mutation tool with no annotations and no output schema, the description covers the high-level operation and rationale but omits practical details such as conflict handling, prerequisite local repository state, and failure behavior. It is adequate for an informed agent but 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?

Schema coverage is 100%, so the baseline is 3. The description adds the context that rebase targets the latest base branch and mentions 'main' as an example, which mildly reinforces base_branch semantics, but it does not meaningfully expand on repo_path or pr_url_or_number beyond what the schema already states.

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 (rebase), the resource (an existing Jules GitHub PR), the target (latest base branch), and the mechanism (local rebase followed by force-push with lease). It clearly differentiates from sibling tools like jules_merge_pr because it is explicitly about rebasing rather than merging.

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 identifies the concrete scenario for use: eliminating PR collision and out-of-date branch warnings on GitHub. It does not explicitly mention when not to use it or compare against sibling alternatives, but the intended trigger conditions are 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 present, the description carries the full burden of disclosing behavior. It does not mention that auto_create_pr defaults to true, that wait_for_completion controls synchronous blocking, that a GitHub PR may be created, or what side effects occur on the source repository. Phrases like 'Eliminates prompt ambiguity' and 'ensures optimal output quality' are promotional rather than behaviorally informative.

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 verb and examples, but the second sentence ('Eliminates prompt ambiguity and ensures optimal output quality') is subjective filler that does not add operational value. It is compact yet not every sentence 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 tool with six parameters, no annotations, and no output schema, this description is insufficient. It omits crucial context such as the default PR-creation behavior, whether the call blocks, what artifacts or results are produced, and how this differs from sibling dispatch tools. An agent would lack the information needed to safely invoke it in a real workflow.

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 is 3. The description repeats the recipe names already documented in the schema but adds no new operational meaning about source, target_path, or the boolean flags. It neither compensates for gaps nor contradicts 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 uses a clear verb-resource pair: 'Dispatch a standardized... chore recipe' with concrete examples like 'scaffold-unit-test' and 'add-strict-types'. It is specific enough to understand the tool's core job, but it doesn't explicitly differentiate itself from closely related siblings such as jules_dispatch_and_wait or jules_batch_dispatch.

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 no guidance on when to use this tool versus alternatives, no exclusions, and no conditions. The recipe examples imply some use cases, but the tool's relationship to jules_dispatch_and_wait, jules_batch_dispatch, or jules_queue_tasks is never addressed, leaving selection 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?

The description clearly states the core action: sending a message directly to a session. However, with no annotations, it does not disclose additional behavioral details such as whether sending resumes the session, whether it can be called multiple times, or what error/response behavior to expect.

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?

One efficient sentence with no filler. The action and target are front-loaded, and the message-type list earns its place by clarifying exactly what the tool is for.

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 tool with full schema coverage and no output schema, the description provides enough context to select and invoke it correctly. It could mention post-conditions, but the target context and purpose are clear.

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 schema already describes both parameters sufficiently. The description does not add parameter-specific details, but the baseline of 3 applies because the schema does the heavy lifting.

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 ('Send'), names the resource ('in-progress or paused session'), and enumerates the message types (feedback, clarification, steering). This clearly distinguishes it from sibling tools that check events, create tasks, or approve plans.

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 when to use the tool: when sending user feedback, unblocking a clarification, or providing follow-up steering. It does not explicitly name alternatives or exclusion cases, but the target session state is specified.

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 behavioral burden. Words like 'Inspect', 'review', and 'pulls ... via gh' convey a non-mutating fetch operation and identify the underlying mechanism. It does not fully document auth requirements or error behavior, but these are minor for a read-only PR inspection 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?

One compact, front-loaded sentence uses a colon list to convey the tool's scope and data sources. There is no filler or redundant restatement of the name.

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, read-only review tool with no output schema, the description plus schema is sufficient for an agent to choose and invoke it correctly. It states what data will be gathered, implies non-mutation, and the schema covers parameter meaning.

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 already documents both parameters at 100% coverage, including the nuance that repo is required when only a PR number is passed. The description adds no parameter-level detail, so it earns the baseline 3 for a well-covered 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 opens with a specific verb-object pair ('Inspect and review a GitHub PR') and enumerates exactly what is gathered: PR metadata, review comments, diff stats, and CI status checks. This clearly differentiates it from mutating siblings like jules_merge_pr and jules_rebase_pr.

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 establishes a clear use context: reviewing/inspecting a GitHub PR created by Google Jules. It does not explicitly name alternatives or state when not to use it, but the intended selection scenario is evident enough.

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 behavioral burden. The verb 'Extract' and the focus on producing a markdown breakdown imply a read-only, non-destructive operation, and the output composition is clearly disclosed. However, it does not explicitly state side-effect safety, permissions, streaming behavior, or error conditions, which would improve transparency without 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, information-dense sentence with the verb and primary deliverable front-loaded. Each clause earns its place by naming a distinct output section, and there is no 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?

The tool is simple: one required, fully documented parameter, and the description compensates for the missing output schema by enumerating the expected markdown sections. The main gaps are the lack of explicit sibling differentiation and edge-case behavior, but for a single-parameter read-style tool the core context is well covered.

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%: the only parameter, session_id, is already described as 'The Jules session ID to inspect.' The description adds no new parameter-level meaning beyond echoing the session concept, so the baseline score of 3 applies.

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 operation ('Extract') and a concrete output resource ('structured markdown progress breakdown for a session'), then enumerates the included components: plan checklist, reasoning trail, files modified, and sandbox commands. This clearly separates it from generic session or plan tools among the siblings.

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 when to use this tool: when a consolidated progress breakdown covering checklist, reasoning, files, and commands is needed. However, it gives no explicit guidance on when to prefer it over related sibling tools like jules_get_session, jules_get_plan, or jules_inspect_bash_logs, and no exclusion criteria.

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 disclosure. It does meaningfully reveal that the tool runs tests locally and opens real GitHub PRs through the external 'gh' CLI, which are important side effects. However, it does not disclose authentication prerequisites, whether patches are applied to the local repo, or what happens on test 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, compact sentence with a colon-led sequence that is easy to parse. Every phrase adds value: 'local', 'verify with tests', 'open GitHub PRs', and 'via gh' are all useful specifics. The high-level intent is front-loaded before the sub-steps.

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 multi-step automation that can create real GitHub PRs, the description is too thin on scope and outcomes. It does not state where patches come from, whether existing PRs are updated or new ones created, or what is returned when sessions fail. There is no output schema, so the description needed to carry more of that context and did not.

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 parameters are already documented and the baseline is 3. The description weakly reinforces repo_path and test_command through 'local' and 'verify with tests', but it adds no new parameter-level meaning beyond the schema. This is acceptable given the schema already covers all three parameters.

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 workflow: extract patches, verify with tests, and open GitHub PRs via 'gh'. This goes well beyond the tool name and distinguishes it from read-only or single-step siblings like jules_verify_patch or jules_get_patch. It does not explicitly contrast with the alternative PR tools, but the high-level intent is 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?

There is no guidance on when to choose this tool over alternatives like jules_verify_patch, jules_apply_patch, or jules_merge_pr. The phrase 'Run local autopilot' weakly implies an automated batch workflow, but no when-to-use or when-not-to-use context is provided. The schema hints at optional session selection, but that is parameter behavior, not usage 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 carries the behavioral disclosure burden. It clearly conveys a non-mutating dry-run, the exact command executed, and the meaning of success (0 conflicts). It does not describe the result format or failure modes, but the core side-effect and operation behavior are transparent.

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?

One dense sentence front-loads the core purpose ('Dry-run preflight check') before technical detail. It is slightly long because of the quoted git command, but every part contributes to understanding the tool's behavior.

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 two-parameter check tool with no output schema, the description covers the tool's purpose, operation, preconditions, and non-destructive nature. The main missing piece is exactly how the verification result is returned, but this is enough for an agent to select and invoke 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 100%, and both parameters already have clear meanings (session_id containing the patch, repo_path as absolute local path). The description adds minor contextual framing ('completed session', 'local workspace') but no substantive new parameter semantics, so the baseline 3 applies.

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 precise verb ('verify') on a specific resource (a completed session's git patch) and names the concrete mechanism ('git apply --check --3way'). The 'Dry-run preflight check' framing clearly separates it from apply-or-write siblings, so an agent can tell what this tool does.

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 clear usage context: use this before creating branches or writing files, to confirm a patch will apply cleanly. It does not explicitly name alternatives (e.g., jules_apply_patch) or list when not to use it, so it stops short of full exclusion 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 carries the full burden, and it does disclose key behavior: blocking/polling, the terminal conditions it waits for, and the async-to-harness bridging. However, it does not disclose what the tool returns, whether it exits with partial states, or what happens on timeout or when a session is not found.

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 core polling/waiting behavior stated first. The second sentence adds useful architectural context, though it is slightly abstract and not strictly necessary.

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 what the tool waits for, and parameter documentation is complete, but the absence of an output schema or any mention of return values leaves an important gap. An agent invoking a blocking wait tool would benefit from knowing what result shape or status it receives when the wait ends.

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%, so the schema already documents all five parameters clearly. The description adds minimal value beyond that, though it does contextualize the plan approval and question-asking states that relate to auto_approve_plan and auto_unblock_questions.

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 action (poll/wait), the resource (a Google Jules session), and the stopping conditions (completion, failure, plan approval request, or question asking). It also hints at its differentiating role by bridging async cloud execution into the harness, though it does not explicitly name sibling tools.

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?

Usage context is implied: it is for synchronously waiting on an already-running async Jules session. However, there is no explicit guidance on when to choose this over alternatives like jules_stream_progress, jules_check_events, or jules_dispatch_and_wait, nor any when-not-to-use guidance.

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