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

Annotations already carry the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the bar is lower. The description adds that this is a state transition for awaiting-approval sessions, which is consistent with the annotations. However, given openWorldHint=true, it neither discloses post-conditions (what state the session reaches after approval, whether approval triggers plan execution) nor potential side effects — a real gap for a mutating action.

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 eight-word sentence with zero filler. The core verb ('Approve') comes first, and the scoping condition ('awaiting plan approval') follows immediately. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter tool with a straightforward action, the description is mostly adequate. But with no output schema and openWorldHint=true, the agent is left uninformed about what the approval does (state transition, triggering of execution, return value). Given the richer workflow implied by siblings (monitor_session, send_message, extract_pr_from_session), a sentence on the post-condition would meaningfully complete 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 description coverage is 100% — the single required session_id parameter is already documented in the schema ('The Jules session ID'). The description adds only marginal semantic value by constraining that the session must be in an awaiting-approval state. Baseline 3 is appropriate since the schema does the heavy lifting and the description adds no syntax or format detail.

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 resource ('plan for a session'), and the qualifier 'awaiting plan approval' pins down the exact session state to which it applies. This clearly differentiates it from siblings like jules_get_session, jules_send_message, and jules_create_session — an agent can tell what this tool does and what it's not without opening the schema.

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 target condition is implicit in 'for a session awaiting plan approval,' which tells the agent when the tool is relevant. However, there is no explicit statement about checking session state first (e.g., via jules_get_session), no exclusions (e.g., what to do if the session isn't awaiting approval), and no named alternatives. Usage context is present but mostly 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?

The annotations already mark this as non-read-only and idempotent, but the description adds the key behavioral detail that archiving hides the session from the default list and that the API default list excludes archived sessions. It also discloses reversibility by naming the unarchive sibling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler: the first states the action and the second explains the consequence and the inverse operation. 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 single-parameter archive operation with no output schema, the description covers the action, the side effect, and the restoration path. An agent has everything needed to invoke this 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?

The sole parameter session_id is fully described in the schema (The Jules session ID to archive), so the description adds no further parameter semantics. Per the baseline rule for high schema coverage, this is adequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Archive' and names the resource 'Jules session,' clearly distinguishing this from the sibling operations (delete, create, unarchive). It also explicitly names the inverse operation jules_unarchive_session, so an agent can tell these tools apart.

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

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

It states the effect (archived sessions are hidden from the default list) and points to jules_unarchive_session for restoration. This gives an agent the context for when archiving is appropriate, though it doesn't explicitly mention alternatives like permanent deletion via jules_delete_session.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds valuable behavioral context by specifying the exact one-letter return codes and their meanings, plus the auto-resolve behavior. It does not contradict 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 very short and every sentence contributes: it states the tool's token-saving purpose, defines its output codes, and explains how to target the session. There is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a lightweight status-check tool, the description explains the output codes and input options well, which is especially important since there is no output schema. It could go slightly further by mentioning when to prefer richer siblings such as jules_monitor_session, but the essentials are 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 description coverage is 100%, so the schema already documents repo, owner, branch, and session_id. The description confirms the relationship between session_id and owner/repo, but this is also present in the schema and adds little beyond it.

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 ('token-saving status check'), identifies the resource ('current Jules session'), and explains the return format with one-letter codes Q/C/F/N. The 'minimal output' framing in the title and description distinguishes it from richer sibling tools like jules_get_session or jules_monitor_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 gives clear input guidance: provide session_id directly, or use owner/repo to auto-resolve the current project session. It does not explicitly say when not to use this tool or name an alternative like jules_monitor_session, but the token-saving framing makes the intended lightweight status-check use case 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?

Annotations already convey mutation with readOnlyHint=false and idempotentHint=false. The description adds no behavioral context beyond 'create', such as whether creation is asynchronous, whether it returns a session ID, whether it starts background work, or what side effects occur. With no output schema, this is a meaningful gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single concise sentence with no wasted words; it front-loads the core action and resource. The only weakness is that it adds little beyond the title, but that does not detract from its tightness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite 9 parameters and no output schema, the description does not explain the return value, the session lifecycle, or what happens after creation. Given sibling tools like jules_monitor_session and jules_send_message, missing workflow context makes this definition incomplete for reliable tool selection.

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 includes detailed descriptions for all 9 parameters, including automationMode's enum semantics and notes about PR creation. The tool description itself adds no parameter-level meaning, so it meets the baseline for schema-heavy tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: create a new Jules coding session for a GitHub repository. It is clearly a create/start operation and is distinguishable from sibling get/list/delete tools, though it could be strengthened by explicitly mentioning the first step in a session workflow.

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 on when to use this tool versus alternatives, such as when to choose jules_send_message or jules_get_session. The description implies creation is for starting work, but provides no exclusions or workflow 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?

The description adds nothing beyond the annotations: destructiveHint=true and idempotentHint=true already communicate the core safety profile. It does not disclose whether deletion is permanent, whether it can be undone, or any side effects on related data.

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 tight sentence with no filler or repetition of schema content. It is appropriately front-loaded and concise, though it could also include a brief behavioral warning without becoming bloated.

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 delete operation, the schema and annotations carry most of the burden: the parameter is documented and the destructive/idempotent behavior is annotated. However, the lack of any statement about permanence or how delete compares to archive leaves an important gap for an agent deciding whether deletion or archiving is intended.

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 fully describes the single parameter session_id as 'The Jules session ID', so the description does not need to compensate. It also adds no extra meaning beyond the schema, 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 uses the specific verb 'Delete' with the explicit resource 'Jules session', making the operation unmistakable relative to sibling tools like get/list/create. It clearly states what the tool does in one unambiguous phrase.

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 guidance on when to use delete versus alternatives such as archive_session or unarchive_session. There are no when-to-use conditions, prerequisites, or warnings about preferring archive over deletion.

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 goes well beyond the annotations by explaining conditional behavior: returns the full PR when AUTO_CREATE_PR was used, returns changeSet when present, and still returns changeSet when only a patch was produced. This gives the agent a clear model of the tool's edge cases without contradicting the readOnly/idempotent 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?

Two sentences, front-loaded with the primary purpose, followed by concise conditional return details. Every clause adds necessary information and there is no filler or repetition of the tool name/title.

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 single parameter, no output schema, and rich annotations, the description covers the key return scenarios and fields well. It could be slightly more complete by stating what happens when neither a PR nor a changeSet exists, but for a one-parameter extraction tool 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?

The schema already documents session_id as 'The completed Jules session ID' with 100% coverage. The description reinforces the 'completed' aspect but adds no new parameter-level semantics beyond what the schema already provides, 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 uses a specific verb and resource: 'Extract pull request and/or change set information from a completed Jules session's outputs.' It clearly distinguishes this from sibling tools by focusing on PR/changeSet extraction rather than session retrieval or management, and it details exactly what is returned based on session conditions.

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

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

The description provides clear context: this tool is for completed sessions and extracts PR/changeSet data. It implies when to use it (after a session is done) and what to expect, but does not explicitly mention alternatives or state when not to use it versus tools like jules_get_session or jules_get_activity.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior, so the description does not need to repeat safety traits. It adds no further behavioral context, such as behavior for missing or invalid IDs or session scoping enforcement, beyond what the schema and annotations convey.

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 short sentence conveys the operation, the target resource, and the scoping. 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 low-complexity read tool with strong annotations and complete parameter documentation, the description is sufficient for an agent to invoke it. The only minor omission is lack of detail about the returned activity shape or error behavior, but this is a simple get-by-ID operation.

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 both parameters are documented. The description adds no extra semantics beyond restating that lookup is by activity ID within a Jules session, leaving the schema as the source of 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 uses a specific verb ('Get'), resource ('activity'), and selection mechanism ('by ID'), and scopes it to a Jules session. This makes the tool's purpose unambiguous and distinguishes it from sibling jules_list_activities, which retrieves multiple activities.

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 'by ID' and 'for a Jules session' imply the tool should be used when the caller already has an activity ID in a known session. However, it does not explicitly state when not to use it or mention alternatives such as jules_list_activities to first obtain the ID.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds that the tool returns metadata, state, and outputs, but does not disclose potential errors, access requirements, or whether the 'outputs' are full transcripts or summaries. No contradiction exists.

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, front-loaded sentence with no fluff. Every word helps the agent understand what the tool does.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only getter with one parameter and no output schema, the description adequately conveys the return categories. It is sufficient for an agent to call the tool correctly, though a brief note about what 'outputs' contains would make it fully self-sufficient.

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 sole parameter session_id is already described as 'The Jules session ID'. The description adds no further meaning to the parameter beyond what the schema provides, so the baseline 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 specifies a clear verb, 'Fetch', and a specific resource, 'session', while enumerating the kind of data it returns: metadata, state, and outputs. This is distinct from listing sessions or fetching activities, though it could have explicitly disambiguated against 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?

No explicit guidance is given about when to use this tool versus the many sibling tools. The singular 'session' implies a single-session lookup, but alternatives such as jules_list_sessions or jules_get_activity are never mentioned, 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, but the description adds no behavioral information beyond 'get details.' It does not describe error behavior, return format, or any caveats about source_id resolution. It doesn't contradict annotations, but also doesn't add context beyond them.

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 short sentence, no fluff, front-loaded with the verb and object. It is efficient for the low complexity of this 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?

With one required parameter, strong annotations, and high schema coverage, the description is minimally viable, but it leaves 'details' undefined and provides no guidance about what response to expect or when to prefer this tool over siblings. For a very simple getter this is adequate but not complete.

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

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

Schema description coverage is 100%, so the schema already documents source_id as 'The source ID.' The description only paraphrases 'a specific source,' adding no format, source, or usage semantics beyond the schema. Baseline 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 the operation ('Get details') and the resource ('a specific source'), which is enough to distinguish it from list-oriented sibling jules_list_sources. However, it doesn't explicitly differentiate itself from other get-type tools or state what 'details' include.

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 on when to use this tool versus alternatives such as jules_get_activity or jules_list_sources. An agent must infer from the name and the single source_id parameter that this is for individual-source lookup; the description provides no explicit when/when-not conditions.

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 annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, but the description adds no behavioral detail such as pagination behavior, ordering, or response framing. It restates the listing operation without disclosing anything beyond the structured hints.

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 short sentence with no filler or redundant clauses, making it easy to parse. It is concise, though it could carry more semantic content without becoming verbose.

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?

Annotations cover safety and the schema covers all parameters, so the core call can be constructed from structured data alone. However, there is no mention of the return shape, pagination flow, or when this list operation is appropriate, leaving some context 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?

All three parameters are documented in the input schema, including descriptions for pageSize, pageToken, and session_id, so schema coverage is effectively 100%. The description adds no parameter-level meaning beyond the schema, 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-resource pair ('List activities') and scopes it to a Jules session, matching the title and the required session_id parameter. It is not a tautology, but it does not explicitly distinguish itself from the sibling jules_get_activity beyond the implied list-versus-get distinction.

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 such as jules_get_activity or jules_list_sessions. The description simply states the operation and leaves all selection context to the agent's 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?

Annotations already disclose read-only, idempotent, open-world, and non-destructive behavior, so the description's burden is lower. The description adds the default non-archived behavior and the includeArchived/filter interaction, but much of this is also present in the schema property descriptions. It contributes useful context but does not add substantial behavioral detail beyond the annotations and schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences with no wasted words. It front-loads the primary purpose, then gives the default behavior, then lays out the two options for modifying archival filtering. Every sentence serves a clear decision-relevant 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 read-only list tool, the description plus annotations and full schema coverage are largely sufficient: purpose, filtering behavior, and parameter semantics are all covered. The main gap is that no output schema exists and the description does not describe the shape or ordering of returned sessions, but 'List sessions' plus the tool title makes the return expectation reasonably 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 description coverage is 100%, and the schema already documents filter, pageSize, pageToken, and includeArchived with examples and override behavior. The description only repeats the includeArchived and filter concepts without adding new parameter-level meaning. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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?

Description states a specific verb ('List') and resource ('Jules sessions'), making the tool's core function immediately clear. It also clarifies the default scope (non-archived) which adds precision. It does not explicitly distinguish itself from jules_get_session or jules_list_sources, but the plural resource and list semantics make that distinction reasonably inferable.

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

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

Provides clear usage context for the main decision: by default non-archived sessions are returned, includeArchived=true changes that, and a raw AIP-160 filter overrides the default. It does not mention alternatives like jules_get_session for retrieving a single session, so the guidance is scoped to filter options rather than sibling tool selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the context that 'sources' means GitHub repositories, but it does not disclose behavioral detail such as pagination behavior or the implications of openWorldHint=true (e.g., whether external repositories are included).

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 five-word sentence with zero filler and the verb front-loaded. It is efficiently structured, though the brevity leaves some information (like usage guidance) unaddressed.

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?

Adequate for a simple read-only list tool with no required params and a rich annotation set, but there are clear gaps: no indication of what the response looks like, no pagination usage hints, and no guidance distinguishing it from jules_get_source. The parenthetical defining 'sources' is the only extra contextual value.

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%, with both pageSize and pageToken already documented in the schema. The description adds no parameter-related meaning beyond what the schema provides, 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?

States a specific verb and resource ('List available sources') with a clarifying parenthetical that sources are GitHub repositories. It is clear and distinct from sibling tools like jules_list_sessions and jules_list_activities by resource type, though it doesn't explicitly name or contrast any 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?

No guidance is given on when to use this tool versus alternatives. Notably, jules_get_source exists as a sibling, but the description never explains the relationship between listing sources and fetching a single source, nor any context for when listing is appropriate.

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

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

Annotations already establish that this is a read-only, non-destructive operation. The description adds genuinely useful behavior beyond those annotations: it emits MCP progress notifications during polling and returns the final session state and outputs. No contradiction with the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler; every clause earns its place. The terminal-state polling behavior and progress-notitication detail are front-loaded ahead of the return-value note.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output scheem, it clearly states what is returned (final session state and outputs). It also specifies terminal states and the notification mechanism, giving an agent enough to know how the call behaves. The long-duration blocking aspect is conveyed by 'Polls ... until terminal state'.

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 scheem covers 100% of parameters with descriptions for session_id and poll_interval_seconds, so the description need not repeat them. The description adds no semantic detail beyond the scheem, so baseline 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 uses a specific verb ('Polls'), identifies the exact resource (a Jules session), and names the stopping condition (terminal state COMPLETED or FALED). This clearly separates it from one-shot peers like jules_get_session, and its polling-with-progress behavior sets it apart from jules_wait.

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?

Although 'Polls until it reaches terminal state' makes the use case apparent, the description does not mention alternatives such as jules_get_session or jules_wait, nor does it state when not to use this tool. The context is present but only implied, so it is not explicit enough for a 4.

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 says the tool sends a message but does not disclose whether the message is delivered immediately, whether it triggers actions, whether a response is returned, or what side effects may occur. Annotations indicate non-read-only and non-idempotent but the description adds little about actual 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 a single, front-loaded sentence with no redundant filler. It conveys the core purpose efficiently and is easy for an agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter send tool, the essential calling information is present in the schema and description. However, the lack of usage guidance and side-effect disclosure leaves moderate ambiguity for an agent trying to decide whether and how to invoke 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?

Both parameters are fully described in the input schema, so the description adds little beyond that. The phrase 'clarification or instruction' gives some context to the message parameter, but it does not explain format, length, or behavioral expectations.

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 ('send') and target ('clarification or instruction to a Jules session'), which clearly identifies the tool's purpose. It distinguishes it from query-style siblings like jules_get_session, though it overlaps slightly with jules_approve_plan since both can involve directing a 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 the tool is for clarifications or instructions, but it does not say when to prefer it over alternatives such as jules_approve_plan or jules_create_session. No exclusions or routing guidance is provided.

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

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

Annotations already cover that this is a non-read, non-destructive, idempotent operation. The description adds the behavioral detail that the session reappears in the default list, but it does not mention idempotency or any preconditions beyond being archived. This is adequate given the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence that states both the action and the effect with zero extraneous words. It is compact and immediately understandable.

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 annotations covering safety and idempotency, the description is nearly complete. It lacks explicit error or precondition details, but none are essential for the agent to invoke 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?

The schema has 100% coverage for the single parameter, and the description adds no additional meaning beyond what the schema provides. 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 ('Restore'), names the resource ('archived Jules session'), and states the observable outcome ('reappears in the default session list'). This clearly distinguishes it from siblings like jules_archive_session 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?

The description implies when to use the tool: when a session is archived and should be brought back. It does not explicitly state when not to use it, but the conditional 'archived session' and the outcome make the usage context 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?

Annotations already cover the safety profile with readOnlyHint, idempotentHint, and destrutiveHint=false. The description adds the 600-second limit and clarifies that execution is paused, but it does not describe the return behavior or whether the call blocks synchronously; with the annotations carrying safety, a mid-level score is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler: the action is front-loaded, followed by a concise usage note. Every sentence contributes, and the structure makes it easy to scan.

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 utility with strong annotations, the description is nearly complete: it gives the action, the maximum delay, and the intended use case. The only gap is the absence of return-value or completion information, and there is no output schema to cover that.

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 only parameter fully, including the maximum, so there are no hidden parameters for the description to explain. The description repeats the max limit but adds no new semantic detail beyond the schema, so the baseline for 100% schema coverage 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 action - pause execution for a duration - and includes a hard cap of 600 seconds, so an agent clearly knows what the tool does. It differentiates the tool from a generic sleep server but does not explicitly reference sibling tools by name, so it stops short of full distinction among 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?

It explicitly says to use the tool between polling calls, which is concrete when-to-use guidance. It also frames the tool as an alternative to a separate sleep MCP server, giving the agent a clear alternative and rationale.

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