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

No annotations are provided, so the description carries the burden. It discloses the precondition (requirePlanApproval=true, AWAITING_PLAN_APPROVAL) and the action of approval. However, it does not describe the post-approval effects (e.g., execution starts) or any potential errors, so it falls short of full transparency.

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 sentences that are concise and information-dense. It front-loads the action, then adds the condition, then gives a practical pointer without any fluff.

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

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

For a simple approve operation with one parameter, the description covers the action, required precondition, and a helpful handoff to view the plan. The absence of an output schema means return values are not specified, but the description gives enough to 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?

The input schema already provides a description for sessionId ('Session ID to approve plan for'), and schema coverage is 100%. The tool description adds no further parameter-level detail, 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' with a clearly defined resource 'execution plan for a Jules session' and a condition (requirePlanApproval=true). It distinguishes itself from sibling tools by indicating this is an action on a plan, not a list or session management tool.

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

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

The description explicitly states 'Only needed when session state is AWAITING_PLAN_APPROVAL,' providing a clear when-to-use condition. It also tells the user to 'View the plan first with jules_list_activities,' which offers a concrete alternative preceding the action.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the key effect (hidden from default list), clarifies that the session is not deleted, and implies reversibility by mentioning restore via unarchive. This is fully transparent for a simple archival operation.

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

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

The description is two sentences, with the primary action and key nuance ('without deleting it') front-loaded. The second sentence points to the sibling tool for restoration. Every word earns its place; no redundancy or fluff.

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

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

Given the tool's simplicity (one parameter, no output schema, no annotations), the description fully covers what an agent needs: what the tool does, the side-effect-free behavior (hide only), and how to reverse it. The sibling list supports the context, and the description aligns well with the tool's minimal scope.

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 'sessionId' described as 'Session ID to archive'. The description adds no additional parameter context, but since the schema already documents the parameter fully, a baseline of 3 is appropriate. No extra semantics are needed for a single self-explanatory 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 clearly states the action: 'Archive a Jules session to hide it from the default session list without deleting it.' The verb 'Archive' is specific, and the resource 'Jules session' is explicit. It also distinguishes from sibling tools by explicitly contrasting with deletion and naming the corresponding unarchive tool.

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

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

The description provides clear context: use this to hide a session without deleting it. It explicitly directs to 'jules_unarchive_session' as the way to restore, effectively serving as both an alternative and a when-not-to-use (if you want to fully remove, you'd use delete instead). This is excellent 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 full burden of behavioral disclosure. It adds the useful detail that each result is reported independently, but it does not explain failure handling, partial success behavior, side effects, or the mutating nature beyond 'create'.

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 core action and includes a meaningful behavioral detail ('reporting each result independently'). 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?

Despite the bulk nature, no annotations, and no output schema, the description provides very little operational context. It does not explain result shapes, partial failures, error reporting, or how to interpret the independent results, leaving the agent under-informed for a mutating bulk 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 the schema already documents the sessions parameter and its required item fields. The description adds minimal meaning beyond the schema, mainly reinforcing the multi-repository scope.

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 specifies the operation: create sessions across multiple repositories, with per-result independent reporting. It distinguishes this from the sibling jules_create_session tool by emphasizing the multi-repository bulk nature.

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 this is for bulk creation across repositories, but it never explicitly names alternatives or states when to prefer this over jules_create_session. There is no when-not-to-use guidance or mention of scheduling or other related tools.

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

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

With no annotations provided, the description carries the full burden. It states the action but does not disclose consequences such as whether future scheduled sessions are removed, whether existing sessions remain, or whether cancellation is reversible.

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 short, direct sentence with no filler. It is concise, though it sacrifices useful detail for brevity.

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, but without annotations, parameter guidance, or usage context, the description is too thin. It does not explain the effect of cancellation or how to identify the correct schedule, leaving an agent to rely on inference.

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

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

The schema has one parameter, scheduleId, with 0% description coverage. The description adds no meaning beyond the parameter name; it does not explain what the scheduleId refers to or suggest using jules_list_recurring_schedules to find it. The name is self-evident but underdocumented.

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

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

The description uses a specific verb ('Cancel') and resource ('recurring session schedule'), making the tool's function immediately clear. It also implicitly differentiates from siblings like jules_schedule_recurring_session and jules_list_recurring_schedules by focusing on cancellation.

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, how to obtain a valid scheduleId, or whether this should be used instead of deleting individual sessions. The intended workflow is not explained.

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 and discloses useful traits: 'runs in an isolated cloud VM' and 'typically completes tasks in 5-60 minutes depending on complexity'. This adds behavioral context beyond the schema. It does not explicitly state that code changes will be made, but 'coding task' implies it, and the schema covers autoApprove/autoCreatePR 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 three concise sentences, each earning its place: purpose, user action, and execution context. It is front-loaded with the main intent and contains no filler or repetition, making it easy 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?

The description covers the tool's essence and provides timing expectations, but since there is no output schema, it does not explain what the tool returns (e.g., session ID) or how to track progress. While sibling tools exist for status, the description does not mention next steps, leaving the agent to infer the post-creation 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 coverage is 100%, so baseline is 3. The description reinforces that 'prompt' should be detailed and identifies repoOwner/repoName as 'the repository to work on', but it does not add unique meaning beyond the schema. The schema already provides individual parameter descriptions, so the description adds minimal extra semantic value.

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 'Start a new asynchronous coding task with Jules' which clearly identifies the action and resource. It distinguishes this creation tool from sibling tools like jules_list_sessions, jules_get_status, and jules_delete_session by focusing on initiating a new session rather than managing existing ones.

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 context for when to use: when you need to start an asynchronous coding task, providing a detailed task description and repository. It implies the async nature and typical duration, which helps the agent decide. However, it does not explicitly mention alternatives or when not to use it, though siblings are clearly different types of operations.

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 the critical behavioral trait that deletion is permanent and cannot be undone. It could additionally mention side effects (e.g., associated data removal), but the core irreversible nature is clearly stated.

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 wasted words, and the most important information (permanent deletion) is front-loaded. The alternative is provided succinctly.

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 delete operation with one parameter and no output schema, the description is complete. It covers purpose, irreversibility, and alternative usage. The sibling context (archive/unarchive) further reinforces the distinction.

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 (sessionId) is already described as 'Session ID to delete.' The tool description adds no extra meaning beyond the schema, which is acceptable given the high coverage and simple single-parameter nature.

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

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

The description clearly states the tool's purpose: 'Permanently delete a Jules session.' It uses a specific verb ('delete') and resource ('session'), and explicitly contrasts with sibling tool jules_archive_session, making differentiation 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?

Provides explicit usage guidance: 'Use jules_archive_session instead if you may want the session back later.' This tells the agent when not to use this tool and names the alternative, making the choice unambiguous.

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; the description carries that weight and discloses progress tracking, automatic notifications, a bounded wait to prevent infinite pending, and the return bundling of final status, summary, and PR details. Lacks explicit permission or side-effect disclosure, but for this tool type the non-destructive hint is not necessary.

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 paragraph is packed with meaningful details—not a blank 'summary'; it carries exactly the substance of what is needed. No wasted words, although it is a long sentence it is acceptable given complexity.

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?

It has 9 parameters, a modest but non-trivial tool; the description covers lifecycle (creation, return, progress, output), wait limits, inputs, outputs; the output schema is absent, but the description of the returned payload (final state, summary, PR details) completes 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?

Input schema descriptions are rich: each property has an explanation, especially prompt details, defaults, max, etc. The description adds no semantics beyond the schema but the schema already provides near-total coverage of the parameters; to that score the description provides value in explaining the purpose of select 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 states a specific action ('Create a new Jules session') and resource ('wait/poll for its completion'), clearly distinguishing this from a basic creation tool by emphasizing the wait and return behavior.

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

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

Provides concrete context (polling, progress notifications, PR creation, wait limits) and describes when it should be used (for synchronous task completion), but does not explicitly name competing/alternative tools or spell out when not to use it.

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 only states the core action and does not mention error handling, permissions, return format, or what happens if the activity is not found. This minimal transparency is insufficient for a tool with no 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 exactly two sentences: one stating the purpose and one pointing to a sibling tool. It is front-loaded, direct, and contains no unnecessary words 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 by-ID fetch with two well-documented parameters, the description covers the essential operation and provides a valuable pointer to the list tool. However, since there is no output schema and no behavioral notes about errors or response format, it is not fully complete.

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

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

The input schema covers 100% of parameters with descriptions for both sessionId and activityId. The description adds no additional parameter meaning beyond the schema, 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 clearly states 'Get a single activity from a Jules session by ID,' which has a specific verb, resource, and method of retrieval. It distinguishes itself from the sibling tool jules_list_activities by specifying retrieval of a single activity by ID rather than listing 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 description includes 'Use jules_list_activities to find activity IDs,' which provides an explicit alternative for a related task. This implies the tool is for when an activity ID is already known, offering clear context on when to use this tool versus the list tool.

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. It states the return includes 'final output and results' and 'pull request details,' and implies a prerequisite that the session be completed. However, it does not disclose error behavior if used prematurely, auth requirements, or guarantee of non-mutation. 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?

The description is two sentences, front-loaded with the action, and contains no redundant or filler text. It earns its place with the specific mention of 'pull request details' and the completion prerequisite.

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 parameter and no output schema, the description adequately covers the purpose and usage condition. It could be more complete by explaining what happens if the session is not completed, but given the low complexity, it is nearly complete, earning a 4.

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 parameter 'sessionId' is already described as 'Session ID to get output for.' The description does not add additional semantic meaning beyond what the schema 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 clearly states the action ('Retrieve the final output and results'), the resource ('from a completed Jules session'), and even includes specific content ('including pull request details'). It distinguishes itself from sibling tools by specifying the post-completion context, differentiating it from get_status and 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 says 'Use after session state is COMPLETED,' providing clear timing guidance. It does not mention when not to use it or alternative tools, but the completion prerequisite is a strong usage guideline, earning 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?

No annotations are provided, so the description carries the full burden. It discloses the specific return contents ('branches and visibility') which goes beyond the schema, but it does not explicitly state that the operation is read-only or safe, nor does it mention error behavior or permissions. However, the verb 'Get' strongly implies a safe, non-mutating operation, and the added detail about return contents provides useful transparency.

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

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

The description is two sentences long, front-loaded with the main purpose, and follows with a precise pointer to the alternative sibling tool. Every sentence contributes value with no unnecessary 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 two-parameter get operation with no output schema, the description covers the key scope, return contents (branches, visibility), and the relationship to the sibling listing tool. It lacks explicit error behavior or prerequisites, but these are less critical for a straightforward read operation. The guidance is sufficient 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%, with both repoOwner and repoName fully described in the input schema. The description does not add any additional parameter-level context 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 clearly states the function: 'Get details for a single GitHub repository connected to Jules, including its branches and visibility.' This uses a specific verb and resource, and it distinguishes from the sibling tool 'jules_list_sources' by focusing on a single repository rather than all.

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 provides usage guidance with 'Use jules_list_sources to see all connected repositories,' which tells the agent when to use this tool vs an alternative. It implies that this tool is for individual repository lookup, while the sibling handles listing all connected sources.

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. It adds useful behavioral context by indicating the tool is for repeated polling and the typical duration, implying it's safe to call. However, it does not explicitly state that it is read-only, disclose error behavior, or mention any side effects or permissions needed.

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

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

The description is two sentences, front-loaded with the core purpose, and includes only essential usage guidance (polling and typical duration). 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?

Given the tool's simplicity (2 params, no output schema, no annotations), the description adequately covers purpose, usage, and typical duration. It lacks mention of return structure or error cases, but the description sets expectations for polling and completion, making it complete enough for most AI agents.

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% for both parameters (sessionId and includeActivities), so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides, except arguably the 'recent activity' phrase aligns with includeActivities, but that's redundant.

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

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

The description clearly states the tool checks 'current status and recent activity of a Jules session,' which is a specific verb and resource. It differentiates from siblings like jules_get_session_output (which presumably retrieves final output) and jules_list_activities by focusing on session status and polling, while explicitly noting the duration range.

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 explicit usage context: 'Use this to poll for progress and completion,' and provides expected time bounds ('Sessions typically take 5-60 minutes'). It does not name alternative tools or state when not to use it, but the context is clear for a polling tool.

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. It implies a read-only operation (listing) and notes ordering ('most recent first'), but does not explicitly state that it has no side effects or mention any constraints like authorization or rate limits.

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 highly concise, consisting of two sentences that pack the essential action, purpose, and behavior. It is front-loaded with the main verb and contains no redundant or extraneous information.

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

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

The description covers the essential context: what is returned (activity log), what types of activities are included, and the ordering. It does not describe the response format or error handling, but for a simple read operation this is adequate.

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 (sessionId and limit) are already described in the schema with clear meanings. The tool description adds no extra semantic detail beyond the schema, such as how limit interacts with the ordering or any additional constraints.

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

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

The description clearly states the action ('Get detailed activity log') and resource ('a Jules session'), and implies a collection via 'activity log'. It is distinguishable from the sibling 'jules_get_activity' (singular), though it doesn't explicitly say 'list'.

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

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

No guidance is provided on when to use this tool versus alternatives like 'jules_get_activity' for a specific activity or 'jules_list_sessions' for sessions. The description does not mention any selection criteria or comparison.

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 'List' implies a read-only operation and 'persistent' adds some context, but the description does not disclose output shape, whether canceled or expired schedules are included, or any pagination behavior. It does not contradict any 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 front-loaded sentence with no wasted words. 'Persistent' adds a meaningful nuance beyond the title, and the structure makes the tool's purpose immediately scannable.

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 read-only listing tool, this description is largely complete: it names the exact resource returned. There is no output schema and no mention of status filtering, but the simplicity of the operation means the missing details are minor and partly captured under usage guidelines.

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 is empty with zero properties and schema description coverage is 100%, so there are no parameters that need documentation. With zero parameters, the baseline of 4 applies and the description does not need to add parameter-level 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 states a specific action, 'List', and a specific resource, 'persistent recurring session schedules', making the purpose immediately clear. It distinguishes itself from sibling tools like jules_list_sessions, which lists sessions rather than schedules, and jules_schedule_recurring_session, which creates schedules.

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

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

The usage context is implied by the wording: use this tool to view existing recurring session schedules. However, there is no explicit guidance about when not to use it or how it compares to alternatives like jules_list_sessions or jules_cancel_recurring_schedule.

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 the read-only listing behavior and that states are included, but it does not clarify pagination behavior (e.g., 'all' may require multiple pages) or any other constraints. This is a minor transparency gap.

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

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

The description is two sentences, front-loaded with the action ('List all your Jules sessions') and includes a practical use case. Every word earns its place, with no 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?

The tool is simple, but with no output schema and no annotations, the description only partially covers return values ('current states') and does not mention pagination semantics. It is adequate for basic selection but not fully complete without additional inference.

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 covers 100% of parameters with descriptions, so the baseline is 3. The description adds no additional parameter information, meaning no extra credit for clarifying semantics 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 uses a specific verb 'List' with the resource 'Jules sessions' and adds 'with their current states', making it clear what the tool does. This distinguishes it from siblings like jules_create_session or jules_get_status, which have different purposes.

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 by stating 'Useful for finding session IDs or checking on multiple tasks', indicating when to use the tool. It does not explicitly mention alternatives or exclusions, but the use case is well implied.

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 usefully discloses that results depend on the GitHub app being installed, but it does not describe output shape, pagination behavior, or explicitly confirm read-only behavior beyond the verb 'List'.

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

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

The description is two concise sentences: the purpose is front-loaded, and the critical prerequisite is stated in the second sentence. There is no repetition of schema fields or unnecessary 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 simple list operation with two optional, well-documented parameters, the description and schema together are nearly complete. The main gap is the lack of return-format details, but that is minor for an intuitive list-repositories 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%, with clear descriptions for both filter and pageSize, so the baseline is 3. The tool description adds no parameter-specific meaning beyond what the input schema already provides.

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

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

The description states a specific verb and resource: 'List all GitHub repositories connected to Jules.' It clearly clarifies that 'sources' are GitHub repositories, distinguishing this from the sibling session, schedule, and activity 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?

The description conveys a clear prerequisite: the Jules GitHub app must be installed before repositories appear. It does not explicitly contrast this with jules_get_source or other alternatives, but the 'List all' scope and installation context give a clear sense of when to use it.

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 bears the full burden of behavioral disclosure. It discloses that pagination is handled automatically, but it does not explicitly state that the operation is read-only or describe other potential behaviors like rate limits or response characteristics. This is a moderate but not comprehensive disclosure.

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

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

The description is a single, well-structured sentence that communicates the core purpose and key behavior without any unnecessary words 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 list tool with one optional parameter and no output schema, the description defines the term 'stuck', explains the tool's scope, and mentions automatic pagination. It is mostly complete, though it could briefly mention what the response contains or compare with sibling list tools.

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

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

The only parameter (pageSize) is fully documented in the schema with a default and description. The description's mention of automatic pagination adds mild context but does not significantly enhance the parameter's 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 uses a specific verb ('List') and identifies the resource ('sessions') with a clear scope ('waiting for plan approval or user feedback'). This distinguishes it from sibling tools like jules_list_sessions and jules_wait_for_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 clearly indicates when to use the tool: to list sessions stuck in waiting states. It also notes automatic pagination. However, it does not explicitly name alternative tools or state when NOT to use it, so it stops short of a perfect score.

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 must carry the behavioral burden, and it only discloses durability ('persistent') and recurrence ('cron'). It does not state whether a session runs immediately upon scheduling, whether duplicate schedules are allowed or overwritten, what the default autoApprove/autoCreatePR behavior implies for future autonomous runs, or what the response contains.

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 10-word sentence with zero filler; 'persistent' and 'cron' earn their place by conveying durability and recurrence. It is efficiently front-loaded, though given the 8-parameter complexity and 19 siblings, the brevity veers toward under-specification rather than ideal conciseness.

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 8 parameters, no annotations, no output schema, and 13% schema coverage, one sentence is far from complete. Missing context includes the return format (does it return a schedule ID?), the relationship to jules_cancel_recurring_schedule/jules_list_recurring_schedules, and the operational consequence that scheduled sessions will run autonomously on a recurring basis.

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

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

Schema description coverage is only 13% (only 'cron' has a terse description), so the description must compensate, but it mentions no parameters at all. While repoOwner/repoName/prompt are self-evident by name, autoApprove and autoCreatePR carry behavioral meaning (autonomous approval, PR creation on each run) that neither the schema nor the description clarifies.

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 ('Create'), a specific resource ('persistent cron schedule for recurring Jules sessions'), and the scope (recurring vs one-off). This clearly separates it from one-off session tools like jules_create_session and jules_bulk_create_sessions, though it does not explicitly name a sibling as the gold-standard examples do.

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 choose this tool over alternatives. With 19 siblings including jules_create_session, jules_bulk_create_sessions, jules_list_recurring_schedules, and jules_cancel_recurring_schedule, the absence of any routing cue ('use X for one-off sessions') leaves the agent to infer the decision 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?

No annotations are provided, so the description carries the full burden. It adds a key behavioral trait: Jules will respond in the next activity, indicating asynchronous behavior. However, it doesn't disclose error conditions, side effects, or authentication requirements, leaving some ambiguity.

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 concise sentences, front-loaded with the core purpose and immediately useful next steps. 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 message-sending tool with two parameters and no output schema, the description covers the purpose, the session context, and where to see the response. It doesn't elaborate on failure modes, but that's acceptable given the tool's simplicity.

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 has 100% coverage for both parameters (sessionId and message), so the description doesn't add significant semantic value. It reinforces that the message is a follow-up and requires a sessionId, but provides no extra format or constraint details beyond the schema.

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

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

The description clearly states the tool sends a follow-up message or instruction to a running Jules session, using a specific verb and resource. It distinguishes itself from sibling tools like jules_list_activities or jules_get_status by focusing on the act of sending a message to an existing 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 context that it's for running sessions and directs the user to check the response via jules_list_activities or jules_get_status. It implies the use case of sending follow-up messages but doesn't explicitly contrast with alternatives like jules_approve_plan or state prerequisites beyond 'running'.

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 states the action and result but does not disclose side effects, reversibility, error behavior (e.g., if the session is not archived), or any permissions/security implications.

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, focused sentence that front-loads the action and outcome. Every word earns its place, with 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?

The tool is simple (one parameter, no output schema, no annotations), and the description clarifies the primary purpose and result. However, it omits edge-case behavior and fails to provide any safety or side-effect context, which is a gap given the total lack of annotations.

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 single parameter sessionId is fully described in the schema ('Session ID to unarchive'), and the description adds no additional meaning beyond the schema. Since schema coverage is 100%, 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 'Restore' and clearly identifies the resource ('previously archived Jules session') and the outcome ('appears in the default session list again'). This distinguishes it from sibling tools like jules_archive_session and jules_delete_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 reversing an archive operation, but it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites. The context is clear but not comparative.

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 must carry the full burden of behavioral disclosure. It explains that the tool polls, tracks progress, emits progress notifications, returns a unified payload with final state/details, and is bounded by a wait limit to prevent timeouts. This gives the agent a clear picture of what happens without repeating annotation 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 extremely concise at two sentences, opens with the core purpose, and every clause adds value (tracks progress, emits notifications, returns payload, bounded wait). There is zero redundancy or filler, 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?

Given the lack of an output schema, the description adequately explains the return payload (unified payload with final state, summary, and PR details) and mentions timeout prevention. It doesn't cover error handling or specific edge cases, but for a wait/poll tool this is sufficient. The presence of siblings like jules_get_status might imply more granular reads, but the description is complete enough for successful 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 coverage is 100% for the three parameters (sessionId, maxWaitSeconds, includeActivities). The description adds minimal parameter-specific meaning—it only hints at the wait limit ('bounded by a wait limit') and the unified payload, but doesn't elaborate on how includeActivities affects output. With high schema coverage, baseline is 3, and the description doesn't exceed that.

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

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

The description clearly states the tool's purpose: to wait/poll for a Jules session to complete. It uses a specific verb ('wait/poll') and resource ('Jules session'), and distinguishes itself from siblings like jules_execute_and_wait by focusing solely on waiting for an existing session rather than executing a new one.

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 you have a session ID and need to wait for its completion. It mentions it automatically tracks progress and emits notifications, suggesting it's more comprehensive than simple polling. However, it doesn't explicitly state when NOT to use it or compare it to alternatives like jules_get_status, though the context of 'wait/poll' provides clear usage context.

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