Server Quality Checklist

Tool Scores

• jules_unarchive_sessionA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action and result but does not disclose side effects, reversibility, error behavior (e.g., if the session is not archived), or any permissions/security implications.

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

  Conciseness5/5

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

  The description is a single, focused sentence that front-loads the action and outcome. Every word earns its place, with no redundancy or filler.

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

  Completeness3/5

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

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

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

  Parameters3/5

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

  The single parameter sessionId is fully described in the schema ('Session ID to unarchive'), and the description adds no additional meaning beyond the schema. Since schema coverage is 100%, the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description uses the specific verb 'Restore' and clearly identifies the resource ('previously archived Jules session') and the outcome ('appears in the default session list again'). This distinguishes it from sibling tools like jules_archive_session and jules_delete_session.

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

  Usage Guidelines3/5

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

  The description implies the tool is for reversing an archive operation, but it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites. The context is clear but not comparative.

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

• jules_list_activitiesA
  3.6/5.0
  Behavior3/5

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

  No annotations are present, so the description carries full responsibility for behavioral transparency. It usefully discloses the contents (plan generation, progress updates, messages, completion) and ordering (most recent first), but does not mention pagination behavior, error conditions, or any access requirements.

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

  Conciseness5/5

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

  Two concise sentences front-load the core purpose and then add valuable detail about content and ordering. No redundant or wasted wording.

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

  Completeness4/5

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

  For a simple listing tool, the description provides the core purpose, activity types, and ordering. It does not describe the return shape or mention pagination, but the schema's pageToken and default limit cover those mechanics, and there are no annotations or output schema.

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

  Parameters3/5

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

  Schema descriptions cover all three parameters at 100%, so the baseline applies. The description adds no parameter-specific detail beyond the schema; it only reinforces that the log is for a session.

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

  Purpose4/5

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

  The description clearly states the tool gets a detailed activity log for a Jules session and enumerates activity types, making the purpose apparent. It does not explicitly distinguish from the sibling jules_get_activity, but the plural 'activities' and 'log' convey a listing operation.

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

  Usage Guidelines3/5

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

  There is no explicit guidance on when to use this tool versus alternatives such as jules_get_activity. The description implies it should be used when a session's activity history is needed, but it lacks exclusions or alternative recommendations.

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

• jules_get_activityA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the core action and does not mention error handling, permissions, return format, or what happens if the activity is not found. This minimal transparency is insufficient for a tool with no annotations.

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

  Conciseness5/5

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

  The description is exactly two sentences: one stating the purpose and one pointing to a sibling tool. It is front-loaded, direct, and contains no unnecessary words or repetition.

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

  Completeness4/5

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

  For a simple by-ID fetch with two well-documented parameters, the description covers the essential operation and provides a valuable pointer to the list tool. However, since there is no output schema and no behavioral notes about errors or response format, it is not fully complete.

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

  Parameters3/5

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

  The input schema covers 100% of parameters with descriptions for both sessionId and activityId. The description adds no additional parameter meaning beyond the schema, so the baseline score of 3 applies.

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

  Purpose5/5

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

  The description clearly states 'Get a single activity from a Jules session by ID,' which has a specific verb, resource, and method of retrieval. It distinguishes itself from the sibling tool jules_list_activities by specifying retrieval of a single activity by ID rather than listing activities.

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

  Usage Guidelines4/5

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

  The description includes 'Use jules_list_activities to find activity IDs,' which provides an explicit alternative for a related task. This implies the tool is for when an activity ID is already known, offering clear context on when to use this tool versus the list tool.

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

• jules_list_sessionsA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses the read-only listing behavior and that states are included, but it does not clarify pagination behavior (e.g., 'all' may require multiple pages) or any other constraints. This is a minor transparency gap.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the action ('List all your Jules sessions') and includes a practical use case. Every word earns its place, with no redundant information.

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

  Completeness3/5

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

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

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

  Parameters3/5

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

  The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no additional parameter information, meaning no extra credit for clarifying semantics beyond the schema.

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

  Purpose5/5

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

  The description uses a specific verb 'List' with the resource 'Jules sessions' and adds 'with their current states', making it clear what the tool does. This distinguishes it from siblings like jules_create_session or jules_get_status, which have different purposes.

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

  Usage Guidelines4/5

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

  The description provides clear context by stating 'Useful for finding session IDs or checking on multiple tasks', indicating when to use the tool. It does not explicitly mention alternatives or exclusions, but the use case is well implied.

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

• jules_get_session_outputA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It states the return includes 'final output and results' and 'pull request details,' and implies a prerequisite that the session be completed. However, it does not disclose error behavior if used prematurely, auth requirements, or guarantee of non-mutation. Adequate but not rich.

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

  Conciseness5/5

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

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

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

  Completeness4/5

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

  For a simple tool with one parameter and no output schema, the description adequately covers the purpose and usage condition. It could be more complete by explaining what happens if the session is not completed, but given the low complexity, it is nearly complete, earning a 4.

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

  Parameters3/5

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

  Schema description coverage is 100%, and the parameter 'sessionId' is already described as 'Session ID to get output for.' The description does not add additional semantic meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the action ('Retrieve the final output and results'), the resource ('from a completed Jules session'), and even includes specific content ('including pull request details'). It distinguishes itself from sibling tools by specifying the post-completion context, differentiating it from get_status and list_sessions.

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

  Usage Guidelines4/5

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

  The description explicitly says 'Use after session state is COMPLETED,' providing clear timing guidance. It does not mention when not to use it or alternative tools, but the completion prerequisite is a strong usage guideline, earning a 4.

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

• jules_get_statusA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It adds useful behavioral context by indicating the tool is for repeated polling and the typical duration, implying it's safe to call. However, it does not explicitly state that it is read-only, disclose error behavior, or mention any side effects or permissions needed.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the core purpose, and includes only essential usage guidance (polling and typical duration). No filler or redundancy.

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

  Completeness4/5

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

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

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

  Parameters3/5

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

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

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

  Purpose5/5

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

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

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

  Usage Guidelines4/5

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

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

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

• jules_list_sourcesA
  4/5.0
  Behavior3/5

  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 adds value by disclosing the prerequisite of installing the GitHub app, which directly impacts whether repositories will appear. Yet it does not mention pagination behavior, return format, or whether the operation is read-only (though 'list' implies). This is some behavioral context, but not comprehensive.

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

  Conciseness5/5

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

  The description is two sentences long and front-loaded with the core purpose. The first sentence states what the tool does, and the second sentence adds a necessary prerequisite. No word is wasted, and the structure is clear and efficient.

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

  Completeness4/5

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

  For a list tool with three optional parameters and no output schema, the description covers the main purpose and the key prerequisite. It could be slightly more complete by explaining what the response contains, but the phrase 'List all GitHub repositories' implies the output. The schema already covers parameter details, so the description is sufficient for most use cases.

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

  Parameters3/5

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

  The input schema has 100% coverage with descriptions for all parameters (filter, pageSize, pageToken). The tool description does not add any additional meaning beyond what the schema already provides, so 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.

  Purpose5/5

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

  The description clearly states the tool's function: 'List all GitHub repositories connected to Jules.' The verb 'list' plus the resource ('GitHub repositories') makes the purpose explicit. It also distinguishes from the sibling tool 'jules_get_source' by indicating it lists all sources rather than retrieving a single one.

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

  Usage Guidelines4/5

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

  The description provides a clear prerequisite: 'You must install the Jules GitHub app at https://jules.google.com before repositories appear here.' This guides when the tool will be useful (after installation) and implies it should not be used expecting repositories without the app. However, it does not explicitly differentiate when to use this tool versus alternatives like 'jules_get_source'.

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

• jules_list_stuck_sessionsA
  4/5.0
  Behavior3/5

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

  With no annotations, the description bears the full burden of behavioral disclosure. It discloses that pagination is handled automatically, but it does not explicitly state that the operation is read-only or describe other potential behaviors like rate limits or response characteristics. This is a moderate but not comprehensive disclosure.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that communicates the core purpose and key behavior without any unnecessary words or repetition.

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

  Completeness4/5

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

  For a simple list tool with one optional parameter and no output schema, the description defines the term 'stuck', explains the tool's scope, and mentions automatic pagination. It is mostly complete, though it could briefly mention what the response contains or compare with sibling list tools.

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

  Parameters3/5

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

  The only parameter (pageSize) is fully documented in the schema with a default and description. The description's mention of automatic pagination adds mild context but does not significantly enhance the parameter's meaning beyond the schema.

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

  Purpose5/5

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

  The description uses a specific verb ('List') and identifies the resource ('sessions') with a clear scope ('waiting for plan approval or user feedback'). This distinguishes it from sibling tools like jules_list_sessions and jules_wait_for_session.

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

  Usage Guidelines4/5

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

  The description clearly indicates when to use the tool: to list sessions stuck in waiting states. It also notes automatic pagination. However, it does not explicitly name alternative tools or state when NOT to use it, so it stops short of a perfect score.

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

• jules_send_messageA
  4/5.0
  Behavior3/5

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

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

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

  Conciseness5/5

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

  Two concise sentences, front-loaded with the core purpose and immediately useful next steps. No wasted words.

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

  Completeness4/5

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

  For a simple message-sending tool with two parameters and no output schema, the description covers the purpose, the session context, and where to see the response. It doesn't elaborate on failure modes, but that's acceptable given the tool's simplicity.

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

  Parameters3/5

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

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

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

  Purpose5/5

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

  The description clearly states the tool sends a follow-up message or instruction to a running Jules session, using a specific verb and resource. It distinguishes itself from sibling tools like jules_list_activities or jules_get_status by focusing on the act of sending a message to an existing session.

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

  Usage Guidelines4/5

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

  The description gives context that it's for running sessions and directs the user to check the response via jules_list_activities or jules_get_status. It implies the use case of sending follow-up messages but doesn't explicitly contrast with alternatives like jules_approve_plan or state prerequisites beyond 'running'.

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

• jules_create_sessionA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden and discloses useful traits: 'runs in an isolated cloud VM' and 'typically completes tasks in 5-60 minutes depending on complexity'. This adds behavioral context beyond the schema. It does not explicitly state that code changes will be made, but 'coding task' implies it, and the schema covers autoApprove/autoCreatePR behavior.

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

  Conciseness5/5

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

  The description is three concise sentences, each earning its place: purpose, user action, and execution context. It is front-loaded with the main intent and contains no filler or repetition, making it easy to parse quickly.

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

  Completeness3/5

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

  The description covers the tool's essence and provides timing expectations, but since there is no output schema, it does not explain what the tool returns (e.g., session ID) or how to track progress. While sibling tools exist for status, the description does not mention next steps, leaving the agent to infer the post-creation workflow.

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

  Parameters3/5

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

  Schema coverage is 100%, so baseline is 3. The description reinforces that 'prompt' should be detailed and identifies repoOwner/repoName as 'the repository to work on', but it does not add unique meaning beyond the schema. The schema already provides individual parameter descriptions, so the description adds minimal extra semantic value.

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

  Purpose5/5

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

  The description starts with 'Start a new asynchronous coding task with Jules' which clearly identifies the action and resource. It distinguishes this creation tool from sibling tools like jules_list_sessions, jules_get_status, and jules_delete_session by focusing on initiating a new session rather than managing existing ones.

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

  Usage Guidelines4/5

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

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

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

• jules_wait_for_sessionA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description must carry the full burden of behavioral disclosure. It explains that the tool polls, tracks progress, emits progress notifications, returns a unified payload with final state/details, and is bounded by a wait limit to prevent timeouts. This gives the agent a clear picture of what happens without repeating annotation data.

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

  Conciseness5/5

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

  The description is extremely concise at two sentences, opens with the core purpose, and every clause adds value (tracks progress, emits notifications, returns payload, bounded wait). There is zero redundancy or filler, making it easy for an agent to parse quickly.

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

  Completeness4/5

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

  Given the lack of an output schema, the description adequately explains the return payload (unified payload with final state, summary, and PR details) and mentions timeout prevention. It doesn't cover error handling or specific edge cases, but for a wait/poll tool this is sufficient. The presence of siblings like jules_get_status might imply more granular reads, but the description is complete enough for successful invocation.

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

  Parameters3/5

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

  Schema coverage is 100% for the three parameters (sessionId, maxWaitSeconds, includeActivities). The description adds minimal parameter-specific meaning—it only hints at the wait limit ('bounded by a wait limit') and the unified payload, but doesn't elaborate on how includeActivities affects output. With high schema coverage, baseline is 3, and the description doesn't exceed that.

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

  Purpose5/5

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

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

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

  Usage Guidelines4/5

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

  The description implies when to use this tool: when you have a session ID and need to wait for its completion. It mentions it automatically tracks progress and emits notifications, suggesting it's more comprehensive than simple polling. However, it doesn't explicitly state when NOT to use it or compare it to alternatives like jules_get_status, though the context of 'wait/poll' provides clear usage context.

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

• jules_approve_planA
  4.4/5.0
  Behavior4/5

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

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

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

  Conciseness5/5

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

  The description is three sentences that are concise and information-dense. It front-loads the action, then adds the condition, then gives a practical pointer without any fluff.

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

  Completeness4/5

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

  For a simple approve operation with one parameter, the description covers the action, required precondition, and a helpful handoff to view the plan. The absence of an output schema means return values are not specified, but the description gives enough to invoke the tool correctly.

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

  Parameters3/5

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

  The input schema already provides a description for sessionId ('Session ID to approve plan for'), and schema coverage is 100%. The tool description adds no further parameter-level detail, so the baseline of 3 applies.

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

  Purpose5/5

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

  The description uses a specific verb 'Approve' with a clearly defined resource 'execution plan for a Jules session' and a condition (requirePlanApproval=true). It distinguishes itself from sibling tools by indicating this is an action on a plan, not a list or session management tool.

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

  Usage Guidelines5/5

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

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

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

• jules_get_sourceA
  4.4/5.0
  Behavior4/5

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

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

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

  Conciseness5/5

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

  The description is two sentences long, front-loaded with the main purpose, and follows with a precise pointer to the alternative sibling tool. Every sentence contributes value with no unnecessary filler.

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

  Completeness4/5

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

  For a simple two-parameter get operation with no output schema, the description covers the key scope, return contents (branches, visibility), and the relationship to the sibling listing tool. It lacks explicit error behavior or prerequisites, but these are less critical for a straightforward read operation. The guidance is sufficient for an agent to select and invoke the tool correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both repoOwner and repoName fully described in the input schema. The description does not add any additional parameter-level context beyond what the schema already provides, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the function: 'Get details for a single GitHub repository connected to Jules, including its branches and visibility.' This uses a specific verb and resource, and it distinguishes from the sibling tool 'jules_list_sources' by focusing on a single repository rather than all.

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

  Usage Guidelines5/5

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

  The description explicitly provides usage guidance with 'Use jules_list_sources to see all connected repositories,' which tells the agent when to use this tool vs an alternative. It implies that this tool is for individual repository lookup, while the sibling handles listing all connected sources.

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

• jules_delete_sessionA
  4.5/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses the critical behavioral trait that deletion is permanent and cannot be undone. It could additionally mention side effects (e.g., associated data removal), but the core irreversible nature is clearly stated.

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

  Conciseness5/5

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

  Two sentences, no wasted words, and the most important information (permanent deletion) is front-loaded. The alternative is provided succinctly.

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

  Completeness5/5

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

  For a simple delete operation with one parameter and no output schema, the description is complete. It covers purpose, irreversibility, and alternative usage. The sibling context (archive/unarchive) further reinforces the distinction.

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

  Parameters3/5

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

  Schema description coverage is 100%, and the only parameter (sessionId) is already described as 'Session ID to delete.' The tool description adds no extra meaning beyond the schema, which is acceptable given the high coverage and simple single-parameter nature.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Permanently delete a Jules session.' It uses a specific verb ('delete') and resource ('session'), and explicitly contrasts with sibling tool jules_archive_session, making differentiation clear.

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

  Usage Guidelines5/5

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

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

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

• jules_execute_and_waitA
  4.5/5.0
  Behavior4/5

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

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

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

  Conciseness4/5

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

  A single, dense paragraph is packed with meaningful details—not a blank 'summary'; it carries exactly the substance of what is needed. No wasted words, although it is a long sentence it is acceptable given complexity.

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

  Completeness5/5

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

  It has 9 parameters, a modest but non-trivial tool; the description covers lifecycle (creation, return, progress, output), wait limits, inputs, outputs; the output schema is absent, but the description of the returned payload (final state, summary, PR details) completes it.

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

  Parameters5/5

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

  Input schema descriptions are rich: each property has an explanation, especially prompt details, defaults, max, etc. The description adds no semantics beyond the schema but the schema already provides near-total coverage of the parameters; to that score the description provides value in explaining the purpose of select parameters.

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

  Purpose5/5

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

  The description states a specific action ('Create a new Jules session') and resource ('wait/poll for its completion'), clearly distinguishing this from a basic creation tool by emphasizing the wait and return behavior.

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

  Usage Guidelines4/5

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

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

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

• jules_archive_sessionA
  4.7/5.0
  Behavior5/5

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

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

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

  Conciseness5/5

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

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

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

  Completeness5/5

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

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

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

  Parameters3/5

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

  Schema coverage is 100% with 'sessionId' described as 'Session ID to archive'. The description adds no additional parameter context, but since the schema already documents the parameter fully, a baseline of 3 is appropriate. No extra semantics are needed for a single self-explanatory parameter.

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

  Purpose5/5

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

  The description clearly states the action: 'Archive a Jules session to hide it from the default session list without deleting it.' The verb 'Archive' is specific, and the resource 'Jules session' is explicit. It also distinguishes from sibling tools by explicitly contrasting with deletion and naming the corresponding unarchive tool.

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

  Usage Guidelines5/5

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

  The description provides clear context: use this to hide a session without deleting it. It explicitly directs to 'jules_unarchive_session' as the way to restore, effectively serving as both an alternative and a when-not-to-use (if you want to fully remove, you'd use delete instead). This is excellent usage guidance.

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