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 action (approve) but does not disclose any side effects, whether the operation is reversible, if it requires specific permissions, or what happens after approval. For a mutation tool, this is a significant 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 a single sentence with no extraneous words. It front-loads the action and condition, 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 tool is simple, and an output schema exists, so return values are defined elsewhere. However, the description lacks essential context: when to use it (beyond the condition), any prerequisites or preconditions, and what the approval entails. An agent might not know if the session must be in a specific state or if approval is the only step. This leaves gaps for a mutation tool with no 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 schema has one parameter (session_id) with no description, and schema description coverage is 0%. The tool description does not elaborate on what session_id refers to or how it should be obtained. Although the parameter name is self-explanatory, the description adds no value beyond the schema, failing to compensate for the lack of schema documentation.

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

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

The description clearly states a specific verb ('Approve') and resource ('pending plan for a session created with plan approval required'). It distinguishes this tool from siblings by narrowing its use to a particular session type, making its purpose 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 provides a clear condition for use: only for sessions created with plan approval required. It implies this tool is not for sessions without that requirement, but it does not explicitly name alternatives or exclusions. Still, the context is specific enough for an agent to decide when to invoke 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. It discloses the important non-obvious default that Jules auto-approves its plan and explains how to force human/model inspection first. This materially changes what happens when the tool is invoked, though other side effects like branch changes or execution details are not mentioned.

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 short sentences with no filler. The core action is front-loaded, and the source-format detail plus the plan-approval caveat each earn their place without repeating schema property names.

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

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

With an output schema present and no annotations, the description covers the key behavioral contract and the most non-obvious parameter formats. It omits some details like starting_branch semantics and prerequisites for a connected source, but the tool is still callable correctly with the information provided.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain the accepted formats for source and the meaning of require_plan_approval, but prompt, title, and starting_branch are left entirely to their names. This is helpful but only partially covers the parameter surface.

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

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

The description opens with a specific verb ('Create'), names the resource ('Jules coding session'), and scopes it to 'a connected GitHub source'. This clearly distinguishes it from sibling tools like jules_list_sessions, jules_send_message, and jules_approve_plan.

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 tool's creation purpose is unambiguous, and the description gives clear guidance on when to set require_plan_approval. It does not explicitly state when not to use it or name alternatives, but the context is clear enough that an agent can select it appropriately.

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 repeats the action implied by the name and provides no information about return format, error handling, side effects, or auth requirements. The existence of an output schema may cover some return details, but the description itself adds no behavioral 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, concise sentence, which is appropriately sized for a simple getter. It is front-loaded with the core action. However, it is so brief that it omits essential context, making it feel under-specified rather than efficiently concise.

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 two required parameters and no annotation coverage, the description is incomplete. It doesn't explain how to obtain the activity_id, what a Jules session is, or how this tool fits into the broader workflow. The output schema exists but its content is unknown, and the description doesn't reference it. Overall, an agent lacks enough context to use the tool correctly.

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

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

The input schema has 0% description coverage, and the tool description does not mention the parameters at all. The parameter names (session_id, activity_id) are somewhat self-explanatory, but the description does not clarify their format, how to obtain them, or any constraints. Since the schema provides no help, the description fails to compensate.

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

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

The description states a clear action (get) and resource (one activity) with context (from a Jules session). It differentiates from jules_list_activities by specifying 'one' vs a list, making its purpose distinguishable. However, it doesn't mention the identifiers or that it fetches by ID, which is implied but not 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?

No guidance is provided on when to use this tool versus alternatives like jules_list_activities or jules_get_session. There is no mention of exclusions, prerequisites, or context in which this tool is preferred. The description gives no usage direction.

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. 'Get' signals a read-only operation and the resource-name format is a useful behavioral detail, but error/not-found behavior and auth requirements are not disclosed.

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

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

One compact sentence that front-loads the operation and gives an example; no filler or redundancy.

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

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

For a low-complexity getter with an output schema, the description covers the key input semantics. It omits not-found behavior, but the example and identifier clarification make it sufficient for basic invocation.

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

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

Schema coverage is 0%, so the description must explain session_id. It adds clear meaning by saying the parameter accepts either a bare ID or a resource-name form like 'sessions/123', partially compensating for the missing schema 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 a specific verb ('Get'), a clear resource ('a Jules session'), and the two accepted identifier forms (ID or resource name), which distinguishes it from sibling listing tools like jules_list_sessions.

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

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

The phrase 'by ID or by resource name' implies this is the targeted fetch tool when an identifier is already known, but it does not explicitly state when to prefer it over jules_list_sessions or mention any exclusions.

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

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

With no annotations provided, the description carries the burden of behavior disclosure. 'Get' makes the read-only nature evident, and the included content is stated, with no implication of mutation or side effects. It does not discuss authorization or error behavior, but those are less critical for a simple retrieval 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 entire description is one concise, front-loaded sentence that names the action, the object, and the key included data without repetition or filler.

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

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

The output schema covers return values, but a critical gap remains: the source parameter's expected format is undefined, and there are no annotations conveying safety or scope. The tool is simple enough that this is barely adequate, but not fully complete.

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

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

Schema description coverage is 0%, and the description does not clarify what the 'source' parameter should contain (identifier, name, path, or repository). The word 'source' only echoes the tool name and does not give the agent enough information to construct a correct argument.

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

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

The description uses a specific verb ('Get') with a singular resource ('one Jules source') and names included content (repository metadata, available branches). This clearly differentiates it from jules_list_sources, which would be the sibling for retrieving multiple sources.

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

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

The singular 'one' and the mention of branches convey that this is the tool for fetching a single source in detail, which gives clear selection context. It does not explicitly name jules_list_sources as the alternative for enumerating all sources, so it stops short of a 5.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that activities/events are immutable, which supports repeated polling safely, and it explains the create_time-based snapshot behavior. However, it does not state pagination behavior, ordering, permission requirements, error behavior, or explicitly confirm read-only semantics 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 short and front-loaded: first the purpose, then a focused note on the most important parameter. Every sentence adds information, and there is no repetition or filler. The RFC 3339 clarification is especially valuable.

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 4-parameter list tool with no annotations, the description is only somewhat complete. It explains create_time and immutability, and an output schema is present, so return shape is less critical. However, it omits any explanation of pagination parameters, does not differentiate from sibling tools, and does not mention default filtering behavior or limitations.

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

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

Schema description coverage is 0%, so the description must compensate. It does for create_time by giving its exact format, its filtering meaning, and a use case. But it says nothing about session_id, page_size, or page_token, leaving pagination and required-session semantics only implied by names and defaults. This is partial, not complete, compensation.

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 immutable activities/events for a Jules session.' This is clear enough to distinguish it from jules_get_activity, which likely fetches a single activity, and from sibling list/session tools. It does not fully specify scope ('all', 'paginated'), but the core purpose is 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 gives a concrete usage hint: using create_time with an RFC 3339 timestamp is useful for incremental polling. However, it does not explicitly say when to choose this tool over jules_get_activity or jules_session_snapshot, nor does it mention when not to use it. The guidance is implied rather than explicit.

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

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

With no annotations, the description must disclose behavioral traits. 'List' implies read-only and 'authenticated account' indicates scoping, but it does not explain pagination behavior, ordering, or whether any side effects occur. Minimal transparency beyond the action itself.

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, efficient sentence placed at the start. No filler or redundant phrasing—every word contributes to the tool's purpose.

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

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

The description is adequate for a straightforward list operation with an output schema present. However, it lacks guidance on pagination semantics, alternative selection, and any authentication prerequisites, so an agent would need to infer some context.

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

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

Schema description coverage is 0%, so the description should compensate for the two parameters (page_size, page_token). It does not mention them or pagination at all. Parameter names and defaults in the schema provide some meaning, but the description adds none.

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'), a clear resource ('Jules coding sessions'), and a scope ('for the authenticated account'). It distinguishes itself from siblings like jules_list_sources and jules_get_session by specifying the exact object being listed.

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: use this to retrieve all sessions for the authenticated user, as opposed to getting one session (jules_get_session) or listing other entities (jules_list_sources, jules_list_activities). However, no explicit alternatives or when-not-to-use conditions are given.

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 discloses authentication scope ('connected to the authenticated Jules account'), which is useful. However, it does not explicitly state that the operation is read-only, does not describe pagination behavior, or mention any potential side effects. For a simple list operation, this is adequate but not thorough.

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, concise sentence that is front-loaded with the core purpose. There is no extraneous information or verbosity; every word contributes to clarity.

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 with an output schema that defines return structure, so that is covered. However, the description does not explain pagination (despite having pagination params), nor does it mention any limitations or edge cases. For a list tool, this is moderately complete but missing useful context that an agent could leverage.

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 0%, so the description must compensate. It does not mention page_size or page_token at all, leaving the agent to guess their meaning from names alone. The names are somewhat self-explanatory (pagination), but no explicit explanation of default behavior or token usage is provided, which is a notable gap given the low schema coverage.

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

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

The description states a specific action (List), a clear resource (GitHub repositories/sources), and a scope (connected to the authenticated Jules account). It effectively differentiates from sibling jules_get_source (which retrieves a single source) and jules_list_sessions (which lists sessions, not sources).

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

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

No guidance is provided on when to use this tool versus alternatives. The description only states what it does, with no mention of conditions like 'use this to enumerate all sources' or 'if you need a specific source, use jules_get_source instead.' The agent must infer usage from the name and sibling set.

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, but it only mentions the action without disclosing side effects, error behavior, or requirements (e.g., what happens if session is inactive, whether it's fire-and-forget, authentication needs). The description adds minimal behavioral context beyond the verb itself.

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, concise sentence that front-loads the core action. There is no wasted wording or filler.

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

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

For a tool with no annotations and 0% schema coverage, the description is too sparse. It does not mention return values, error handling, or operational details. The presence of an output schema helps, but the description still leaves key usage questions unanswered.

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

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

Schema description coverage is 0%, so the description must compensate. It does not explain the meaning of 'prompt' beyond 'feedback/additional instructions' and does not clarify 'session_id' format or expectations. No examples or constraints are provided.

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 (send) and the resource (message to a session), and specifies the purpose (feedback/additional instructions). It is distinct from sibling tools like create_session or approve_plan, but does not explicitly differentiate itself, so it misses the top 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?

It implies the session must be active, but gives no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or conditions. The context is inferred from 'active session' rather than stated.

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

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

No annotations are provided, so the description carries the full burden. It only states it 'fetches' data, implying a read-only operation, but does not disclose pagination behavior (e.g., how 'latest page' is determined), ordering, or any limits beyond the page size parameter. The snapshot concept could have been explained further.

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. It is appropriately terse, though it sacrifices 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?

An output schema exists, so return values are covered, but the description omits any explanation of parameters and the exact scope of the 'snapshot' (e.g., whether it includes only the current session state or also metadata). For a combined fetch tool, more detail on the activity page default and how pagination works would be necessary.

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

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

Schema description coverage is 0%, and the description does not mention either parameter (session_id or activity_page_size). The agent must rely entirely on the schema, which lacks descriptions. The description adds zero value to parameter understanding.

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

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

The description states a clear verb ('Fetch') and specific resources ('current session object' and 'latest page of activities'), and explicitly notes they are retrieved together. This distinguishes it from individual session/activity tools like jules_get_session and jules_list_activities, though it doesn't name them explicitly.

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

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

The description implies a combined fetch but provides no guidance on when to use this tool versus calling separate session and activity tools. No conditions, prerequisites, or alternatives are mentioned.

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 largely meets it: it discloses that the call blocks, polls until a terminal/paused state or timeout, and returns on specific states. The main gap is the unspecified timeout outcome (error vs. current-state return), but the core behavioral contract is clear.

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

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

Three short sentences, front-loaded with the core behavior, followed by return conditions and use case. No filler or repetition.

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

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

For a simple polling tool, the description covers the what, the when, and the return-triggering states. The output schema exists to explain return values. Missing timeout behavior and default-value callouts are the main omissions, so it's strong but not exhaustive.

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 descriptions are absent (0% coverage), but the description's language gives meaning to the key parameters: 'timeout' maps to timeout_seconds, 'Poll' maps to poll_interval_seconds, and 'a Jules session' maps to session_id. It doesn't explicitly document each parameter or defaults, so it partially compensates but leaves some work to inference.

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

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

The description opens with a specific verb and resource ('Poll a Jules session') and defines the completion condition ('until it stops actively running or until timeout'). It also enumerates the exact session states that cause the method to return (COMPLETED, FAILED, PAUSED, AWAITING_PLAN_APPROVAL, AWAITING_USER_FEEDBACK), clearly distinguishing it from sibling get/list/snapshot 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 explicitly states the intended usage context: 'useful after creating a task when the caller wants a bounded wait instead of manual polling.' This tells an agent when to choose this tool over manual polling, though it doesn't name specific alternative tools or exclusion criteria.

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