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

No annotations provided, so description carries full behavioral burden. It mentions POST for creation but does not disclose whether membership is additive or replacing, nor any permissions or idempotency. Missing critical mutation details.

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

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

Two-line description plus structured parameter list. Action is front-loaded in the first sentence. No redundant information.

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

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

Lacks completeness for a mutation tool: no info on return value, side effects, authorization, or behavior on duplicates. Output schema exists but description does not leverage it to explain response.

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 0% schema coverage, description provides meaningful semantics: group_id is a 'Billing group id' and user_ids_json is a 'JSON array of encoded user ids', clarifying type and format. Falls short on explaining 'encoded' or duplicate handling.

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

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

Description clearly states the verb 'Add members to a billing group' and specifies the HTTP endpoint. It distinguishes from sibling tools like 'remove_billing_group_members' and 'add_organization_group_members'.

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 guidelines on when to use this tool versus alternatives. The purpose implies billing group context, but no exclusions or prerequisites 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?

No annotations are provided, so the description must cover behavioral traits. It mentions mutation ('add'), but lacks disclosure on destructive nature, authentication requirements, effect on existing members, or error handling. The max 100 limit is a useful detail, but overall transparency is minimal.

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 concise, front-loads the action, and uses a clear argument list. Every sentence earns its place without 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 two required parameters and no nested objects, the description covers the basics but misses context like prerequisites, success/failure behavior, or return value (output schema exists but not described). Adequate but with 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?

The description adds meaning beyond the input schema by specifying the format of group_id (g_...) and the structure of user_ids_json (JSON array, max 100). This compensates for the 0% schema description 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 'Add members to an org group' with the HTTP endpoint, specifying the verb and resource. It is easily distinguishable from sibling tools like 'remove_organization_group_members' and 'list_organization_group_members'.

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 constraints like max 100 users per request, but does not explicitly state when to use this tool versus alternatives (e.g., remove or list). Usage context is implied but not 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 provided, the description bears full responsibility for disclosing behavior. It states that archiving prevents new runs, which is a key behavioral trait. However, it omits details about whether existing runs continue, if the action is reversible (implied by unarchive_agent), or required permissions. Basic transparency is present 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.

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

The description is extremely concise: two sentences. The first sentence states the purpose, and the second lists the argument. There is zero wasted text, and the important 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?

Given the tool's simplicity (one required parameter) and the presence of an output schema (not shown but indicated), the description provides sufficient context. It explains the action's effect and gives a param example. It could mention the return value type, but that is covered by the 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 input schema has 0% description coverage, but the description adds significant value by providing an example format ('for example bc-...') for the agent_id parameter. This hints at the expected identifier pattern, which goes beyond the schema's type and title.

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 'archive' and the resource 'agent', and explains the effect: 'so it cannot accept new runs'. This effectively distinguishes it from sibling tools like unarchive_agent, delete_agent, and list_agents.

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 does not provide any guidance on when to use this tool versus alternatives such as delete_agent or unarchive_agent. There is no mention of prerequisites, when not to use, or how to decide between archiving and other actions.

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 'Cancel an active agent run' without disclosing side effects, reversibility, permission requirements, or error states.

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 includes the essential information. The 'Args:' list is slightly redundant but not wasteful. Could be more concise without losing 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?

Despite having an output schema, the description omits important behavioral details like whether the run must be active, what happens if already canceled, or authentication needs. Incomplete for a mutation tool.

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 0% schema description coverage, the description adds examples for agent_id and run_id formats (e.g., 'bc-...', 'run-...'), which provides some guidance but lacks detail on where to obtain these IDs or their constraints.

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

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

Clearly states the action 'Cancel an active agent run' with the HTTP method and path, distinguishing it from sibling tools like list_agent_runs or create_agent_run.

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

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

No guidance on when to use this tool versus alternatives (e.g., when a run is already completed or cannot be canceled). Does not mention prerequisites or 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 the full burden. It mentions idempotent creation via agent_id but does not detail error scenarios, rate limits, or side effects beyond the initial run enqueue. The note on extra_json conflicts is a minor behavioral disclosure.

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

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

The description starts with a clear purpose but then becomes a lengthy parameter list. While structured, it could be more concise by grouping related params or using shorter descriptions. The front-loaded sentence is good.

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?

Covers all 13 parameters but does not explain the output (though an output schema exists). Missing guidance on when to create a new agent vs. using create_agent_run, and no mention of typical use cases or workflow 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 coverage is 0%, so the description provides all parameter semantics: constraints (e.g., max 100 chars), formats (bc-...), and advanced usage (extra_json). Each parameter gets an explanation beyond the schema's type and title.

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 'Create a Cloud Agent and enqueue its initial run' and includes the HTTP method and endpoint. It distinguishes from sibling tools like archive_agent, delete_agent, and create_agent_run by focusing on creation and initial run.

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 such as create_agent_run (for existing agents) or list_agents (for querying). The description does not provide context on prerequisites or 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?

No annotations are provided, so the description carries full responsibility. It implies the agent must be active but does not explain behavior on inactive agents, side effects, idempotency, or authentication requirements. The description is mostly a parameter 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 concise with a front-loaded main action. The parameter list is clear, though the 'Args:' section is somewhat redundant with the input schema. Slightly exceeding minimal viable length.

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 but is not described, leaving the return value unclear. The description does not mention preconditions (e.g., agent must be active) or link to related sibling tools. Adequate but has 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 0%, but the description adds context: mode options (agent/plan), warning that extra_json cannot overwrite certain fields, and clarifies prompt_text as 'follow-up instruction'. This compensates for the schema's lack of descriptions.

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 a follow-up prompt to an active agent') and identifies the resource (agent run) with a specific HTTP endpoint. It differentiates from siblings like cancel_agent_run and list_agent_runs.

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

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

No guidance on when to use this tool versus alternatives (e.g., create_agent for new conversations, stream_agent_run for streaming). No exclusions or prerequisites 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?

The description only mentions creation with no details on side effects, permissions, idempotency, or errors. No annotations are provided, so the description carries full burden but fails to disclose behavioral traits.

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?

Concise at two sentences. Structured with args list, but no wasted words. However, presenting args in code style is acceptable.

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?

Missing return value description, error scenarios, and prerequisites. With only 2 parameters, the description could be more complete, especially since annotations are absent.

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 adds meaning for group_type ('currently only BILLING'), which provides a constraint not in schema titles. However, the schema already has titles 'Name' and 'Group Type', so the description adds limited additional 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 'Create a billing group' and specifies the HTTP endpoint POST /teams/groups. It differentiates from sibling tools like list_billing_groups, get_billing_group, etc., by naming the create action.

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

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

No guidance on when to use this tool versus alternatives (e.g., update_billing_group, delete_billing_group). No context about prerequisites or constraints.

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?

Despite lacking annotations, the description discloses key behaviors: token lifespan (one-hour), redaction of accessToken in results, and the API endpoint. It does not mention side effects, but creating tokens is non-destructive. The information is sufficient for an agent.

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

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

The description is highly concise: three sentences plus a bullet list of arguments. Every sentence adds essential information, and there is no verbosity. The structure front-loads the core action.

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

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

Given the tool's simplicity (2 parameters, output schema exists), the description covers all necessary context: auth requirement, parameter semantics, token lifespan, and result redaction. It is complete without needing to describe return values.

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 0% schema description coverage, the description fully explains the parameters: 'for_user_email: Active team member email' and 'for_user_id: Active team member numeric user id.' It also clarifies the constraint that exactly one must be provided, adding significant value 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: 'Mint a one-hour user-scoped worker token (POST /v1/sub-tokens).' It specifies the action (mint), resource (worker token), and constraints (one-hour, user-scoped). The name matches, and there is no ambiguity with sibling 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 provides explicit usage guidelines: requires a service-account API key and exactly one of email or user id. It does not explicitly state when not to use or mention alternatives, but the constraint is clear. Sibling tools are distinct, so no confusion.

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

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

The description explicitly states the operation is permanent and irreversible. Without annotations, this adequately discloses the destructive nature. No contradiction.

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

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

Two concise lines plus an Args section. Every sentence adds value: action, HTTP method, irreversibility, and parameter format. No wasted words.

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

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

For a simple deletion tool with an output schema, the description covers the essential behavior (permanence) and parameter. It doesn't specify response details, but the output schema handles that. Adequate.

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

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

The description adds an example format 'bc-...' for agent_id, which is helpful beyond the schema that only has type and title. With 0% schema coverage, this provides useful guidance.

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 'Permanently delete an agent' with the HTTP method and resource. It distinguishes from siblings by implying this is the destructive deletion, as opposed to archive_agent.

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 notes irreversibility, which guides against accidental use. However, it does not explicitly mention when to use this over archive_agent, which is a sibling for reversible removal.

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 full burden. It only states 'Destructive' and the HTTP method, lacking details on irreversibility, side effects (e.g., associated memberships), or success response. Minimal disclosure.

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

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

Very brief but includes relevant HTTP endpoint. However, it lacks structure—no clear separation of purpose and details. The Args section is presented but not integrated into a flowing explanation.

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

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

Despite having an output schema, the description does not mention return values or error handling. A delete operation should at least note success indicators (e.g., 204 No Content) or prerequisites. Incomplete for safe agent 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 0%. The description repeats the parameter name and type ('group_id: Billing group id.'), which adds little beyond the schema's title 'Group Id'. No format, constraints, or examples are 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 ('Delete a billing group') with the HTTP method and path, making the purpose unambiguous. It distinguishes from sibling tools like list_billing_groups or create_billing_group via the verb 'delete'.

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

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

No guidance on when to use this tool versus alternatives like update_billing_group or remove_billing_group_members. The only indicator is 'Destructive', which implies finality but not selection criteria.

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

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

With no annotations, the description must disclose behavioral traits. It only says 'Delete', omitting details about idempotency, error behavior (e.g., if entry not found), permission requirements, or consequences. This is insufficient for a deletion tool.

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

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

The description is extremely concise—two short lines—with no extraneous information. Every word serves a purpose, and it includes the HTTP method for 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?

For a simple delete operation with one parameter and an output schema (though not shown), the description is adequate but lacks depth. It does not mention success/failure indicators, side effects, or permissions, leaving some ambiguity.

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 0% description coverage, and the description adds 'repo_id: Blocklist repo id.' This barely clarifies the parameter's purpose beyond the schema title 'Repo Id', leaving format, validation, and examples unknown.

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 'Delete one repository blocklist entry', which specifies the action (delete) and the resource (repository blocklist entry). It distinguishes from siblings like upsert_repo_blocklists (create/update) and list_team_repo_blocklists (list).

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

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

No guidance on when to use this tool vs alternatives. It does not mention prerequisites, such as needing ownership or admin permissions, nor does it contrast with other delete or blocklist 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?

The description discloses the presigned URL expiration (15 minutes) and the HTTP method, providing useful behavioral context. However, it omits potential side effects, authorization requirements, or rate limits. With no annotations, the description carries the burden, and while it adds value, it is not fully transparent.

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 concise with two short sentences and a bullet-like list of arguments. No extraneous information. The key action and parameters are front-loaded. Slightly more compact could be achieved, but it is efficient overall.

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 presence of an output schema (not shown), the description adequately covers the tool's function and parameters. However, it lacks usage guidelines, error handling, and behavioral context like permissions. For a tool with no annotations, it is moderately complete but has 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 coverage is 0%, so the description must add meaning. It provides examples for both agent_id ('bc-...') and path (relative path from list_agent_artifacts). This adds context beyond the bare schema, but could be more precise about formats or constraints. It compensates partially but not fully.

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 it returns a 15-minute presigned URL for an artifact, specifying the HTTP method and endpoint. This is a specific verb+resource. However, it does not explicitly differentiate from sibling tools like download_ai_code_commits, though the context of artifacts versus code commits provides some distinction.

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

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

No guidance on when to use this tool versus alternatives, such as direct download or other artifact operations. There are no prerequisites, exclusions, or alternatives mentioned, leaving the agent without context to choose correctly 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?

No annotations are present, so the description must carry the full burden. It discloses the HTTP method (GET) and that the response contains 'csv_text', but does not specify whether the operation is read-only, any side effects, permission requirements, or rate limits.

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

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

The description is concise, using two sentences and a bullet-like list for parameters. It avoids unnecessary verbosity while covering the core action and parameters.

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 download tool, the description covers the main function and parameters. However, it lacks details on date formats, user identifier format, potential errors, and the full output schema (though output schema exists externally).

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, but the description adds brief semantic labels for each parameter (e.g., 'Optional start date bound'). This helps the agent understand parameter purpose beyond what the schema provides (names and types only).

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 'Download AI change metrics CSV' specifying the verb and resource. It also includes the HTTP endpoint. However, it does not distinguish from the sibling tool 'download_ai_code_commits_csv', which has a very similar name and purpose.

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 'list_ai_code_changes' or the commits CSV download. The description only lists parameters, 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?

No annotations are provided, so the description carries full burden. It discloses the main behavior (download CSV as text) and parameters, but lacks details on error handling, rate limits, or side effects. The GET method implies read-only but is not stated.

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

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

The description is extremely concise, with only three lines of meaningful content. It front-loads the purpose and lists parameters without redundancy. Every sentence is necessary.

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 has an output schema and only three optional parameters, the description covers the essentials: purpose, return format (csv_text), and filter options. It could mention that the CSV is returned as a string, but the output schema likely provides structure, so it's nearly 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%, so the description must add meaning. It provides brief explanations for each parameter (e.g., 'Optional start date bound') but lacks format specifications (e.g., ISO 8601) or behavioral details like inclusivity.

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

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

The description specifies the tool downloads an AI commit metrics CSV via a GET endpoint and returns the CSV body as text. It uses a specific verb 'download' and resource 'AI commit metrics CSV', distinguishing it from siblings like list_ai_code_commits.

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 lists optional filters but provides no guidance on when to use this tool versus siblings like download_ai_code_changes_csv or list_ai_code_commits. Usage context is implied but not 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 full burden. It discloses the HTTP method (GET) and resource type ('durable metadata'), implying read-only and idempotent behavior. However, it lacks details on permissions, error handling, or rate limits.

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

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

The description is two concise sentences with no wasted words, including the HTTP path and argument.

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 that an output schema exists (not shown, but noted), the description does not need to explain return values. For a simple one-parameter tool, the description is complete and sufficient.

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

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

Schema coverage is 0%, so description must compensate. It adds an example format ('for example bc-...') which gives practical meaning beyond the schema's 'string' type.

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

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

Description states 'Get durable metadata for one Cloud Agent (GET /v1/agents/{id})', specifying verb, resource, and HTTP method. Clearly distinguishes from siblings like list_agents and archive_agent.

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 indicates when to use (to get metadata for a single agent) but does not explicitly mention when not to use or alternative tools. However, the sibling list provides 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 full burden. It only mentions 'GET', implying read-only behavior, but does not disclose permissions, rate limits, or error handling. Minimal disclosure beyond the HTTP method.

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

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

The description is extremely concise with two short sentences, front-loading the purpose and listing arguments clearly. No extraneous words; every sentence earns its place.

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

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

Given the tool's simplicity and the presence of an output schema, the description is sufficient to use it correctly. It explains inputs and purpose, though it could mention id format or error handling.

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%, yet the description adds value by explaining each parameter with examples (agent_id: 'bc-...', run_id: 'run-...'). This provides context beyond the schema's type and title.

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

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

The description clearly states 'Get one Cloud Agent run' with a specific HTTP method and path, distinguishing it from siblings like list_agent_runs (list) and create_agent_run (create). It precisely specifies the resource and action.

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 for retrieving a single run, but provides no explicit when-to-use or alternatives. It is adequate for a simple retrieval tool but lacks guidance compared to siblings like list_agent_runs for listing.

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 relies on 'Get' to imply read-only behavior, but does not detail what 'token usage' includes (e.g., breakdown by type) or any potential constraints. Adequate but minimal.

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

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

Two sentences plus a clean argument list. Front-loaded with purpose, no wasted words. Extremely concise and structured well.

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

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

Given the tool's simplicity (2 params) and the presence of an output schema (not shown), the description is mostly complete. It could mention return format briefly, but provides sufficient context for an agent to use 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 description adds meaningful information beyond the schema: agent_id gets a format example ('bc-...'), run_id is clearly explained as optional for scoping. Compensates for the schema's lack of descriptions.

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 'Get token usage for an agent' with optional run scoping, using specific verb and resource. It distinguishes from siblings like get_daily_usage_data and get_spending_data by specifying per-agent and optionally per-run scope.

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 for agent-specific token usage, but does not explicitly mention when to use alternatives or provide exclusions. Context is clear but lacks direct guidance.

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

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

No annotations are provided, so the description carries the burden. It discloses 'Limited alpha' status and the ability to accept comma-separated hashes. However, it does not explicitly state that the operation is read-only (though implied by GET) or any authentication or rate-limit 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 concise: a one-line purpose, a caveat, and parameter docs. It is front-loaded with the main action. Some may prefer more structure, but it is efficient.

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 presence of an output schema (handles return values), the description is adequate but lacks guidance on when to prefer this tool over sibling tools like list_ai_code_commits. The 'Limited alpha' note adds useful context, but more usage context would improve completeness.

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 clarify parameters. It adds that commit_hash can be a comma-separated list and branch is an optional filter, providing meaning beyond the parameter names in 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 'Get' and the resource 'commit detail / blame', and specifies the HTTP method and endpoint. This distinguishes it from siblings like list_ai_code_commits (which lists commits) and download_ai_code_commits_csv (which downloads CSV). Not a tautology.

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 for fetching details of specific commit(s) via the commit_hash parameter, but does not explicitly state when to use this tool over alternatives (e.g., list_ai_code_commits for browsing). No exclusions or when-not-to guidelines are provided.

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

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

With no annotations, the description provides basic behavioral info: it's a read operation, lists pagination with max page size, and parameter constraints. However, it lacks details on authentication, error handling, or data freshness.

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?

Structured with clear headers and bullet points for parameters. Every sentence adds value: endpoint, allowed metrics, parameter details. No 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?

Covers all 6 parameters, pagination limits, and allowed metrics. Output schema exists (not shown) so return format is covered. Lacks mention of permissions or error conditions, but sufficiently complete for a read-only fetch tool.

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%, but the description fully compensates by explaining each parameter: metric as allowlisted slug, date bounds, comma-separated users, page/page_size with defaults and max. This adds crucial meaning beyond the bare 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 'Fetch a by-user analytics metric' and specifies the endpoint. It lists allowed metrics, making the tool's purpose precise and distinct from siblings like get_team_analytics.

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. While the name implies per-user scope, there is no when-not-to-use or comparison with other analytics 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 full burden for behavioral disclosure. It states a read operation ('Return metadata') and includes the endpoint, but lacks details on authorization requirements, rate limits, or potential side effects. The minimal information leaves gaps for the agent.

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 that immediately states the purpose and includes the HTTP endpoint. Every word adds value, and there is no redundancy or wasted content.

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 has no parameters and an output schema exists (which describes the return value), the description sufficiently covers what the tool does. The endpoint reference aids understanding, and no additional context is needed for this simple retrieval operation.

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

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

The input schema has no parameters, so description coverage is 100% trivially. The description does not need to add parameter meaning but correctly implies the tool requires no user-provided arguments. Baseline score of 4 is appropriate for zero-parameter tools.

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

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

The description clearly specifies the action ('Return metadata'), the resource ('configured Cursor API key'), and includes the HTTP endpoint ('GET /v1/me'). No other sibling tool seems to perform this function, making it highly distinctive.

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 does not provide explicit guidance on when to use this tool versus alternatives. However, the purpose is straightforward, and with no similar sibling tools, the usage context is implicitly clear but could be improved with a note about typical use cases (e.g., verifying key status).

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 present, so the description carries full burden. It does not disclose behavioral traits such as rate limits, authentication requirements, or read-only nature (though implied by GET). Only basic fetch action is described.

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 concise with a clear one-line summary followed by a structured 'Args' block. Each parameter is listed with brief but sufficient detail. No unnecessary information.

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

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

The description covers all parameters and their usage fully. An output schema exists (not shown) so return values are not required. Minor omission: no mention of typical response structure, but output schema likely covers it. Adequate for a complex tool.

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%, but the description provides detailed semantics for all 7 parameters, including format examples (e.g., ISO8601 for time), defaults, and valid values (e.g., page_size 1-500). This fully compensates for the missing schema descriptions.

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 'Fetch team audit log events' which specifies the verb (fetch) and resource (audit log events). The HTTP path is also included, and it is distinct from sibling tools like get_usage_events.

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

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

No guidance on when to use this tool versus alternatives is provided. The description does not mention exclusions, prerequisites, or comparison with other 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 provided, so description must fill gaps. It describes the GET request and parameters but omits details like auth requirements, error responses, or side effects. Adequate for a simple read operation.

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

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

The description is brief and well-structured with a clear 'Args' section. Every sentence conveys essential information without 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?

Has output schema, so return values need not be detailed. Description covers operation and parameters sufficiently for a simple get tool, though missing edge case discussion.

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 description carries full burden. It explains group_id and billing_cycle with format and default, adding meaningful context beyond schema titles.

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 it retrieves a specific billing group by ID, including the HTTP method and path. However, it does not explicitly distinguish itself from siblings like list_billing_groups.

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 lacks any 'when to use' or 'when not to use' instructions.

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?

Discloses key behavioral traits: query-only nature ('query only'), date range constraint, and mode switching based on pagination. Without annotations, this adequately informs the agent of the tool's non-destructive read 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?

Concisely written with a clear break between general description and parameter details. Could be slightly tighter but remains informative without extraneous content.

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 (4 parameters, two modes) and the presence of an output schema, the description covers essential usage context, constraints, and behavior completely.

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 0% schema description coverage, the description fully compensates by explaining each parameter: epoch milliseconds for dates, optional pagination, and the behavior effect. Adds significant meaning beyond schema titles.

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 fetches daily team usage metrics, specifies the endpoint (POST /teams/daily-usage-data), and distinguishes it from siblings like get_organization_daily_usage_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?

Provides clear usage context: date range limit of 30 days and explains how page/pagination parameters affect returned data (active vs all members). Does not explicitly contrast with sibling tools but gives actionable guidance.

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

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

No annotations provided, so the description must convey behavior. It indicates a read operation via 'Get' and includes the HTTP endpoint. Lacks details on auth or data freshness, but for a simple count it's adequate.

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?

Extremely concise single sentence (under 20 words) that is front-loaded with the core action. No wasted words.

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

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

Tool is simple with zero parameters and an output schema available. Description fully covers what the tool does; no missing context for an agent to invoke it correctly.

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

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

No parameters in schema, schema description coverage is 100% by default. Description adds no param info, but none is needed. Baseline for 0 params is 4.

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

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

Description explicitly states the action (Get) and the resource (connected/in-use worker counts). It distinguishes from sibling tools like list_private_workers (list all workers) and get_private_worker (single worker) by focusing on summary counts.

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 when-to-use guidance, but the purpose is clear. Since it's a simple read-only summary with no parameters, usage is implied: use when you need aggregate worker counts.

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 must carry behavioral transparency. It does not disclose important behavioral traits such as data freshness, rate limits, authentication requirements, or pagination behavior beyond mentioning page/page_size. The description lacks critical details for a data retrieval tool.

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 structured with a brief summary followed by bullet-point-like lines for arguments. It is reasonably concise but includes redundant elements like repeating the function signature. Could be shorter and more direct.

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

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

The description covers the tool's purpose and parameter meanings, but given the tool's moderate complexity (6 parameters) and the existence of an output schema, it does not explain what the returned data represents or any limitations. It leaves the agent without a complete picture of the tool's behavior.

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 0% schema description coverage, the description partially compensates by explaining each parameter's meaning (e.g., organization_id format, date range as epoch ms). However, it does not clarify constraints like allowed values for team_ids_json (e.g., JSON array format) or the behavior of page/page_size (e.g., default values, max page size). The explanation adds value but is incomplete.

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 retrieves organization daily usage data, specifying HTTP method and path. It lists the arguments, making the purpose unambiguous. However, it does not differentiate from sibling tools like get_daily_usage_data or get_spending_data, which reduces clarity in context.

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 basic context (retrieving org daily usage) but no explicit guidance on when to use this tool versus alternatives. No prerequisites, when-not-to-use, or best practices are mentioned. This leaves the agent to infer usage 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 provided, and description does not disclose behavioral traits such as permissions, rate limits, or side effects. For a read operation, it could mention safety but does not.

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?

Short and to the point: purpose and parameter in two lines. No fluff, but could include a bit more context without being verbose.

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

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

For a simple get tool with one parameter and an output schema, the description is minimally complete. However, it lacks behavioral context and usage guidance.

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%; description adds value by specifying id format as 'g_...'. This hints at the expected pattern beyond the schema's type definition.

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

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

Description clearly states 'Get one organization group' with the HTTP endpoint, and it is distinct from sibling 'list_organization_groups'. The verb 'Get' and resource 'organization group' are specific.

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

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

No guidance on when to use this tool versus alternatives like list_organization_groups. Does not specify when it is appropriate or when not to use it.

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

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

With no annotations, the description discloses the HTTP method (POST) and operation type (query only), implying no destructive side effects. It also notes the required permissions. However, it does not mention rate limits, idempotency, or other behavioral traits beyond what the schema and endpoint hint provide.

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

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

The description is three sentences long, starts with the action and endpoint, and every sentence provides useful information without redundancy or waste.

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 has one parameter and an output schema, the description covers the essential context: what it does, how to call it, and required permissions. It could briefly define 'pooled usage' but is otherwise complete for its simplicity.

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

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

Schema description coverage is 0% and the only parameter is documented in the description with a format hint ('Public org id (org_...)'), adding meaningful guidance beyond the schema's string type.

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

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

The description specifies 'Get org pooled usage' with the HTTP method and endpoint, clearly indicating the action and resource. It differentiates from sibling tools such as get_organization_daily_usage_data and get_organization_spending_data by focusing on pooled usage.

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 states required permissions ('Organization API key with usage:* or admin:*') and that it is query-only, providing clear context for when to use. However, it does not explicitly mention when not to use or list alternative 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 must disclose behavioral traits. It does not mention side effects, authentication requirements, rate limits, or data scope. The tool lists parameters but lacks transparency on what happens during invocation.

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

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

The description is very concise, using a single summary line and a structured Args section. Every sentence adds value without redundancy. The purpose is front-loaded, and the parameter list is clear.

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 explains all parameters and the basic purpose. The output schema exists, so return values are covered. However, it lacks details on pagination behavior, sorting, or potential error conditions. Overall, adequate for a tool with 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?

With 0% schema description coverage, the description adds significant meaning: it explains that organization_id is a public org id format 'org_...', search_term is a name/email filter, page is 1-indexed, and page_size is optional. This goes well beyond the schema's type-only information.

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

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

The description clearly states 'Get org spend' and includes the HTTP method and endpoint, which specifies the action and resource. It distinguishes from siblings like 'get_spending_data' by including 'org' in the name and description.

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 such as 'get_spending_data' or 'get_organization_daily_usage_data'. No when-not-to-use or alternative references 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?

No annotations are provided, so the description carries full burden. It lacks details on whether the operation is read-only, any required permissions, rate limits, or side effects. The HTTP method (POST) is given but its implications are not explained.

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 concise with a single-line summary followed by a clean parameter list. Every sentence is relevant. Could be slightly more streamlined but no wasted words.

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

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

Given the presence of an output schema, return values need not be described. The description adequately covers all parameters for a data retrieval tool. Missing context about filtering behavior or relationship to other tools, but sufficient for basic 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 description provides brief but useful semantics for all 6 parameters: organization_id format, date range in epoch ms, team_ids_json as JSON array, pagination defaults. This compensates for the 0% schema description coverage, though examples or constraints would enhance it.

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

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

The description clearly states 'Get org-wide usage events' with the specific HTTP method and endpoint, and the 'org-wide' qualifier distinguishes it from sibling tools like 'get_usage_events'. It directly answers what the tool does.

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 it's for organization-level data via 'org-wide', but no explicit guidance on when to use versus alternatives (e.g., get_usage_events). No exclusions or prerequisites 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?

No annotations provided; description does not state read-only nature, authentication prerequisites, error conditions, or rate limits. Fails to disclose behavioral traits beyond the basic action.

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

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

Two sentences, no fluff, front-loaded with purpose. Every sentence is necessary.

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?

Simple GET tool with one parameter and an output schema (not shown). Description adequately covers the purpose and parameter. Lacks only minor behavioral details, which are less critical given 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?

Description adds example format 'pw_...' for worker_id, which adds value beyond the schema's title. However, schema coverage is 0% and the added context is minimal.

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?

Clearly states it gets one private worker, includes the HTTP method and endpoint. Distinguishes from sibling list_private_workers which retrieves multiple.

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?

Implied usage: use when you need a specific private worker by ID. No explicit guidance on when to avoid or alternatives 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?

Discloses that it is a POST endpoint used for querying only (read operation). Lacks details on authentication, rate limits, or error behavior. With no annotations, this is partial.

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?

Front-loaded with a concise purpose line, followed by a structured Args list. Every sentence adds value; no 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?

Does not mention return format or pagination details, though an output schema exists. Given the absence of annotations, some behavioral gaps remain (e.g., no mention of sorting behavior when multiple pages).

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 fully explains each of the 5 parameters (search_term, sort_by, sort_direction, page, page_size), adding semantics beyond the schema (0% coverage). Clearly states filter options and defaults.

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?

Clearly states the tool fetches current-cycle team spend, using a POST endpoint. Distinguishes from sibling 'get_organization_spending_data' by focusing on team-level 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?

No explicit guidance on when to use this tool versus alternatives like 'get_organization_spending_data' or 'get_daily_usage_data'. Usage must be inferred from the name.

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 present, so the description must reveal behavioral traits. It mentions the endpoint is GET, implying a read-only operation, but does not disclose permissions, rate limits, or error handling. The list of allowed metrics helps, but more transparency (e.g., 'requires analyst role') would improve the score.

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 structured with a metric list and parameter explanations. It is reasonably concise for the amount of information, though the metrics could be bulleted for clarity. Each sentence contributes value without 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 10 parameters and no annotations, the description covers all parameters and provides a list of allowed metrics. The existence of an output schema reduces the need to describe return values. Minor omissions like default pagination behavior prevent a perfect score.

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 0% schema description coverage, the description fully compensates by explaining each parameter: metric, start_date, end_date, users, page, page_size, include, repo, pr_number, dry_run. It provides allowed values, formats, and conditions (e.g., 'include is required for conversation-insights'). This adds significant meaning beyond the raw 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 fetches a team analytics metric with a specific endpoint (GET /analytics/team/{metric}) and lists all allowed metrics. The verb 'Fetch' and the resource 'team analytics metric' are specific and distinct from sibling tools, which focus on agents, members, and other non-analytics 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 explains parameters but does not explicitly state when to use this tool versus other analytics-related siblings like get_analytics_by_user or get_daily_usage_data. The context is implied by the metric list, but no direct guidance on alternatives is provided.

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

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

Without annotations, the description must disclose behavioral traits. It indicates 'query only' and the HTTP method, but does not mention rate limits, pagination behavior beyond defaults, or potential errors. This is insufficient for a tool with no 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 concise with a one-line summary followed by a parameter list. It is front-loaded and efficiently uses space, though the parameter list partially duplicates schema 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?

With an output schema present, the description does not need to explain return values. It covers the parameters adequately and indicates filtering. However, missing usage guidance and behavioral details make it incomplete for a 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?

Since schema coverage is 0%, the description provides meaningful context for all 5 parameters: explains start/end date as epoch ms, users as comma-separated emails/IDs, page as 1-indexed, and page_size with defaults. This adds significant value beyond the schema's type-only definitions.

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 'Fetch' and the resource 'usage events', and specifies filtering capability with the POST endpoint. However, it does not differentiate from sibling tools like get_agent_usage or get_daily_usage_data, which are related but distinct.

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 (e.g., get_agent_usage, get_daily_usage_data). The 'query only' note implies read-only but does not offer usage context or 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?

No annotations are provided, so the description must disclose behavioral traits. It only states it uses GET and requires an agent_id, but does not mention pagination, permission requirements, rate limits, or what fields are returned. For a read operation, this is insufficient.

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

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

The description is extremely concise, with no wasted words. It front-loads the purpose and includes the endpoint and parameter example. Every sentence is necessary.

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 that an output schema exists, the description does not need to detail return values. However, the description is minimal and does not note that it returns a list (though implied by 'List'), nor does it mention pagination or limits. With many sibling tools, slightly more context would help. It is adequate but not thorough.

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 adds 'for example bc-...' which gives a hint about the format, but does not explain where to find the agent_id or its constraints. This adds some meaning beyond the schema, but not enough for full 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 'List artifacts produced by a Cloud Agent', which is a specific verb and resource. It also provides the HTTP endpoint for additional clarity. Among siblings, this tool is distinct from 'download_agent_artifact' which downloads a specific artifact.

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

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

The description gives context by showing the HTTP method and an example agent_id, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any conditions or exclusions. Usage is implied but not guided.

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?

Reveals ordering and pagination mechanism but does not state that the operation is read-only or disclose any side effects, auth requirements, or rate limits. Without annotations, the description provides moderate transparency but lacks completeness.

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?

Extremely concise: one sentence plus a clear bulleted argument list. Every sentence adds value with no 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?

Covers core functionality and parameter details. With an output schema present, return value explanation is not needed. Minor omission: no mention of scoping (e.g., runs for a specific agent only is clear from agent_id). Adequate for a list operation.

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

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

Adds significant meaning beyond the schema: explains agent_id with example, limit with valid range, and cursor origin. Schema has 0% description coverage, so the description fully compensates and clarifies each parameter's role.

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 lists runs for a Cloud Agent with explicit ordering (newest first) and provides the REST endpoint. It distinguishes itself from sibling tools like get_agent_run (single run) and create_agent_run (create).

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

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

No guidance on when to use this tool vs alternatives (e.g., get_agent_run, stream_agent_run) or when not to use it. The description is purely functional without 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?

Without annotations, the description covers key behaviors: it indicates a GET request (read-only), pagination parameters (limit, cursor), and filtering options (pr_url, include_archived). However, it does not explicitly state it's a safe read operation or address authentication 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 extremely concise: a single-line summary followed by a clean bullet-style breakdown of parameters. Every sentence adds value with no redundancy or filler.

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

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

Given the output schema exists (defining return values), the description adequately covers pagination, filtering, and defaults. It could have mentioned rate limits or error handling, but it sufficiently enables an agent 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?

With 0% schema description coverage, the description fully compensates by explaining each parameter's meaning: limit (page size, range, default), cursor (pagination token), pr_url (optional filter), include_archived (default true). This adds critical context beyond the schema's type definitions.

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 'List Cloud Agents for the authenticated user' with the HTTP path, specifying the verb (list), resource (Cloud Agents), and scope (authenticated user). It distinguishes from siblings like get_agent (single agent) and list_team_members (different entity).

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. There is no mention of when not to use it or which scenarios favor other tools like get_agent or list_agent_runs.

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

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

The description discloses pagination behavior (1-based page, max 1000 results) and parameter constraints, which adds value. However, with no annotations, it does not explicitly state that the tool is read-only or list any side effects, leaving some uncertainty about safety.

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 concise and front-loaded with the tool's purpose and endpoint. The parameter list is clear though not bulleted; no unnecessary words. Slightly more structure (e.g., separating endpoint from args) would be optimal.

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 presence of an output schema, the description need not detail return values. It covers the essential inputs and pagination. Missing details like date inclusivity and sorting are minor gaps, but overall it is sufficient for a list endpoint.

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% (no property descriptions in schema), but the description explains each parameter's meaning and constraints (e.g., default values, max page size). This provides useful context beyond the schema's type and default fields.

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 lists 'accepted AI change metrics' and provides the exact HTTP GET endpoint. It effectively distinguishes from siblings like list_ai_code_commits and download_ai_code_changes_csv by specifying the resource and action.

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 parameter details but offers no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. Sibling tools like list_ai_code_commits suggest related functionality but no comparative direction is 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 discloses default values, date formats, pagination behavior, and user filter format, which is good. However, it does not explicitly state that the operation is read-only or mention rate limits.

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

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

The description is well-structured with bullet points and a clear header. It is concise but includes necessary details; could be slightly more succinct by removing redundant default info already in schema.

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 output schema exists, return value documentation is not needed. The description covers all parameters and provides useful context like max page size and default dates. Missing sorting or ordering details, but overall 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 coverage is 0%, so the description fully compensates by explaining each parameter's format, default, and constraints (e.g., ISO dates, user ID formats, page size max). This adds significant meaning beyond the schema.

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

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

The description clearly states the tool lists AI commit metrics with the specific HTTP method and path, distinguishing it from siblings like get_ai_code_commit_details and list_ai_code_changes.

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?

While it provides parameter details, it lacks explicit guidance on when to use this tool versus alternatives like get_ai_code_commit_details for single commits or download_ai_code_commits_csv for CSV export. Usage context is implied but not 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 indicates a read operation (GET) and describes the optional parameter. However, it does not disclose pagination, authentication requirements, rate limits, or behavior when no groups exist. The disclosure is minimal but not misleading.

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

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

The description is extremely concise: two sentences. The first states the purpose and endpoint, the second describes the parameter. No filler or redundant information; every word serves a 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?

Given that an output schema exists (not shown), the description need not detail return values. It covers the core functionality and parameter semantics. It lacks mentions of team context or authorization, but for a straightforward list tool, it is largely complete.

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

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

The input schema has 0% coverage (no description in schema), but the tool description adds valuable meaning: it specifies that billing_cycle is an optional ISO date (YYYY-MM-DD) with a default of the current cycle. This goes beyond the schema's 'string or null' type and title.

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 it lists billing groups for the team and includes the HTTP endpoint (GET /teams/groups), differentiating it from siblings like list_organization_groups (organization-level) and get_billing_group (single group). The verb 'list' and resource 'billing groups' are specific and 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 does not provide any guidance on when to use this tool versus alternatives. Sibling tools include list_organization_groups, get_billing_group, and create_billing_group, but no criteria for selection (e.g., team vs. organization scope, listing vs. retrieving a single group) 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?

No annotations exist, and the description provides no behavioral details such as authentication requirements, rate limits, or side effects. It only states the HTTP method, which is minimal.

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 that efficiently conveys the tool's purpose and HTTP method. No unnecessary words.

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

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

For a parameter-less listing tool with an output schema, the description is adequate but lacks context about the output format or typical use cases. It could be more complete by hinting at how the data might be used.

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 zero parameters, the description does not need to add parameter details. Baseline score of 4 is appropriate as the schema is empty and the description offers no ambiguity.

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 the resource 'repos with Bugbot settings', which distinguishes it from the sibling tool 'list_repositories' by specifying a filter on Bugbot configuration.

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 'list_repositories'. The description does not clarify the intent or context for using this tool over others.

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 must convey behavioral traits. It mentions the HTTP method GET, implying idempotency and read-only nature, but does not explicitly state that no side effects occur. This is adequate but not exceptional.

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 immediately conveys the purpose. No redundant information is present.

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 no parameters and an output schema exists (not shown). The description is sufficient for an agent to understand the action, though it could optionally mention that models are for use in Cloud Agents runs. Still, it meets the needs for completeness.

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 tool has no parameters, so the baseline is 4. The description adds value by including the HTTP method and endpoint path, which provides API context beyond the schema. This justifies a score of 5.

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', the resource 'models', and the context 'for Cloud Agents'. It also provides the HTTP endpoint, distinguishing it from sibling tools like 'list_agents' which list agents.

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 does not provide guidance on when to use this tool versus alternatives. While the action is clear, there are no explicit when-not-to-use cases or comparisons with 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?

No annotations are provided, so the description must convey behavioral traits. It indicates a read operation (GET) and lists parameters, but does not explicitly state it is read-only, safe, or any authentication/rate limit details. It is minimally adequate for a simple list operation.

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

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

The description is extremely concise with a clear one-liner action followed by parameter definitions in a structured docstring format. Every sentence is necessary and no information is redundant.

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 has an output schema (not shown), the description does not need to detail the response. It covers the input parameters and endpoint adequately for a straightforward list operation. One might wish for a note on pagination behavior, but overall it is 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%, so the description adds value by explaining each parameter: group_id format (g_...), page default and indexing (1-indexed), and page_size default. This goes beyond the raw schema. However, it could still mention that page_size has a max or that the response is paginated.

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 'List members of an organization group' using a specific verb and resource, and includes the HTTP endpoint. It distinguishes itself from siblings like 'list_organization_members' and 'list_organization_groups' by focusing on group membership.

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 does not mention prerequisites, scenarios, or comparisons with related tools like 'list_organization_members' or 'add_organization_group_members'.

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 present, and the description only states the HTTP method and parameters. It does not disclose whether the operation is read-only, requires authentication, or has any side effects or rate limits.

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

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

The description is extremely concise with no wasted words. It front-loads the main action and follows a clear structure: action, HTTP path, then parameter definitions.

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 presence of an output schema, the description does not need to explain return values. It adequately covers pagination defaults. However, it lacks any note about potential empty results or error handling, but this is minor for a simple list tool.

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 adds clear meaning beyond the schema: '1-indexed page' specifies indexing convention, and 'Groups per page' defines the quantity. Both parameters are fully explained, compensating for the 0% 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 explicitly states the action 'List' and the resource 'organization groups', and provides the HTTP method and path for clarity. It clearly distinguishes from sibling list tools that operate on different entities.

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 such as list_organization_members or list_billing_groups. There is no mention of prerequisites or 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 must disclose behavior. It specifies the GET method and API key scope, and notes page_size cap of 200. It does not mention rate limits, side effects, or return format, but output schema covers return structure. Acceptable but not rich.

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

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

The description is extremely concise with only three sentences and a compact args list. Every sentence adds value, and the structure prioritizes key 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 presence of an output schema, the description does not need to detail return values. It covers basic usage and parameters, but lacks mention of ordering, filtering, or any other behavior. Adequate but not comprehensive.

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 description carries the burden. It explains page is 1-indexed with default 1, page_size capped at 200 with default 50. This adds meaningful context beyond the schema's default values.

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 lists organization members and provides the HTTP endpoint. However, it does not differentiate from sibling tools like list_organization_group_members, which could cause confusion.

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 required API key scope (members:read or broader), giving context on when to use. It lacks explicit when-not-to-use or alternatives, but the scope hint is helpful.

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

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

The description mentions the HTTP method (GET) indicating a read operation, and details pagination via limit and page_token. However, it does not disclose authorization requirements beyond a brief note on repository-scoped keys, nor does it specify rate limits or response structure, which is important given the absence of annotations.

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

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

The description is very concise: one line for purpose and endpoint, followed by parameter details in a clear list format. No unnecessary words, all sentences add value.

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 presence of an output schema (not shown), the description adequately covers the tool's purpose and parameters. It does not explain return values, but the output schema likely handles that. Overall, it provides sufficient context for an agent to use the tool 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?

Despite 0% schema description coverage, the description provides meaningful explanations for all three parameters: limit (range and default), page_token (pagination cursor), and repository (optional but required for repo-scoped keys). This fully compensates for the missing schema descriptions.

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 'List unassigned pool requests' and includes the HTTP endpoint, which identifies the specific resource. It distinguishes from sibling list tools by specifying 'pending requests' as opposed to other resources like workers or agents.

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 does not provide any guidance on when to use this tool versus alternatives. It lacks context such as prerequisites, scope of results, or scenarios where other list tools would be more 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 discloses the authentication requirement and parameter meanings, but it does not mention side effects, rate limits, pagination behavior beyond the cursor, or the nature of the operation (read-only). The output schema exists, but behavioral traits beyond parameters are absent.

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

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

The description is extremely concise, with just three lines of explanatory text plus parameter bullets. Every sentence serves a purpose: the first line states the action and endpoint, the second line specifies authentication, and the bullet list defines parameters. No redundant information.

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

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

Given that the tool has only three optional parameters and an output schema, the description covers the input side well with parameter details and authentication. It does not describe the output format, but the output schema exists. For a simple list operation, this is sufficiently complete, though a note about idempotency or safety would improve it.

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

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

Schema description coverage is 0%, so the description must compensate. It provides meaningful details for all three parameters: status options (all, in_use, idle), limit range (1-100), and next_page_token as a pagination cursor. This adds significant value beyond the raw 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 'List self-hosted pool workers' and includes the HTTP endpoint, making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'get_private_worker' or 'list_pending_pool_requests', which could cause confusion.

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 the authentication requirement ('Requires the pool's service account API key'), which is helpful. However, it does not provide guidance on when to use this tool versus alternatives, nor does it explain when not to use it. The usage context is implied but not 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. It adds value by disclosing strict rate limits (1 request/user/minute, 30/user/hour) and potential slowness. It does not contradict annotations. Minor gap: does not explicitly state it's a read operation, which is implied.

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

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

Two concise sentences that front-load the action and then add critical context (rate limits, performance). No unnecessary words, every sentence earns its place.

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

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

Given that the tool has no parameters and an output schema exists (though not shown), the description provides rate limits and performance caveats, which are helpful. It is nearly complete for a simple list tool, though it could mention the output structure briefly.

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 tool has zero parameters and schema coverage is 100%, so no parameter documentation is needed. The description adds no parameter info, but that is acceptable. The baseline for no parameters is 4.

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 it lists GitHub repos accessible via Cursor's GitHub App, with the specific endpoint. It is a specific verb+resource combination and distinguishes from sibling tools like list_agents or list_models.

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

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

The description includes rate limits which imply cautious usage, but it does not explicitly state when to use this tool versus alternatives, or when not to use it. The usage context is implicit but not fully guided.

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 must carry the full burden. It only mentions the HTTP method (GET) and auth requirement, but fails to disclose whether the operation is read-only, any rate limits, pagination behavior, or error conditions. With minimal behavioral context, the score is low.

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

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

The description is extremely concise: two sentences covering purpose and auth. Every sentence earns its place, and the key 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?

Given the tool has no parameters and an output schema exists, the description is mostly complete. It covers the action and auth, but lacks details on pagination or result format. Still, it is adequate for a simple listing tool.

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?

There are zero parameters, and schema description coverage is 100% trivially. The rubric allows a baseline of 4 for 0-parameter tools. The description adds no parameter info, but none is needed.

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 'List team members' and provides the HTTP method and endpoint. It effectively distinguishes from sibling tools like 'remove_team_member' and 'list_organization_members' by specifying 'team' members.

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 the required authentication ('Team Admin API key'), giving a prerequisite. However, it does not provide guidance on when to use this tool versus alternatives (e.g., 'list_organization_members' for org-level members), nor does it mention when not to use it.

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

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

With no annotations, the description should disclose behavioral traits. It only states it is a GET request to list blocklists, but does not mention any side effects, rate limits, or whether the list is full or paginated. The description adds minimal value beyond the name.

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

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

The description is a single, front-loaded sentence that includes the HTTP method and path. While it is concise, the path may be unnecessary implementation detail, but overall it is efficient and no extraneous content.

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

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

Despite an existing output schema (not shown), the description does not explain what a 'team repository blocklist' is or what the output contains. For a list tool, this is insufficient for the agent to fully understand the response structure or any implicit constraints.

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?

There are zero parameters and schema coverage is 100%, so the description does not need to add parameter information. It appropriately avoids redundancy, and baseline 4 applies as per guidelines.

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 the resource 'team repository blocklists', and includes the HTTP method and path for clarity. It is distinct from siblings like 'upsert_repo_blocklists' and 'delete_repo_blocklist'.

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. There is no mention of prerequisites, exclusions, or context such as if filtering or pagination is needed.

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 for behavioral disclosure. It only states that it removes members, implying a destructive operation, but does not disclose side effects, error conditions, or requirements (e.g., group must exist, user must be a member). The bare description lacks transparency.

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

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

The description is very short (two sentences plus URL and args). It is efficient and front-loaded with the action. However, it could be slightly expanded 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 the tool's simplicity (2 params, output schema exists), the description covers the basic action and parameters. However, it lacks completeness in terms of prerequisites, failure modes, or behavior on invalid input. It is adequate but not fully comprehensive.

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 provides the only parameter documentation. It adds brief meaning: "Billing group id" and "JSON array of encoded user ids". However, these remain vague (e.g., no format for id, no example of JSON). It adds some value but not substantial.

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 "Remove" and the resource "members from a billing group", with the HTTP method and path for reference. It distinguishes from siblings like add_billing_group_members, but lacks explicit differentiation from remove_organization_group_members.

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. There is no mention of prerequisites, context, or when not to use it. The description only states the action without contextual usage advice.

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 provided, so description carries burden. It discloses HTTP method (POST), bulk operation, and max 100 users per request. This adds meaningful behavioral context beyond the tool name.

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?

Extremely concise: two sentences plus a structured argument list. No redundant words. Every sentence adds value.

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 an output schema exists, the description need not explain return values. It covers the HTTP method, parameter formats, and limits. Could mention idempotency or error handling, but overall adequate.

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

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

Schema coverage is 0%, but the description compensates fully: it explains group_id format (g_...) and clarifies user_ids_json as a JSON array with a max limit. This adds significant meaning beyond the schema's type info.

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 ('Remove members') and the resource ('from an org group'). It distinguishes from sibling tools like add_organization_group_members and list_organization_group_members.

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

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

No guidance on when to use this tool versus alternatives (e.g., when to remove vs. leave?). Implied usage only. No exclusions or prerequisites 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?

No annotations are provided, so the description carries the full burden. It identifies the action as removal (destructive), but does not disclose permissions, reversibility, side effects, or error handling. For a potentially destructive action, more behavioral context is needed.

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

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

The description is extremely concise, front-loading the main purpose and HTTP endpoint, followed by clear parameter guidance. Every sentence is necessary, with no extraneous words.

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