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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description does not contradict them. It adds a small behavioral hint by naming the return content ('status and result'), but does not disclose error handling, not-found behavior, or access requirements.

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

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

A single, front-loaded sentence with no filler. Every phrase adds information: action, scope, and return 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?

For a low-complexity read-only fetch with two self-descriptive parameters and strong annotations, the description is nearly sufficient: it names the action, the scope, and key return fields. It would be more complete with an explicit pointer to list_builds for multi-build retrieval, but this is not a blocking gap.

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

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

Schema description coverage is 0% and the description does not explain the 'project' or 'buildId' parameters. While the names are suggestive, the description does not specify the format of 'project' or the relationship between buildId and build/run, leaving the description unable to compensate 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?

States a specific verb ('Fetch'), a precise resource ('a single build/run'), and the data of interest ('status and result'). This clearly distinguishes it from the sibling list_builds, which would return multiple builds.

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 about when to choose this tool over list_builds or other siblings. There are no explicit conditions, exclusions, or alternative scenarios.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds minimal behavioral context beyond that—it does not address not-found behavior, response shape, or authentication requirements, though these are less critical given the strong annotation coverage.

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

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

The description is a single, front-loaded sentence that conveys the essential verb, resource, and scope with no filler or redundant restatement of the title. Every word contributes to the meaning.

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 read-only getter with one fully documented parameter and comprehensive safety annotations, the description is nearly complete. It does not describe the return payload or how name versus id is resolved, but the tool name and sibling context make the intended use reasonably clear.

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 description coverage is 100%, and the only parameter 'project' is clearly documented as 'Project name or id'. The description adds no additional parameter-level semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the specific action 'Fetch' and the resource 'details of a single project', which distinguishes it from list_projects and other list-based siblings. The word 'single' narrows the scope to a targeted retrieval rather than enumeration.

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

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

The description implies the tool is used when a single project's details are needed and the project can be identified by name or id, but it does not explicitly contrast with list_projects or other alternatives. There is no when-not-to-use guidance, so the agent must infer the appropriate context from the sibling tool names.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral details beyond the operation itself, such as error handling, authentication, or what happens if the PR is not found. No contradiction with annotations.

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

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

The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core operation.

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 fetch with rich annotations, the description is minimally viable, but it omits parameter semantics and any usage relationship to list_pull_requests. With no output schema, the agent gets little context about the return shape or error 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?

Input schema has 0% description coverage and the description gives no explanation of project, repo, or id. It doesn't compensate for the schema gap, though the parameter names are somewhat self-explanatory. An agent still must infer that id is the pull request number and how repo/project are formatted.

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

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

The description uses the verb 'Fetch' and the resource 'a single pull request', clearly stating the operation and scope. It distinguishes itself from the sibling list_pull_requests by emphasizing 'single'.

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

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

The phrase 'a single pull request' implies this is for retrieving one specific PR rather than listing all, but it never explicitly names alternatives or states conditions (e.g., use when you have the PR ID, use list_pull_requests to find it first). No exclusions or sibling 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?

The annotations already communicate that the operation is read-only, idempotent, and non-destructive, so the description adds no significant behavioral context beyond those annotations. It does not describe error/not-found behavior, field subset details, or access considerations.

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

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

The description is a single, front-loaded sentence with no filler. It effectively states the operation and result without repeating the title or the 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?

For a simple single-parameter read-only tool with rich annotations, the description is largely complete. Because there is no output schema, slightly more specificity about which fields are returned would make it fully self-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?

The input schema already fully documents the single id parameter with its type, requirement, and description. Schema description coverage is 100%, so the description does not need to add param semantics, and it does not go 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 specifies a clear verb ('Fetch') and resource ('single work item'), and notes that it returns the item's fields. This distinguishes it from the plural listing tools, but it does not explicitly call out the sibling relationship with query_work_items.

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

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

The singular wording and required 'id' imply this is for retrieving a known work item directly rather than searching. However, the description never explicitly says when to use this tool instead of query_work_items or other list tools, and it provides no exclusion 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the operational safety profile. The description adds only the clarification that branches are heads, but provides no additional behavioral context such as result format, ordering, or authentication needs. The annotations carry most of the burden, so a baseline score is appropriate.

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

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

A single, front-loaded sentence conveys the core action and scope with no wasted words. Every element earns its place.

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

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

The tool is simple and the annotations cover safety, but the description lacks usage guidance, output format details, and clarity on the 'project' parameter. It is adequate for a basic read-only list operation yet has clear 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 50%, with only 'repo' described in the schema and 'project' left undocumented. The description adds no parameter-level meaning and does not compensate for the missing 'project' explanation, leaving an agent to guess its 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 uses a specific verb ('List') and resource ('branches (heads) of a repository'), making the tool's function immediately clear. It also distinguishes itself from sibling tools like list_repositories and list_pull_requests by naming the exact resource being operated on.

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 no guidance on when to use this tool versus alternatives such as list_repositories or list_pull_requests. Usage context is only implied by the resource name, with no exclusions or conditions 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?

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint. The description adds the 'most recent first' ordering and 'recent' scoping, but does not go beyond that with details like pagination, limits, or response structure.

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

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

A single sentence with no filler, front-loading the core purpose and then adding the ordering detail. Every word contributes useful 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 simple two-parameter schema, read-only annotations, and absence of an output schema, this description is mostly sufficient. The only notable gap is the lack of explicit detail about what 'recent' means and how 'top' shapes the result set, but the schema partially covers 'top'.

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 50%, so the description partially compensates by clarifying that the project scope is via a project. It does not explicitly explain that 'top' controls the number of results, though 'recent' and 'most recent first' hint at 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 names a specific action ('List'), a clear resource ('recent builds/runs'), and a scope ('in a project'), plus the ordering ('most recent first'). This makes it easy to distinguish from single-item tools like get_build and from pipeline-definition tools like list_pipelines.

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

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

It conveys a clear context: use this when you need recent build/run history for a project. It does not explicitly name alternatives or exclusions, but the intended situation is obvious from the phrasing.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no new behavioral context such as authentication requirements, scope limitations, or output behavior beyond what annotations 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 a single short sentence with no filler or repetition. It front-loads the core action and resource immediately, making it easy for an agent to parse quickly.

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

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

For a simple list tool this is minimally adequate: the return kind is named (iterations/sprints) and annotations cover safety. However, with no output schema and no parameter-level detail, important context about the required project and team parameters is left to the schema alone.

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 for undocumented parameters. It only hints at 'a team's' for the team parameter and says nothing about the required project parameter, its role, accepted formats, or how team and project relate.

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

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

The description states a specific verb and resource: 'List a team's iterations / sprints.' This clearly identifies the tool's function and distinguishes it from sibling tools like list_teams or list_processes by naming the exact resource type.

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 that the tool is for retrieving iterations/sprints for a team, but it gives no explicit guidance on when to prefer this tool over alternatives such as list_processes or query_work_items. There are no exclusions or alternative routing 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?

Annotations already declare the tool read-only, idempotent, and non-destructive, so the description does not need to cover safety. It adds only the project scoping context, but does not disclose behaviors like pagination, ordering, or output shape. This is adequate given the 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 a single, front-loaded sentence with no filler or redundancy. Every word contributes to defining the operation and scope.

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 one-parameter list tool with annotations covering the safety profile, the description is sufficient to invoke it correctly. It lacks details about return format or pagination, but given the tool's simplicity and clear resource name, this is a minor gap.

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

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

The schema has one required 'project' string with no description (0% coverage). The description partially compensates by clarifying that pipelines are listed within a project, but it does not specify whether the value should be an ID, name, path, or other format. The added meaning is minimal but present.

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

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

The description uses a specific verb and resource ('List pipelines') and scopes it to a project, which clearly distinguishes it from sibling list_* tools that target other resources such as projects, teams, processes, and builds. An agent can tell exactly what this tool does at a glance.

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: if you need to list pipelines in a project, this is the tool. However, it does not explicitly state when to prefer this over alternatives or mention any exclusions, leaving usage guidance implicit rather than explicit.

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

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

Annotations already convey that this is read-only, idempotent, non-destructive, and open-world. The description adds the template categories but no additional behavioral context such as pagination, authentication, or return shape, so it stays at the baseline for annotation-covered tools.

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

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

A single, well-structured sentence that front-loads the verb and resource, then adds clarifying examples. Every word earns its place.

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

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

For a parameterless list tool with strong safety annotations and a clear resource scope, the description is complete. An agent can correctly invoke it and understand what it returns without additional 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?

The tool has zero parameters, and the schema confirms this with an empty properties object. With no parameters to document, the description sufficiently conveys that the tool takes no input.

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?

States a specific verb and resource: list organization process templates. The parenthetical examples (Agile, Scrum, CMMI, inherited) clarify the scope and help distinguish it from sibling tools like list_projects and list_teams.

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 makes the tool's context clear: use it when you need organization process templates. It does not explicitly name alternatives or exclusions, but the resource is distinct enough from the listed siblings that an agent can infer when to use it.

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

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

Annotations already establish that the tool is read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by revealing that results are filtered by an allowlist, which helps set expectations that not all organization projects may be returned. This is useful information beyond the structured annotations.

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

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

The description is a single, front-loaded sentence that communicates the resource, scope, and filtering behavior with no wasted words. It is immediately understandable and appropriately sized for a simple parameterless tool.

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

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

For a zero-parameter, read-only list operation with no output schema, the description covers the essential information an agent needs: what is listed, at what scope, and that filtering applies. No critical invocation details are missing.

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 takes zero parameters, and schema coverage is 100%, so there is no parameter gap for the description to fill. The description's mention of organization scope and allowlist filtering adds context but is not required for parameter semantics.

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

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

States a specific verb and resource: 'List projects in the organization', with a clear scoping qualifier '(filtered by the allowlist)'. It is distinct from the sibling get_project (list vs. single) and from other list_* tools by naming the resource directly.

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 makes the basic context clear: it lists organization projects, filtered by an allowlist. However, it does not explicitly discuss when to choose this tool over alternatives such as get_project or mention any exclusions, leaving the choice mostly to inference 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the repository scoping and status filtering, but it doesn't mention default status behavior, ordering, pagination, or any other runtime details. This is acceptable given the annotations reduce the burden, but the description still adds only modest behavioral context.

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

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

The description is a single, tightly written sentence with no filler. It front-loads the core action and adds the key modifier 'by status' without extra words. This is appropriately concise for such a simple list operation.

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 straightforward read-only list operation with rich annotations and a small schema, the description is mostly complete. The presence of required project/repo parameters and the status enum in the schema fills the gaps left by the terse description. No return shape is given, but for a list operation that is reasonably inferable and the annotations already indicate a non-destructive read.

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

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

Schema description coverage is only 33%, with status being the only described parameter. The description reinforces 'repository' and 'by status', but it does nothing to clarify the project parameter, which is required and undocumented in the schema. With low schema coverage, the description needed to compensate more than it does.

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 and resource: list pull requests in a repository. The phrase 'by status' adds a specific filtering dimension, and the tool is easily distinguished from sibling get_pull_request because it handles multiple pull requests rather than a single one. It does not explicitly contrast itself with sibling tools, but the resource and plural form are clear enough.

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 no guidance about when to use this tool versus alternatives. It doesn't mention that get_pull_request should be used for a single pull request, or that other list tools serve different resource types. The intended usage is implied by the name and schema, but no explicit direction 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the project-scoping behavior ('in a project'), which is useful but not a deep behavioral disclosure; it does not mention pagination, completeness, authentication, or return format.

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

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

The description is one efficient sentence with no fluff or redundancy. It front-loads the verb and resource, and every word adds meaning beyond the title.

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, read-only, one-parameter listing tool, the description plus annotations provide a minimally viable understanding. The main missing pieces are parameter format details and return value shape, which are not required for safety but would help an agent invoke it correctly without additional inference.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented 'project' parameter. The description only clarifies that project is the container scope, but does not specify whether the value should be an ID, name, slug, or provide examples. This leaves a meaningful gap for correct invocation.

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

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

The description uses a specific verb ('List'), a specific resource ('Git repositories'), and a scoping qualifier ('in a project'). This clearly distinguishes it from sibling tools like list_projects, list_branches, and list_pull_requests, so the agent knows exactly what resource is targeted.

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

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

The description implies the tool is for listing Git repositories within a project, which gives clear context. However, it does not explicitly state when not to use it or name alternatives, so an agent must infer the appropriate selection from the resource type rather than being directly routed among the many list_* 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to repeat safety behavior. However, it adds no extra behavioral context such as pagination, returned member fields, or whether membership is recursive.

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

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

The description is a single, front-loaded sentence with no filler or repetition. Every word contributes to the core meaning.

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 no-output-schema tool with two required parameters, the description is too thin: it doesn't state what a member record looks like, that team lookup is scoped by project, or the relationship to list_teams. An agent has enough to know the resource but not enough to reliably identify inputs and interpret results.

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

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

Schema description coverage is only 50%; the 'team' parameter is documented as 'Team id or name' but the required 'project' parameter has no schema description. The tool description says 'members of a team' but never explains how the project parameter scopes the team, so it fails to compensate for the gap.

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 names a specific verb ('List') and resource ('members of a team'), so an agent can tell this apart from sibling list_teams or list_projects at a glance. It doesn't explicitly contrast with any sibling, so it doesn't reach the top of the scale.

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?

There is no guidance on when to choose this over list_teams or how to obtain the required team/project values. Nothing is said about prerequisites or exclusions, so an agent must infer the usage context from the tool 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?

The annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint), but the description adds no behavioral context beyond the basic list action. There is no mention of pagination, ordering, return format, or scope details beyond what the parameter schema already 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 a single, clear, front-loaded sentence with no filler. It conveys the essential operation and scope efficiently.

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, read-only, single-parameter list operation, the description is mostly complete. It lacks explicit return-value details, but there is no output schema and the expected resource is clearly stated.

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

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

Schema description coverage is 100%, and the 'project' parameter is already described as 'Project name or id'. The tool description does not add any additional meaning about this parameter, so the baseline score applies.

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

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

The description clearly states the operation ('List') and the resource ('teams'), with a project scope. It is distinguishable from sibling tools like list_projects and list_team_members, though it does not explicitly contrast itself with them.

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

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

The description implies this tool is for listing teams within a specific project, which is enough context for a straightforward read operation. However, it does not provide explicit guidance on when to prefer this over sibling list tools or any exclusions.

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

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

Annotations already cover readOnly, idempotent, open-world, and non-destructive behavior, so the safety profile is established. The description adds that only matching work item IDs are returned, but it does not disclose potential edge cases such as pagination, query limits, or project scoping behavior. No contradiction with 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 two sentences with no filler. The first sentence front-loads the core action and result, and the example concretely illustrates the query format without adding unnecessary 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?

For a simple read-only query tool with annotations covering safety, the description is mostly complete: it states inputs, gives an example, and declares the return value (work item IDs). The main gap is the undocumented 'project' parameter, but the tool is otherwise adequately specified.

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 documents 'wiql' as 'A WIQL query string' but gives no description for 'project'. The description contributes a concrete WIQL example, which clarifies wiql syntax, but it says nothing about the required project parameter's meaning or format. Half of the parameter space remains under-explained.

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

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

The description states a specific verb and resource: 'Run a WIQL query and return matching work item ids.' The WIQL reference and example make the tool's purpose clear and distinct from get_work_item and the list_* siblings. It does not explicitly name or contrast a sibling, so it stops short of full differentiation.

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

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

The WIQL example implies this tool is for ad-hoc work item queries, but there is no explicit when-to-use guidance or mention of alternatives. An agent is left to infer that it should use this instead of get_work_item when needing to filter by criteria rather than fetch one item.

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