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

With no annotations provided, the description carries the full burden. It discloses the important behavioral trait that this uses a 'two-step process (movement request + commit)', hinting at workflow complexity. However, it lacks other critical behavioral details such as whether the operation is idempotent, what happens on invalid state transitions, or permission requirements.

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

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

The description is a single, efficient sentence that front-loads the primary action ('Changes the state') and appends the critical behavioral context (two-step process). Every clause earns its place with zero 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 the simple schema (3 primitive parameters) and lack of output schema, the description adequately covers the core function. However, for a state transition tool with no annotations, it should ideally clarify whether the tool handles both steps of the mentioned process automatically or if additional user/agent action is required, and reference valid state discovery.

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

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

The input schema has 100% description coverage, documenting all three parameters (dbid, application, targetState) including cross-references to other tools for the dbid field. The description adds no specific parameter semantics beyond what the schema provides, meeting the baseline expectation for high-coverage schemas.

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 identifies the action ('Changes the state'), the resource ('work item in Plan'), and the specific mechanism ('two-step process'). However, it does not explicitly differentiate from the sibling 'update_work_item' tool, which could also potentially modify work item properties.

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 mentions the internal two-step process, the description provides no guidance on when to use this tool versus 'update_work_item', nor does it mention prerequisite steps like calling 'get_available_states' to validate the targetState parameter (which accepts free-text strings with no enum 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?

With no annotations provided, the description carries the full burden. It successfully discloses the 'atomic operation' nature of project association and the upsert behavior, but fails to clarify safety aspects (destructive potential of updates) or resolve the confusion around projectID's required status.

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

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

Three tightly written sentences with zero waste. Information is front-loaded with the primary purpose, followed immediately by conditional logic for the two main parameters (releaseDbid and projectID).

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?

While the description adequately covers the dual operation modes, the discrepancy regarding projectID's requirement status (description implies optional, schema requires) creates a significant gap. Without an output schema, the description also omits what the tool returns on success/failure.

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 100%, establishing a baseline of 3. The description adds valuable semantics for releaseDbid (explaining it acts as a mode toggle between create/update) but subtracts clarity for projectID by implying it is optional when the schema requires it, resulting in a neutral net score.

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

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

The description clearly states the dual purpose with specific verbs ('Creates... or updates') and resource ('release in Plan'), distinguishing it from siblings like create_or_update_sprint by explicitly naming the 'release' resource.

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 clearly explains the conditional logic for create vs update modes based on releaseDbid presence. However, it misleadingly implies projectID is optional ('If projectID is provided') when the schema marks it as required, and does not mention when to use this tool versus alternatives like get_releases.

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 full burden. Adds valuable context about 'atomic operation' for project assignment and the conditional create/update logic. However, missing safety profile (destructive potential), error handling, and whether updates are partial or full replacement.

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

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

Three sentences with zero waste. Front-loaded with primary purpose, followed by conditional logic, then secondary atomic behavior. 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?

For a 6-parameter upsert tool with no output schema, the description adequately covers the core functional contract and upsert semantics. Could be improved by describing the return value or success confirmation since no output schema exists, but the behavioral explanation is sufficient for invocation.

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

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

Schema coverage is 100% (baseline 3). Description adds crucial semantic context: name is 'required for creation, optional for update', projectID is 'optional but recommended', and sprintDbid presence determines the operation mode. These conditional requirements are not evident from schema alone.

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 specific verbs (create/update) and resource (sprint in Plan). Clearly distinguishes from read-only sibling get_sprints and from work_item related tools. The upsert pattern is immediately clear.

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 conditional logic for when to use update mode (sprintDbid provided) vs create mode (omitted). Explains atomic project association behavior. Lacks explicit comparison to sibling create_or_update_release or warning against using for work items.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure but only states that it 'Creates' a work item. It fails to mention idempotency concerns, what constitutes success, whether the created item ID is returned (critical given no output schema exists), or required permissions.

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 consists of a single efficient sentence with no redundant or wasteful language. However, it is overly terse given the tool's complexity, sacrificing necessary behavioral and usage context for brevity.

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

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

For a mutation tool with 6 parameters and no output schema or annotations, the description is insufficient. It omits critical context such as error handling (e.g., duplicate titles), the relationship between 'application' and 'projectName' parameters, and whether the operation is atomic.

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

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

The input schema has 100% description coverage, adequately documenting all 6 parameters including optional vs. required status. The description adds no parameter-specific guidance (e.g., valid formats for 'workItemType'), but with complete schema coverage, it meets the baseline expectation.

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 ('Creates') and resource ('work item') and identifies the target system ('in Plan'). However, it does not explicitly differentiate from similar mutation siblings like 'update_work_item' or distinguish when to create vs. modify existing 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 description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as using 'get_available_workitem_types' or 'get_available_projects' to populate required parameters correctly.

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 full burden. While 'Deletes' implies destruction, it fails to disclose whether deletion is permanent/irreversible, if it cascades to child items, or required permissions. Lacks critical safety context for a destructive 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?

Extremely brief (4 words) and front-loaded with the action. Efficient but arguably too terse given the destructive nature and absence of annotations; could accommodate one safety clause 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?

Inadequate for a destructive 2-parameter tool with no output schema. Description omits destructive confirmation, success/failure behavior, and whether the operation is recoverable. Schema covers inputs but description fails to cover behavioral outputs.

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 has 100% description coverage, documenting both dbid and application thoroughly. Description adds no parameter-specific context, but baseline 3 is appropriate when schema does the heavy lifting.

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

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

Clear verb ('Deletes') and resource ('work item'), though 'in Plan' is slightly ambiguous (product name vs. generic planning). Distinguishes from siblings by action type but doesn't clarify delete vs. update/change-state scenarios.

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 no guidance on when to use deletion versus alternatives like update_work_item or change_work_item_state. No mention of prerequisites (e.g., required work item states) or cascading effects on related entities.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Retrieves' implies a read-only operation, the description lacks critical details: pagination behavior for large result sets, return format (array vs object), authentication requirements, or rate limiting concerns. It does not compensate for the missing annotations.

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

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

The description is a single, efficient sentence with no redundant words. The core action and resource are front-loaded, making it immediately scannable.

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 (no parameters) and lack of output schema, the description provides minimal viable context. However, it omits what the tool returns (e.g., 'returns a list of applications') and whether the result set might be large. For a retrieval tool with no schema coverage burdens, this is adequate but incomplete.

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 contains zero parameters. Per evaluation rules, zero-parameter tools receive a baseline score of 4. The description implicitly confirms no filtering is possible by stating 'all applications', which aligns with the empty 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 (Retrieves), scope (all), and resource (applications) within the Plan system domain. It distinguishes from siblings like get_work_items and get_releases by targeting 'applications' specifically, though it assumes familiarity with what constitutes an 'application' in this 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?

No guidance provided on when to use this tool versus siblings like get_available_projects or get_available_components. Given the similar 'get_available_*' naming patterns in siblings, the description fails to clarify whether applications are user-specific, workspace-scoped, or how they relate to projects.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, the description does not confirm safety, idempotency, error conditions (e.g., invalid projectId), or pagination 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?

Single sentence, front-loaded, and efficiently structured without redundant words. However, extreme brevity comes at the cost of omitting necessary behavioral and domain context.

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

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

For a tool with no output schema and no annotations, the description is insufficient. It fails to define what 'components' represent in this domain (feature areas? modules?) or how they relate to work items, despite the presence of sibling work-item tools.

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

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

With 100% schema description coverage, the baseline is met. The description implies a hierarchical relationship ('project in Plan for given application') but does not add critical details like ID format, case sensitivity, or whether application names are human-readable or system identifiers.

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

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

The description uses a specific verb ('Get') and resource ('list of components'), but 'components' lacks domain definition and the description fails to distinguish this from sibling tools like get_available_projects or get_available_states. The phrase 'in Plan' assumes product knowledge without clarification.

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 (e.g., get_work_items), no prerequisites mentioned, and no exclusions provided. The agent must infer usage solely from the parameter requirements.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to indicate that this is a read-only operation, does not describe the return format (e.g., array of project names/IDs), and omits error handling behavior (e.g., what happens if the application doesn't exist).

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

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

The description is a single, efficient sentence of 11 words. It is front-loaded with the verb and contains no redundant or wasted text. Every word contributes to understanding the tool's function.

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

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

Given the low complexity (single string parameter, no nested objects) and complete schema coverage, the description is minimally adequate. However, without an output schema, the omission of return value description (e.g., whether it returns IDs, names, or objects) leaves a noticeable gap for an integration 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 100% schema description coverage, the input schema already fully documents the 'application' parameter. The description mentions 'for a given application' which aligns with but does not significantly extend the schema definition. This meets the baseline for high-coverage schemas.

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 identifies the action ('Get'), resource ('list of projects in Plan'), and scope ('for a given application'). It effectively distinguishes from sibling get_applications by specifying projects are retrieved within a specific application context, though the verb 'Get' is slightly generic compared to 'Retrieve' or '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?

The description provides no explicit guidance on when to use this tool versus siblings like get_applications or get_available_components. While the required 'application' parameter implies a prerequisite workflow step, there is no text describing the sequencing or 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what content is returned (transitions/actions matrix) but does not confirm this is read-only, safe, or idempotent, nor does it mention performance characteristics or caching. Adequate but missing safety confirmation.

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?

Single sentence with no waste. Information is front-loaded with the action ('Gets') and key resource ('state transition matrix') immediately stated. Every clause earns its place by clarifying scope or output 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 single parameter and lack of output schema, the description adequately explains the conceptual return value (matrix of transitions). However, given the absence of annotations, it should ideally confirm the read-only nature of the operation to be complete. Sufficient for a simple lookup tool 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 100%, establishing a baseline of 3. The description adds domain context ('Plan', 'work items') that helps situate the 'application' parameter, but does not add syntax details, examples, or constraints beyond what the schema already provides.

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 identifies the resource (state transition matrix for work items) and scope (in Plan for a given application). It distinguishes from sibling 'change_work_item_state' by specifying this retrieves/ shows available transitions rather than performing them. The verb 'Gets' is slightly weak but functional.

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 discovering valid state transitions, suggesting use before changing states, but does not explicitly state when to use it relative to 'change_work_item_state' or provide explicit prerequisites. Usage guidance is present but implied rather than prescriptive.

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 full burden. While 'Get' implies read-only safety, description doesn't confirm idempotency, error behavior (invalid projectId), caching, or return format. Silent on whether results vary by user permissions.

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?

Single sentence, front-loaded with action verb. No redundant text. Minor grammatical awkwardness ('in Plan' vs 'in the Plan' or 'Plan product') slightly impacts clarity, but generally efficient structure.

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?

Adequate for a 2-parameter lookup tool, but gaps remain: no output schema exists yet description doesn't characterize return values (e.g., list of type names/IDs), and without annotations, safety properties are implied rather than 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?

With 100% schema coverage, baseline is 3. Description maps parameters to their functional role ('for a given application', 'for a project') but adds no syntax details, format examples, or validation rules beyond what the schema already provides.

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 specific verb (Get) and resource (available workitem types) with clear scope (project in Plan for given application). Distinguishes from siblings like get_work_items (instances vs types) and get_available_states/components. Minor ambiguity around 'Plan' (product name vs generic noun) prevents a 5.

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 no guidance on when to use this versus alternatives (e.g., when to query types before creating work items with create_work_item). No prerequisites mentioned beyond implicit required parameters. No workflow context 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?

No annotations are provided, so the description carries full burden. It fails to disclose whether this is read-only, what the return format looks like, pagination behavior, or error conditions. The word 'Get' implies read access but provides no concrete behavioral guarantees.

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 zero redundancy. Every word earns its place: action (Get), object (list of releases), context (in Plan), and filter (for a given application).

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 retrieval tool with complete schema coverage, the description is minimally adequate. However, given the lack of output schema and annotations, it should disclose basic behavioral traits (read-only nature, return structure) to be complete.

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

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

Schema description coverage is 100%, establishing a baseline of 3. The description mentions 'for a given application', acknowledging the parameter's purpose, but adds no additional semantic context such as expected format, case sensitivity, or where to obtain valid application names.

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 specific verb 'Get' with clear resource 'releases' and scope 'in Plan for a given application'. It distinguishes the resource from siblings like get_sprints and get_work_items by specifying 'releases', though it doesn't explicitly contrast with create_or_update_release.

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 explicit when-to-use guidance, prerequisites, or alternative selections. It does not mention that get_applications might be needed first to obtain valid application names, nor does it clarify when to query releases versus sprints or work items.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, the description fails to specify error handling (what happens if the application is invalid), whether the results are paginated, or the structure/format of the returned sprint data.

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

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

The description is a single, efficient sentence of 10 words with the action verb front-loaded. There is no redundant or wasted language; every word contributes to defining the tool's 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?

Given the tool's low complexity (one required string parameter) and complete schema coverage, the description is minimally adequate. However, since no output schema exists, the description should ideally describe the return format (e.g., 'returns a list of sprint objects') or what constitutes a sprint in this context, which it omits.

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

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

With 100% schema description coverage for the single 'application' parameter, the schema already documents the input sufficiently. The description adds minimal semantic context by framing it as 'for a given application,' but does not provide examples, validation constraints, or format details beyond the schema.

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

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

The description clearly states the action ('Get the list'), resource ('sprints in Plan'), and scope ('for a given application'). The verb 'Get' implicitly distinguishes this from the sibling 'create_or_update_sprint', though it does not explicitly mention the sibling or clarify whether this retrieves active, closed, or all sprints.

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 use this tool versus alternatives like 'get_work_items' or 'get_releases', nor are there prerequisites mentioned (e.g., whether the application must exist or be accessible). The description assumes the user knows what 'Plan' refers to without 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 disclosure burden. While 'Retrieves' implies a read-only operation, there is no information about return format, pagination behavior, authentication requirements, or what happens when no items match the filters. The agent gets no behavioral context beyond the basic operation type.

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 and appropriately concise, but the omission of the required 'projectName' parameter suggests it may be too compressed. The information is front-loaded but incomplete regarding the full input requirements.

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

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

Given no output schema and no annotations, the description should provide more context. It fails to mention that both application and project are required identifiers (only mentions application), provides no return value documentation, and lacks error condition handling. For a 4-parameter retrieval tool with required scoping parameters, this is insufficient.

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

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

With 100% schema description coverage, the baseline is appropriately met. The description mentions filtering by 'work item type' and 'specific owner' which maps to the schema parameters. However, it completely omits mention of 'projectName' despite it being a required parameter alongside 'applicationName', which is a notable gap even with complete schema coverage.

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

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

The description clearly states the tool retrieves work items with specific filtering capabilities (by type and owner). It uses a specific verb ('Retrieves') and identifies the resource ('work items'). However, it doesn't explicitly distinguish this from sibling getters like 'get_available_workitem_types' or mention that both application AND project are required scopes.

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 use this tool versus alternatives like 'get_available_workitem_types' (for metadata) versus actual work items. No mention of prerequisites such as needing valid application/project names from sibling tools first, or when to use filtering versus retrieving all items.

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 full burden. Reveals critical business rule about Sprint/PlannedRelease ordering constraint not visible in schema structure. However, missing safety profile (idempotency, reversibility, validation behavior) and error scenarios (what happens if dbid invalid?).

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?

Second sentence 'Provide the fields you want to update with their new values' is redundant given schema's 'Array of fields to update' description. The Sprint/PlannedRelease constraint requires four sentences where two would suffice. Well front-loaded with main 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?

Addresses the most critical domain constraint (Sprint/Release ordering) preventing common usage errors. However, for a mutation tool with no annotations and no output schema, omits operational context such as success indicators, partial update behavior, or permission requirements.

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 has 100% description coverage (baseline 3). Description adds crucial semantic context that Sprint values must correspond to the PlannedRelease value, and provides concrete value format examples ('Sprint 1 - Planning & Foundation', 'Release 2') beyond schema's generic 'The new value' description.

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

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

Description opens with specific verb 'Updates' and resource 'fields of an existing work item', clearly distinguishing from sibling tools like create_work_item (creates new) and delete_work_item (removes). The scope is precisely defined as field-level updates rather than state transitions (change_work_item_state).

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 explicit prerequisite guidance: 'Always update PlannedRelease before updating Sprint field' and explains the dependency constraint ('you cannot assign a sprint... unless that work item is already part of the release'). Lacks explicit comparison to alternatives (e.g., 'use create_work_item for new items').

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