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 explains the core behavior (creating sessions for code tasks) and the repoless session option, but doesn't disclose important behavioral traits like authentication requirements, rate limits, whether sessions are persistent, what happens on failure, or expected response format. The description adds basic context but leaves significant gaps.

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

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

The description is perfectly concise with just two sentences that each earn their place. The first sentence states the core purpose, and the second explains the important 'repoless session' nuance. No wasted words, and the most critical information is front-loaded.

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

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

For a 5-parameter creation tool with no annotations and no output schema, the description provides adequate but incomplete context. It explains the tool's purpose and the repoless session concept well, but doesn't address what the tool returns, error conditions, or important behavioral constraints. Given the complexity of session creation and the lack of structured metadata, more completeness would be beneficial.

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

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

With 100% schema description coverage, the input schema already documents all 5 parameters thoroughly. The description adds some semantic context by explaining the relationship between repo/branch parameters and the 'repoless session' concept, but doesn't provide additional meaning beyond what's already in the schema descriptions. This meets the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose with a specific verb ('creates') and resource ('new Jules session or automated run'), and distinguishes it from siblings by explaining the unique 'repoless session' capability. It explicitly differentiates this creation tool from session query/management tools like 'get_session_state' or '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 provides clear context about when to use this tool (to create sessions for code tasks) and explains the alternative 'repoless session' approach when repo/branch are omitted. However, it doesn't explicitly state when NOT to use this tool versus alternatives like 'jules_quick_task' or 'jules_create_and_wait' among the siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the return content (commands, stdout/stderr, exit codes) and implies a read-only operation, but lacks details on permissions, rate limits, error handling, or pagination for potentially large outputs.

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 appropriately sized with two sentences that are front-loaded and efficient. The first sentence states the purpose and return values, while the second provides usage context, with no wasted words 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 no annotations and no output schema, the description adequately covers the tool's purpose and basic usage, but lacks completeness for a tool with 2 parameters and potentially complex return data. It does not address behavioral aspects like error cases or output structure details.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description does not add any additional meaning or context beyond what the schema provides, such as explaining how 'activityIds' might filter results or the format of 'sessionId'.

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 with a specific verb ('Get') and resource ('bash command outputs from a Jules session'), and distinguishes it from siblings by focusing on shell command execution data rather than session management, code review, or planning functions.

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

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

The description provides clear context for when to use this tool ('to understand what shell commands were run'), but does not explicitly state when not to use it or name specific alternatives among the sibling tools, such as 'jules_list_activities' or 'get_session_state'.

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 and does well by disclosing key behaviors: it explains how it handles busy vs. stable sessions, returns structured summaries organized by file, and includes change types and line counts. However, it doesn't mention potential limitations like rate limits or authentication needs.

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 front-loaded with the core purpose, followed by key features and a clear alternative. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.

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 5 parameters, 100% schema coverage, and no output schema, the description is mostly complete. It explains the tool's behavior and usage context well, but could benefit from more detail on output structure or error handling to fully compensate for the lack of annotations and output schema.

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% description coverage, so the baseline is 3. The description adds some context by mentioning 'automatically detects if session is busy or stable' and 'optionally scope to a single activity', which loosely relates to parameters but doesn't provide additional syntax or format 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's purpose with specific verbs ('Review code changes', 'Returns a structured summary') and resources ('Jules session'). It distinguishes from sibling tools by mentioning 'show_code_diff' for detailed diffs, making its scope explicit.

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 explicit guidance on when to use this tool vs. alternatives: it states 'For detailed diffs, use show_code_diff' and explains when to scope to a single activity vs. the whole session. This gives clear context for selection among siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure and excels. It details return values (e.g., 'RETURNS: id, status, url...'), explains status meanings ('busy', 'stable', 'failed'), describes data structures ('LAST ACTIVITY', 'LAST AGENT MESSAGE', 'PENDING PLAN'), and outlines actionable insights ('NEXT ACTIONS'). It also clarifies operational constraints like 'A session is never truly "done" unless it's failed.'

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 well-structured with clear sections (e.g., RETURNS, STATUS, NEXT ACTIONS) and front-loaded key information. However, it is lengthy due to comprehensive behavioral details, which are justified given the lack of annotations and output schema. Some redundancy exists (e.g., repeating tool names in examples), but overall, each sentence adds value for agent decision-making.

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 complexity of session management, no annotations, and no output schema, the description is highly complete. It thoroughly explains return values, status interpretations, behavioral implications, and next-step recommendations. It compensates for missing structured data by providing all necessary context for an agent to correctly invoke the tool and act on its results, referencing sibling tools where appropriate.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds value by implicitly contextualizing the 'sessionId' parameter through examples of returned data (e.g., 'id', 'url') and usage scenarios, though it doesn't explicitly explain the parameter beyond what the schema states. This elevates the score above baseline but not to a 5, as no new parameter-specific details are introduced.

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 explicitly states the tool's purpose: 'Get the current status of a Jules session. Acts as a dashboard to determine if Jules is busy, waiting, or failed.' It uses specific verbs ('Get', 'determine'), identifies the resource ('Jules session'), and distinguishes from siblings by focusing on status retrieval rather than creation, listing, or messaging.

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 explicit guidance on when to use this tool and alternatives. The 'NEXT ACTIONS' section details specific scenarios (e.g., 'busy → Wait for completion, or peek with get_code_review_context'), and it references sibling tools like 'get_code_review_context' and 'send_reply_to_session' for follow-up actions. It also clarifies that 'You can send messages to ANY session regardless of status,' preventing misuse.

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

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

With no annotations, the description carries full burden but lacks behavioral details. 'Approves' implies a mutation, but it doesn't disclose permissions needed, side effects (e.g., plan execution), reversibility, or response format. This is inadequate for a mutation tool without annotation support.

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

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

The description is a single, efficient sentence that states the core action without fluff. However, it's slightly under-specified for a mutation tool, as it could benefit from one more clarifying detail without losing 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?

Given complexity (mutation tool), no annotations, and no output schema, the description is incomplete. It doesn't explain what 'approves' does operationally, what happens after approval, or any behavioral traits, leaving significant gaps for agent understanding.

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 the single parameter 'sessionId', so the schema fully documents it. The description adds no parameter details beyond implying it's for a session, but with 0 parameters needing extra semantics, a baseline of 4 is appropriate as no compensation is required.

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

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

The description states the action ('Approves') and target ('the current plan for a session'), which is clear but vague. It doesn't specify what 'approves' entails operationally or distinguish it from sibling tools like 'jules_reject_plan' beyond the opposite action, missing specifics like workflow implications or resource effects.

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. It doesn't mention prerequisites (e.g., needing a pending plan), exclusions, or comparisons to siblings like 'jules_reject_plan' or 'jules_wait_for_plan', leaving usage context implied but unspecified.

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 full burden for behavioral disclosure. 'Cancels' implies a destructive mutation, but it doesn't specify whether this requires special permissions, if the action is reversible, what happens to associated resources, or what the response looks like. The description is minimal and lacks important operational context.

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

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

The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple operation with one parameter and no complex behavioral nuances to explain.

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 destructive operation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'cancels' means operationally, what happens after cancellation, error conditions, or return values. Given the complexity of session management and multiple sibling tools, more context is needed for effective 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 description coverage is 100% with the single parameter 'sessionId' documented as 'Session ID'. The description doesn't add any additional semantic context about the parameter beyond what the schema provides, such as format examples or where to obtain session IDs. With complete schema coverage, the baseline score 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 ('Cancels') and target resource ('an active Jules session'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'jules_get_session' or 'list_sessions', but the verb 'Cancels' strongly implies a destructive operation versus read-only alternatives.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'jules_get_session' for checking status or 'list_sessions' for discovery. It mentions 'active' session but doesn't clarify prerequisites, error conditions, or what happens to inactive sessions.

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

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

With no annotations provided, the description carries full burden but only states the combined action without behavioral details. It doesn't mention what 'completion' means (e.g., success/failure states), whether this is a blocking/long-running operation, potential timeouts beyond the parameter, error handling, or authentication needs. For a tool with significant behavioral implications, this is inadequate.

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

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

The description is a single, efficient sentence that front-loads the core functionality with zero wasted words. Every part of the sentence earns its place by clearly stating the tool's purpose and key behavioral aspect (waiting).

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 complexity (8 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain what a 'Jules session' is, what 'completion' entails, what the tool returns, or error scenarios. For a tool that combines creation and waiting—likely involving significant backend processing—this leaves too many contextual gaps.

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

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

Schema description coverage is 75% (6 of 8 parameters have descriptions), so the baseline is 3. The description doesn't add any parameter-specific semantics beyond what the schema provides (e.g., it doesn't explain relationships between parameters like 'waitForCompletion' and 'timeoutMs'). It only implies the tool uses these parameters for the create-and-wait operation.

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 specific action: 'Creates a Jules session AND waits for it to complete in a single operation.' It explicitly distinguishes this from sibling tools like 'jules_create_session' (which only creates) and 'jules_wait_for_completion' (which only waits), making the combined functionality unambiguous.

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

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

The description implies when to use this tool: when you need both creation and waiting in one step. However, it doesn't explicitly state when NOT to use it (e.g., if you want to create without waiting) or name specific alternatives like 'jules_create_session' followed by 'jules_wait_for_completion', leaving some guidance implicit rather than explicit.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'asynchronous coding task', hinting at non-blocking behavior, but lacks critical details like authentication needs, rate limits, what 'session' entails (e.g., duration, resource usage), or error handling. This is inadequate for a tool that likely involves complex operations.

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

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

The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by stating the action and goal clearly, 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?

Given the complexity implied by 'asynchronous coding task' and 6 parameters, with no annotations or output schema, the description is incomplete. It fails to explain what a 'session' is, how results are accessed, or behavioral traits like side effects, leaving significant gaps for the agent to operate effectively.

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 high (83%), with clear descriptions for most parameters like 'prompt' and 'repo'. The description adds no additional parameter semantics beyond the schema, but the schema itself is well-documented, so a baseline score of 3 is appropriate as it doesn't compensate for the minor coverage gap but doesn't degrade the existing clarity.

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 ('Creates a new Jules session') and the purpose ('to perform an asynchronous coding task'), which is specific and distinguishes it from non-Jules session tools. However, it doesn't explicitly differentiate from sibling tools like 'create_session' or 'jules_create_and_wait', which could cause confusion about when to use this specific 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 no guidance on when to use this tool versus alternatives. With sibling tools like 'create_session', 'jules_create_and_wait', and 'jules_quick_task' available, there's no indication of context, prerequisites, or comparative use cases, leaving the agent to guess based on tool names alone.

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 states the tool retrieves data ('Gets'), implying a read-only operation, but does not specify if it requires authentication, has rate limits, returns structured data, or handles errors. This leaves significant gaps in understanding the tool's 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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy for an AI 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 annotations and output schema, the description is incomplete. It does not explain what 'most recent activity' entails (e.g., type of data, format) or how the tool behaves in edge cases, which is insufficient for a tool that retrieves session-specific data without structured output documentation.

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

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

The input schema has 100% description coverage, with 'sessionId' clearly documented as 'Session ID'. The description does not add any additional meaning beyond this, such as format examples or constraints, so it meets the baseline for adequate but not enhanced parameter semantics.

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 with a specific verb ('Gets') and resource ('most recent activity from a Jules session'), making it understandable. However, it does not explicitly distinguish this tool from its sibling 'jules_list_activities', which might also retrieve activities, leaving some ambiguity about when to use one over the other.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'jules_list_activities' or 'get_session_state'. It lacks context about prerequisites, such as needing an active session, or exclusions, which could lead to misuse by an AI agent.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Gets' information, implying a read-only operation, but doesn't cover aspects like authentication needs, rate limits, error handling, or what 'status and details' specifically entail. This leaves significant gaps for a tool with no structured safety 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the 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?

Given the lack of annotations and output schema, the description is incomplete for a tool that retrieves session details. It doesn't explain what 'status and details' includes, potential return formats, or error conditions. For a read operation with no structured output, more context is needed to guide effective use.

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

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

The input schema has 100% description coverage, with the single parameter 'sessionId' documented as 'Session ID'. The description doesn't add any meaning beyond this, such as format examples or context about session IDs. Since the schema does the heavy lifting, the baseline score 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 tool's purpose with a specific verb ('Gets') and resource ('current status and details of a Jules session'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'get_session_state' or 'jules_get_session_summary', which appear to serve similar purposes, preventing a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like 'get_session_state' and 'jules_get_session_summary' that likely retrieve session-related information, there's no indication of specific contexts, prerequisites, or exclusions for this 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 provided, the description carries the full burden of behavioral disclosure. While 'Gets' implies a read operation, the description doesn't address important behavioral aspects like whether this requires authentication, rate limits, what happens with invalid session IDs, or the format/structure of the returned execution plan. This leaves significant gaps for a tool with no annotation coverage.

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

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

The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded, making it immediately clear what the tool does without unnecessary elaboration.

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 annotations, no output schema, and multiple sibling tools that might overlap in functionality, the description is insufficiently complete. It doesn't explain what an 'execution plan' contains, how it differs from other session information retrievable via sibling tools, or what the return format looks like. For a tool in this context, more contextual information is needed.

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% description coverage, with the single parameter 'sessionId' clearly documented in the schema. The description doesn't add any meaningful parameter information beyond what's already in the schema, so it meets the baseline of 3 for high schema coverage without adding 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 clearly states the action ('Gets') and target resource ('execution plan from a Jules session'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'get_session_state' or 'jules_get_session_summary' that might retrieve related session information, so it doesn't achieve full sibling differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like 'get_session_state', 'jules_get_session_summary', and 'jules_get_session' that might retrieve overlapping session information, there's no indication of what distinguishes this tool or when it's the appropriate choice.

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 states it 'Gets' information, implying a read-only operation, but doesn't disclose behavioral traits such as permissions needed, rate limits, error handling, or what 'comprehensive' entails in terms of data format or size. This is inadequate for a tool with no annotation coverage.

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

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

The description is a single, efficient sentence that front-loads the purpose and details without waste. Every word contributes to understanding the tool's function, making it appropriately sized and well-structured.

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

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

Given no annotations and no output schema, the description is incomplete. It doesn't explain what the summary output looks like, how it's structured, or any behavioral context like error cases. For a tool that retrieves complex session data, this leaves significant gaps for an AI agent to operate effectively.

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 the single parameter 'sessionId' documented in the schema. The description adds no additional meaning beyond implying the parameter is used to retrieve session data, so it meets the baseline of 3 where the schema handles parameter documentation effectively.

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 verb 'Gets' and the resource 'comprehensive summary of a Jules session', specifying what information is included (status, plan, activities, outputs). It distinguishes from siblings like 'get_session_state' or 'jules_get_session' by emphasizing comprehensiveness, though not explicitly naming alternatives.

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 on when to use this tool versus alternatives is provided. The description implies usage for session summaries, but it doesn't specify prerequisites, exclusions, or compare with similar tools like 'jules_get_session' or 'get_session_state', leaving the agent to infer 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'Gets details,' implying a read-only operation, but doesn't disclose any behavioral traits such as error handling, authentication needs, rate limits, or what specific details are returned. This leaves significant gaps for an agent to understand how to use it effectively.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.

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 annotations and output schema, the description is incomplete. It doesn't explain what details are returned, how errors are handled, or any behavioral context needed for a read operation. For a tool with no structured support, this minimal description leaves too many gaps for effective use.

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

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

The input schema has 100% description coverage, with the parameter 'source' clearly documented as 'Source name (e.g., "sources/github/owner/repo")'. The description adds no additional meaning beyond this, such as format constraints or examples, so it meets the baseline of 3 where the schema does the heavy lifting.

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

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

The description clearly states the action ('Gets details') and resource ('specific GitHub repository connected to Jules'), which is a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'jules_list_sources' or 'jules_get_session', which might also retrieve information about sources or sessions in different ways.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'jules_list_sources' for listing all sources or other sibling tools that might retrieve related information, nor does it specify any prerequisites or exclusions for usage.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions listing 'all activities' but doesn't describe pagination behavior (implied by parameters), rate limits, authentication needs, or what constitutes an 'activity' (e.g., events, messages). This leaves gaps for an agent to understand operational constraints.

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

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

The description is a single, efficient sentence that front-loads the core purpose ('Lists all activities'). There is no wasted verbiage or redundant information, 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?

Given the tool's moderate complexity (list operation with pagination), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, output format, and usage context, which could hinder an agent's ability to use it effectively without trial and error.

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 parameters are fully documented in the schema. The description adds no additional meaning beyond implying a session context for 'activities'. It doesn't explain parameter interactions (e.g., pagination with pageSize/pageToken) or default behaviors, relying entirely on 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 verb ('Lists') and resource ('all activities (events) in a Jules session'), making the purpose immediately understandable. It distinguishes from siblings like 'jules_get_latest_activity' (single activity) and 'jules_list_sessions' (different resource), though it doesn't explicitly mention these distinctions in the text.

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. For example, it doesn't mention when to choose this over 'jules_get_latest_activity' for a single activity or 'jules_get_session_summary' for aggregated data. The description only states what it does, not when it's 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?

No annotations are provided, so the description carries the full burden. It mentions pagination but doesn't disclose other behavioral traits like whether this is a read-only operation, what permissions are needed, rate limits, or what the output format looks like. For a list tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.

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

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

The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the core functionality without unnecessary elaboration.

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 annotations and output schema, the description is incomplete. It doesn't explain what a 'Jules session' is, what data is returned, or how to interpret results. For a tool with multiple similar siblings and no structured behavioral hints, more context is needed to ensure proper use.

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 fully documents both parameters (pageSize and pageToken). The description adds no additional meaning beyond mentioning 'optional pagination', which is already implied by the parameters. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the verb ('Lists') and resource ('your Jules sessions'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'list_sessions' or 'jules_get_session', which could cause confusion about when to use this specific tool versus alternatives.

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 mentions 'optional pagination' but provides no guidance on when to use this tool versus similar siblings (e.g., 'list_sessions' or 'jules_get_session'). There are no explicit when/when-not instructions or alternatives named, leaving usage context unclear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool lists repositories but fails to describe key behaviors: it doesn't indicate this is a read-only operation (implied but not stated), explain pagination handling (despite parameters for it), detail authentication requirements, or specify output format. This leaves significant gaps for an agent to understand how to interact with the tool effectively.

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

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

The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly communicates the tool's function, making it easy to parse and understand quickly, with no wasted 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?

Given the complexity of a listing tool with pagination parameters and no output schema or annotations, the description is insufficient. It doesn't explain the return values (e.g., structure of repository data), pagination behavior, or error conditions, leaving the agent with incomplete context for proper usage despite the clear purpose.

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

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

The input schema has 100% description coverage, clearly documenting both parameters ('pageSize' and 'pageToken') with their types and purposes. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage without compensating 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 clearly states the action ('Lists') and resource ('all GitHub repositories connected to your Jules account'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential sibling tools like 'jules_get_source' or 'jules_list_sessions', which might also involve GitHub repositories or listing operations.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active Jules account), compare it to siblings like 'jules_get_source' for single repositories, or specify scenarios where listing all repositories is appropriate over other listing tools.

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

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

No annotations are provided, so the description carries the full burden. It mentions 'assign a task' and 'sensible defaults', but fails to disclose critical behavioral traits such as what 'assign' entails (e.g., does it trigger immediate execution, require approval, or have side effects?), authentication needs, rate limits, or error handling. This leaves significant gaps for an agent to understand the tool's 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, efficient sentence that front-loads key information ('Simplest way to assign a task') and avoids unnecessary details. Every word contributes to conveying the tool's essence without waste, making it highly concise and well-structured.

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

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

Given the complexity of task assignment (likely involving mutations and workflows), no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, return values, or error conditions, leaving the agent with insufficient context to use the tool effectively beyond basic parameter input.

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 fully documents all parameters. The description adds no additional meaning beyond implying 'sensible defaults' for parameters like 'branch' and 'createPr', but doesn't elaborate on their semantics or usage. This meets the baseline of 3 when schema coverage is high.

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 ('assign a task to Jules') and the resource ('task'), making the purpose understandable. It distinguishes itself from siblings like 'jules_create_session' by emphasizing 'simplest way' and 'sensible defaults', but doesn't explicitly contrast functionality with all similar tools (e.g., 'jules_create_and_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?

The description implies usage through 'simplest way' and 'sensible defaults', suggesting it's for quick, default-driven task assignments. However, it lacks explicit guidance on when to use this versus alternatives like 'jules_create_session' or 'jules_create_and_wait', leaving the context somewhat implied rather than clearly defined.

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

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

With no annotations, the description carries full burden but lacks critical behavioral details. It states the action is a rejection but doesn't disclose whether this is destructive (e.g., irreversible), requires specific permissions, affects session state, or has side effects like notifications. The optional feedback is mentioned but not explained in terms of impact.

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

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

The description is a single, efficient sentence with zero wasted words. It front-loads the core action ('rejects the current plan') and adds optional functionality concisely. Every element 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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after rejection (e.g., session state changes, return values, error conditions), nor does it address complexity like interactions with other session tools. Given the lack of structured data, more behavioral context is needed.

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%, providing basic parameter documentation. The description adds minimal value by implying 'sessionId' identifies the target session and 'feedback' is optional input for the rejection, but doesn't elaborate on format, constraints, or how feedback is used beyond what the schema already states.

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

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

The description clearly states the action ('rejects') and target ('current plan for a session'), with optional feedback. It distinguishes from siblings like 'jules_approve_plan' by specifying rejection, but doesn't fully differentiate from other session-modifying tools like 'jules_cancel_session' or 'send_reply_to_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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing plan), exclusions, or compare with siblings like 'jules_cancel_session' or 'send_reply_to_session' for session management.

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 but doesn't describe what happens after sending (e.g., whether it waits for a response, returns confirmation, or triggers async processing), nor does it mention any constraints like rate limits, authentication needs, or session state requirements.

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

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

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, 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 complexity of a messaging tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., success confirmation, error details, or response content), behavioral traits, or how it integrates with sibling tools, leaving significant gaps for agent understanding.

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

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

Schema description coverage is 100%, so the schema already documents both parameters ('sessionId' and 'message') adequately. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, but doesn't need to compensate for gaps, resulting in a baseline score.

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 ('sends a message') and target ('to an active Jules session'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from potential alternatives like 'send_reply_to_session' among the sibling tools, which appears to serve a similar function.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions 'active Jules session' but doesn't clarify prerequisites, exclusions, or how it differs from sibling tools like 'send_reply_to_session', leaving the agent with no usage context.

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

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

With no annotations, the description carries full burden but provides minimal behavioral insight. It mentions applying a diff, implying a write/mutation operation, but doesn't disclose critical traits like whether it modifies files permanently, requires git setup, handles conflicts, or has side effects (e.g., committing changes). The lack of output schema further limits transparency on what the tool returns.

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

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

The description is a single, efficient sentence that front-loads the core action ('Applies the latest Jules diff') and target ('to a local git working tree'), with a clarifying parenthetical. Every word contributes to understanding the tool's purpose without 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 complexity (applying diffs to a git repository with 7 parameters), no annotations, and no output schema, the description is insufficient. It lacks details on behavioral outcomes (e.g., success/failure states, error handling), integration with sibling tools (e.g., following 'jules_approve_plan'), or operational constraints, leaving significant gaps for an AI agent to use it correctly.

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

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

Schema description coverage is 100%, so the schema fully documents all 7 parameters. The description adds no parameter-specific semantics beyond implying 'syncs the codebase' relates to parameters like 'repoPath' or 'file'. It doesn't explain interactions between parameters (e.g., 'dryRun' with 'allowDirty') or provide usage examples, meeting the baseline for high schema coverage.

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

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

The description clearly states the action ('applies the latest Jules diff') and target ('to a local git working tree'), with the parenthetical 'syncs the codebase' reinforcing the purpose. It distinguishes from siblings like 'show_code_diff' (which displays differences) or 'jules_get_latest_activity' (which retrieves information), though it doesn't explicitly name alternatives.

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

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

No guidance is provided on when to use this tool versus alternatives. The description implies it's for applying diffs, but it doesn't specify prerequisites (e.g., after a plan is approved), exclusions (e.g., not for viewing diffs), or direct comparisons to siblings like 'jules_approve_plan' or 'jules_reject_plan' in a 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?

With no annotations, the description carries full burden but lacks behavioral details. It mentions waiting for completion but doesn't disclose how it waits (e.g., polling behavior implied by parameters), error handling, timeout effects, or what happens on completion. This is inadequate for a tool with potential side effects like blocking.

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

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

The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without redundancy. It's front-loaded and appropriately sized for its simple function.

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

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

Given no annotations and no output schema, the description is incomplete. It doesn't explain return values (e.g., what data is provided on completion), error conditions, or behavioral nuances like blocking vs. non-blocking. For a wait tool with 3 parameters, this leaves significant gaps for agent understanding.

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 fully documents parameters. The description adds no meaning beyond the schema—it doesn't explain parameter interactions (e.g., how timeoutMs and pollIntervalMs affect waiting) or provide usage examples. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the action ('waits for') and resource ('Jules session'), specifying the completion states (success, failure, or cancellation). It distinguishes from siblings like 'jules_get_session_state' by focusing on waiting rather than checking state, but doesn't explicitly contrast with 'jules_create_and_wait' which may combine creation and waiting.

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. It doesn't mention prerequisites (e.g., needing an active session), exclusions, or comparisons to siblings like 'jules_create_and_wait' or 'get_session_state', leaving the agent to infer usage context.

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

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

With no annotations provided, the description carries full burden but offers minimal behavioral details. It mentions waiting behavior but doesn't specify what happens during the wait (e.g., polling, blocking), error conditions (e.g., timeout handling), or side effects. This is inadequate for a tool that likely involves asynchronous operations and timeouts.

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, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. This is an example of efficient communication that 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?

Given the complexity of waiting for an asynchronous plan generation with timeout handling, no annotations, and no output schema, the description is incomplete. It lacks details on behavior, error handling, return values, and how it fits with sibling tools, leaving significant gaps for the agent to operate effectively.

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%, providing basic parameter documentation. The description adds no additional meaning beyond the schema—it doesn't explain how 'sessionId' relates to Jules sessions or what typical 'timeoutMs' values might be. Baseline 3 is appropriate since the schema does the heavy lifting, but no extra context is given.

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 ('waits for') and resource ('Jules to generate a plan for a session'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'jules_get_session_plan' or 'jules_wait_for_completion', which could cause confusion about when to use this specific waiting tool versus others.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether a session must be in a specific state), exclusions, or comparisons to siblings like 'jules_wait_for_completion' or 'jules_get_session_plan', leaving the agent to infer usage context from the name alone.

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 mentions 'pagination support', which is useful context, but fails to describe other key behaviors such as what 'recent' means (e.g., time frame), whether the list is ordered, what permissions are required, or what the output format looks like. This leaves significant gaps 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 a single, efficient sentence that front-loads the core purpose ('List recent Jules sessions') and adds a key behavioral trait ('with pagination support'). There is no wasted language, making it appropriately sized and well-structured.

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

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

Given the complexity of a list operation with pagination, no annotations, and no output schema, the description is incomplete. It lacks details on output format, error handling, authentication needs, or how 'recent' is defined. While concise, it doesn't provide enough context for an agent to use the tool effectively without additional assumptions.

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

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

The input schema has 100% description coverage, providing clear documentation for both parameters ('pageSize' and 'pageToken'). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.

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

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

The description clearly states the verb ('List') and resource ('recent Jules sessions'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'jules_list_sessions', which appears to be a very similar tool, leaving some ambiguity about when to use one versus the other.

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

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

The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools that might overlap (e.g., 'jules_list_sessions'), there's no indication of context, prerequisites, or exclusions. The mention of 'pagination support' hints at usage for large datasets but doesn't clarify 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the tool queries local cache (implying read-only, non-destructive), returns potentially stale data, is fast, and has a specific use case for searching/filtering. It doesn't mention error handling, rate limits, or authentication needs, but covers the core operational behavior well.

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 efficiently structured in three sentences: first states the purpose and key limitation, second provides alternative for fresh data, third gives usage guidance. Every sentence adds value with zero wasted words, and it's front-loaded with the most critical information (cached data, staleness).

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 complexity (single but nested parameter, no output schema, no annotations), the description does an excellent job of providing context. It explains the data source (local cache), performance characteristics (fast but stale), when to use it, and alternatives. The main gap is lack of output format details, but for a query tool with good parameter documentation, this is acceptable.

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 single 'query' parameter and its nested properties thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, but it does provide context about what the query operates on (local cache vs. fresh data), which is useful. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'Query the LOCAL CACHE of sessions and activities.' It specifies the verb ('query'), resource ('local cache of sessions and activities'), and distinguishes it from sibling tools by emphasizing it's for cached data only, not fresh data.

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

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

The description provides explicit guidance on when to use this tool ('Best for searching across multiple sessions or filtering by type/state') and when not to use it ('Returns only previously synced data (fast, but may be stale)'). It also names alternatives ('To ensure fresh data: call jules_sync first, then jules_select'), making it clear how this tool fits into the workflow.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'interacts' and actions like 'approving plans or sending messages', but fails to detail critical behaviors such as required permissions, whether actions are reversible, response formats, or error handling, which are essential for a tool with mutation capabilities.

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

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

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded and appropriately sized, 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?

Given the tool's complexity (involving session interactions with multiple actions), lack of annotations, and no output schema, the description is insufficient. It omits details on behavioral traits, usage contexts, and return values, leaving significant gaps for effective tool invocation.

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

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

The description does not explicitly discuss parameters, but the input schema has 67% coverage, documenting 'action' and 'message' well. With 3 parameters and no parameter info in the description, the baseline is 4, as the schema adequately covers semantics for most parameters, though 'sessionId' lacks description.

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 the tool 'interacts with an active Jules session' and lists possible actions ('approving plans or sending messages'), which provides a general purpose. However, it lacks specificity about what 'interacts' entails and does not clearly differentiate from sibling tools like 'jules_approve_plan' or 'jules_send_message', making it vague in comparison.

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 offers no guidance on when to use this tool versus alternatives, such as the sibling tools 'jules_approve_plan' or 'jules_send_message'. It mentions actions but does not specify contexts, prerequisites, or exclusions, leaving usage unclear.

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 output format ('unified diff format that can be displayed to users') and a performance consideration ('Omit to get all diffs (may be large)'), which adds useful context. However, it doesn't mention error conditions, rate limits, or authentication needs, leaving some behavioral aspects unclear for a tool with no annotation coverage.

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

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

The description is efficiently structured in three sentences: first states purpose and output, second provides usage guidelines, third explains optional parameter usage. Every sentence adds value without repetition, and it's front-loaded with the core functionality.

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

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

Given no annotations and no output schema, the description does well by explaining the output format and usage workflow. It covers the main use case and optional parameters adequately. However, for a tool with 3 parameters and no structured safety or output info, it could benefit from more detail on error handling or response structure to be fully complete.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema: it mentions the optional activityId parameter and references get_work_in_progress output for its IDs, but this is redundant with the schema's description. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the specific action ('show the actual code diff'), resource ('files from a Jules session'), and output format ('unified diff format'). It distinguishes from siblings by referencing get_code_review_context for context and specifying this tool is for drilling into file changes, unlike broader session management tools like get_session_state or 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?

Explicit guidance is provided: 'Use after get_code_review_context to drill into specific file changes.' It also specifies when to use the optional activityId parameter ('Can optionally show diff from a specific activity') and references where to get that ID ('use activity IDs from get_code_review_context output'). This clearly defines the workflow context and alternatives.

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