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 implies mutation via 'Add' but does not state whether duplicates are allowed, whether existing patterns are overwritten, or any validation or naming constraints.

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 unnecessary words. It front-loads the verb and resource, making it easy to scan.

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

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

The description is adequate for basic tool selection but lacks context about return behavior, error conditions, or how this tool relates to other pattern-related tools. Given the nested object schema and absence of annotations, a bit more guidance 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?

The input schema provides descriptions for both top-level parameters and all nested pattern fields, though the pattern parameter itself lacks a top-level description. The tool description adds no parameter-specific semantics beyond reinforcing the concept of a 'code pattern'.

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 ('Add'), the object ('a reusable code pattern'), and the destination ('project library'). It is specific enough to distinguish from sibling tools like list_patterns or get_top_patterns.

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, nor when not to use it. It doesn't mention that this is the create path for reusable patterns or whether it should be used before list_patterns or other retrieval 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 must disclose behavioral traits on its own. It only states that feedback is added without mentioning side effects, idempotency, whether existing feedback is overwritten, or any prerequisites like a valid taskId. Minimal behavioral detail.

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 concise sentence, front-loaded with the action 'Add', and contains no filler or redundant information. It is highly 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 tool is a simple add operation with a fully-described schema, the description is minimally adequate. However, it lacks usage guidelines and behavioral transparency, making it incomplete for an agent that has no annotations to rely on.

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%, so parameters are already fully described in the schema. The description adds no additional parameter-level meaning, which aligns with the baseline of 3.

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 function: 'Add feedback/learning from task execution' with a specific purpose 'to improve future recommendations'. The verb 'Add' and resource are specific, distinguishing it from other record_* tools like record_decision or record_code_change.

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 after task execution ('from task execution') but does not explicitly state when to use it over alternatives. It lacks guidance on when-not-to-use or comparisons to similar sibling tools, though the purpose is somewhat implied.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning permissions, side effects, idempotency, or whether this replaces existing guidelines. The mutating nature is implied by 'Add' but little else is disclosed.

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

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

The description is a single, front-loaded sentence that conveys the core purpose without wasted words. It's appropriately concise for a straightforward add 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?

Given the tool has no annotations, no output schema, and a nested parameter object, the description is too minimal to provide complete context. It doesn't explain what happens on duplicate guidelines, whether the operation is reversible, or any prerequisite conditions.

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 descriptions for projectId and nested guideline fields, but the description itself adds no parameter-level detail. With schema coverage at 50%, the description doesn't compensate by explaining the guideline structure or any constraints 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 uses a specific verb ('Add') and a clear resource ('project guideline or coding standard'), making it distinct from sibling tools like add_code_pattern or add_feedback. It's unambiguous about the tool's primary function.

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 are no exclusions, prerequisites, or references to other tools for similar 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?

With no annotations, the description is solely responsible for behavioral disclosure. It only states the action without revealing side effects, idempotency, validation, return value, or error behavior, so the agent remains blind to important operational 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?

The description is a single, efficient sentence that front-loads the action and resource. It wastes no words, but it does sacrifice depth 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?

The tool involves a nested object with several fields and no output schema, yet the description provides no context about the required configuration structure or behavior. It is too sparse to fully support correct 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 schema covers only 50% of parameters (projectId is described, but the 'tool' object has no description). The description's phrase 'MCP tool configuration' adds little meaning beyond the schema, and it does not compensate for the undocumented nested object structure.

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 clear action verb 'Add' and identifies the resource ('an MCP tool configuration') and destination ('to the project'). It distinguishes from the sibling tool 'update_mcp_tool' through the add/update contrast, although it does not explicitly call out that 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?

The description provides no guidance on when to use this tool versus alternatives like update_mcp_tool or other configuration tools. It lacks any mention of scenarios, prerequisites, or exclusions, leaving the agent 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?

There are no annotations, so the description must cover behavioral traits. It only states the basic action without disclosing side effects, overwrite behavior, idempotency, or any permission/configuration requirements. This is insufficient for a mutating 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 sentence and front-loaded, containing no fluff. It is appropriately concise for the simple action, though it sacrifices depth 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?

Given the nested object parameter, lack of annotations, and no output schema, this sparse description leaves significant unknowns. There is no mention of how the sub-agent integrates with existing configuration, error conditions, or relationship to sibling tools like 'initialize_project_configuration'.

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 schema description coverage at 50%, the description should compensate, but it adds no meaningful parameter detail. The reference to 'guardian' is slightly misleading given the schema's flexible 'agentType'. The nested 'subAgent' object's properties are documented in the schema, but the tool description provides no additional context.

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 ('Add'), the resource ('sub-agent'), and the context ('project configuration'). It distinguishes from the sibling 'update_sub_agent' by using 'add' vs 'update'. However, the parenthetical '(guardian)' incorrectly narrows the scope since the schema allows various agent types.

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 like 'update_sub_agent' or 'add_mcp_tool'. It also fails to mention prerequisites such as project configuration initialization or that a project ID must exist.

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 of disclosing behavior, but it only states the action. It does not mention whether adding a tech stack entry overwrites existing entries, whether the project must already exist, or any validation/error behavior. This is a significant transparency gap.

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

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

The description is a single, direct sentence that is front-loaded with the action and object. Every word is meaningful, and there is no redundancy or filler. It is appropriately concise for a straightforward add 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?

Given the nested parameter object, lack of annotations, and absence of an output schema, the description is too minimal. It does not explain return values, side effects, prerequisites, or how it relates to sibling tools like update_tech_stack and get_project_configuration. This leaves important gaps for an agent to safely invoke the 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 schema provides descriptions for projectId and the nested properties of techStack, but the techStack parameter itself lacks a description. The tool description loosely refers to it as a 'technology stack entry' but adds little structural or semantic detail beyond what the schema already offers. With 50% top-level coverage, the description only partially compensates.

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 ('Add') and identifies the resource ('technology stack entry') and target ('project configuration'), making the tool's function clear. However, it does not differentiate from sibling tools like update_tech_stack or remove_tech_stack, so it falls short of 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?

The description provides no guidance on when to use this tool versus alternatives. It simply states the action without any context, prerequisites, or exclusions, leaving 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?

With no annotations provided, the description must carry the transparency burden. It conveys that the operation is a read-only check and provides immediate feedback, but it does not disclose error handling, output format, or any potential side effects, leaving some behaviors implicit.

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 short sentences, front-loaded with the main purpose, and contains no redundant or filler content. 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 simple one-parameter tool, the description covers purpose and usage context, but since there is no output schema, it does not explain what the risk assessment output looks like or how to interpret it. The description is adequate but leaves room for the agent to wonder what exactly will be returned.

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% and the parameter 'pattern' is clearly described as 'the pattern name to check for risk'. The description adds no additional parameter-level detail, so it meets the baseline without exceeding 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 the tool checks a specific pattern for failure history and provides a risk assessment. It uses a specific verb ('check') and resource ('pattern'), and the purpose is distinct from sibling tools like list_patterns or get_pattern_stats, which serve different 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 phrase 'before using it' gives clear temporal context for when to use this tool. However, it does not explicitly name alternatives or provide exclusion criteria, so it stops short of full usage 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals a notable behavior: the response automatically includes nextSteps workflow guidance and insists the agent follow it to ensure complete metadata. This is a critical behavioral trait beyond the schema. It could also mention validation or failure modes, but the key non-obvious behavior is disclosed.

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

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

The description is concise and well-structured: a single clear purpose sentence followed by a highlighted warning (⚠️) about the nextSteps field. No unnecessary words, front-loaded with the verb, and the warning is important enough to warrant emphasis. 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 tool with 8 parameters and no output schema, the description is fairly complete. It covers what the tool does, mentions the key fields, and importantly describes the output behavior (nextSteps guidance) which is critical for the agent to use effectively. The schema fully covers inputs, and the description adds the key output context. Some details like error handling or exact return format are missing, but given moderate complexity, this is 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 description coverage is 100%, so the schema already documents all 8 parameters. The description lists some parameter names (status, dependencies, assignee, priority, tags) but does not add meaning beyond the schema descriptions. For example, status enum values are repeated from schema, but no additional format, constraints, or cross-field dependencies are explained. Baseline 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 opens with 'Creates a new task' which is a specific verb+resource statement. It lists key fields (title, description, status, dependencies, assignee, priority, tags) and clearly distinguishes from sibling tools like update_task and delete_task by indicating creation rather than modification or deletion.

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 implies use for creating new tasks, which separates it from update/delete siblings. It also provides a strong usage guideline to always follow the nextSteps field for post-creation analysis. However, it does not explicitly state when not to use or name alternative tools for different 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?

No annotations are provided, so the description carries the full burden. It discloses key behaviors beyond the schema: dependency checking, prevention of deletion when dependencies exist, and automatic cache invalidation. This is substantial transparency for a delete operation, though it does not detail return values or error handling.

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 composed of three short, front-loaded sentences, each contributing specific information (action, dependency check, cache invalidation). There is no wasted wording, making it both concise and well-structured.

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 parameter, no output schema), the description covers the essential context: what it does, a critical safety behavior, and a side effect (cache invalidation). It does not mention return values or error scenarios, but those are arguably less critical for a basic delete tool with dependency safeguards.

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% (id has a description 'Task ID to delete'). The description adds no additional parameter meaning beyond what the schema already provides. Per the baseline rule, a score of 3 is appropriate when the 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?

The description uses a specific verb 'Deletes' with a clear resource 'task'. It distinguishes itself from siblings like safe_delete_tasks_by_status by noting it checks for dependent tasks and prevents deletion if dependencies exist, which is a unique behavior not present in other task-related 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 implies a usage context: use this tool for deleting a task when you need dependency safety. However, it does not explicitly state when to use this tool versus alternatives such as safe_delete_tasks_by_status. The dependency-check behavior provides context but no exclusions or explicit alternative recommendations.

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

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

With no annotations, the description carries the full burden. It discloses that deletion cascades to all sub-tasks, that it validates completed work and external dependencies, and that force bypasses the completed-work guard. This is valuable behavioral insight beyond the schema. Minor gap: the exact behavior for external dependencies (block vs warn) is not specified.

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, front-loaded with the primary action, followed by necessary conditions. No redundancy, every clause adds unique 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?

For a 2-parameter deletion tool with no output schema, the description covers the core behavior, side effects (cascading delete), safety checks, and parameter override. It could mention the outcome for external dependencies, but overall it's sufficiently 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?

Both parameters are already documented in the schema (100% coverage). The description adds meaning by explaining the force parameter's role in overriding completed-work checks, which the schema only describes as 'Force deletion even if there are completed sub-tasks'. It also contextualizes userStoryId as the parent story whose sub-tasks are deleted.

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 'Delete' and the resource 'user story', and specifies cascading deletion of sub-tasks. It distinguishes itself from sibling tools like delete_task (which targets individual tasks) and safe_delete_tasks_by_status (which deletes tasks by status).

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 context about when to use force=true (with completed sub-tasks), implying standard usage without force. It also indicates the tool performs dependency checks, signaling caution. However, it doesn't explicitly mention alternatives for deleting individual tasks, but the related tool names provide that 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 safety and side effects. It states that it 'automatically' detects and returns patterns, suggesting a read-only analysis, but it does not explicitly confirm the absence of side effects or mention data sources, failure conditions, or performance implications. This is moderately transparent but leaves gaps.

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, front-loaded with the core action, and then specifies the return value. Every sentence earns its place with no redundancy or filler.

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

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

The tool has no output schema, but the description explicitly states the return value: patterns sorted by failure rate with risk assessments and recommendations. For a simple tool with two well-documented optional parameters, this is mostly complete, though it could mention the expected input scope (e.g., task history) or any prerequists.

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%, with both minOccurrences and failureThreshold fully documented including defaults. The description adds no additional parameter semantics beyond 'high failure rates', so it does not exceed the baseline for well-covered 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 uses a specific verb ('detect') and resource ('patterns with high failure rates') with a clear purpose ('identify risky approaches'). It also describes the output format, distinguishing it from sibling tools like list_patterns or get_top_patterns by focusing on failure-related risk assessment.

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 when trying to identify risky approaches from pattern data, but it does not explicitly state when to use this tool versus alternatives such as get_pattern_stats or check_pattern_risk, nor when not to use it. The purpose is clear but guidance is implicit.

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 convey behavioral traits. It implies a read operation but does not disclose return format, ordering, pagination, or any side effects. Minimal behavioral information is provided.

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, clear sentence with no filler. It is front-loaded with the action verb and contains every word with 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?

For a simple getter with one parameter, the description is somewhat adequate, but it lacks any information about the returned data structure or edge cases. Given the absence of an output schema, more detail 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?

The schema describes taskId as 'Task ID', which is sufficient for a single parameter. The description adds the phrase 'for a task' linking taskId to the purpose, but no significant additional semantics 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 uses a specific verb 'Get' and identifies the resource 'code changes' scoped to 'a task'. It clearly conveys what the tool does, though it does not explicitly differentiate from sibling tools like get_task_history or record_code_change.

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 get_task_history or record_code_change. The description only states the action without contextualizing its appropriate use.

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 for disclosing behavior. It only says 'Get' without explicitly stating whether it is read-only, whether it has side effects, or what happens if the task doesn't exist. It lacks behavioral details beyond what the name suggests.

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

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

The description is a single concise sentence that is front-loaded with the action and resource. There is no redundancy or unnecessary detail, making it easy to parse.

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 one required parameter and no output schema. The description communicates the core functionality (retrieving decisions for a task) and the parameter is clear. However, it does not describe the return format, potential errors, or ordering, which are minor gaps for such a simple read-only 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 schema already fully documents the taskId parameter with 100% coverage. The description does not add any additional meaning about the parameter's format, constraints, or special behavior beyond what the schema provides, so it meets the baseline.

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 all decisions for a task, using a specific verb and resource. It is distinct from sibling tools that handle tasks, dependencies, or other entities, and the scope is 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?

The description implies usage when you need decisions for a task, but it does not explicitly mention alternatives or exclusion criteria. There is no guidance on when to use this tool instead of similar get_* tools, so it only provides implied 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 the full burden. It discloses algorithm behavior and edge cases (cycles return error with path, isolated tasks at end), but does not state the return format or whether parameters affect the calculation. This is useful but incomplete.

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 relevant information, but the second sentence redundantly restates what was said in the first ('topological execution order' and 'sorted by execution sequence'). Slightly more concise wording would improve 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 calculation tool, the description covers algorithm and edge cases, but it omits the success return format and does not integrate parameter usage. Since there is no output schema, more detail on what the tool returns would make it more 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 descriptions cover 100% of parameters, so the baseline is 3. The tool description adds no extra meaning to the 'status' or 'userStoryId' filters and does not explain how they interact with the dependency ordering, so it neither enhances nor detracts.

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 tool's function: calculating topological execution order for tasks based on dependencies, with a specific algorithm (Kahn's) and scope. It does not explicitly differentiate from sibling tools like get_task_dependency_graph, so it stops short of a perfect score.

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

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

Usage context is implied (use when you need execution order), but the description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. This is adequate but not fully 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 discloses that the response includes 'nextSteps for implementation' and instructs the agent to update task status, which adds behavioral context. However, it does not clarify whether the tool has side effects beyond returning a prompt, so transparency is moderate.

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: the first front-loads the purpose, the second adds important workflow and response-content context. Every sentence earns its place, and the ⚠️ warning highlights the crucial instruction about nextSteps. 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 single-parameter tool with no output schema, the description covers what the prompt will include (dependencies, risks, patterns, guidelines, nextSteps) and when to call it (after save_task_analysis). This is nearly complete, but it could be more explicit about the expected return format, leaving a slight 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 100% and the only parameter, taskId, is already described as 'Task ID to get execution prompt for'. The description adds no additional parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states 'Generates an enriched execution prompt with full context for implementing a task' – a specific verb (Generates) with a clear resource (execution prompt). It also lists what the prompt includes (dependencies, risks, patterns, guidelines), making the purpose concrete and distinct from generic prompt tools.

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

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

The description explicitly says 'Call this after save_task_analysis', providing a clear workflow sequence. It also implies the tool is meant for the implementation phase, but it does not explicitly state when not to use it or mention alternative tools, so it falls short of a 5.

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

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

With no annotations, the description carries full burden. It indicates a read operation, but does not disclose return format, ordering, pagination, or other behavioral aspects. It is minimally transparent but lacks depth for a getter.

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, direct sentence that is front-loaded with the action and object. It is concise with 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 one-parameter tool, the description states what it does, but without an output schema, it does not explain the return structure or what constitutes a guardian intervention. It is adequate but not 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 100% with taskId described as 'Task ID'. The description adds no extra meaning beyond the schema, so the baseline of 3 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 verb 'Get', the resource 'guardian interventions', and the scope 'for a task'. It is specific and distinguishes itself from the sibling tool 'record_guardian_intervention' by being the read counterpart.

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 usage guidance is provided, but the context of sibling tools strongly implies this is for reading interventions vs. recording them. The description does not state when to use this versus alternatives, so it remains at implied usage level.

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 bear the full burden of behavioral disclosure. It indicates a read operation ('Get') but does not specify the return format, error behavior, permissions, or any other operational details. This is 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?

The description is a single, direct sentence that states the tool's function without filler. It is appropriately concise, though it could benefit from more detail within the same sentence.

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 tool with one parameter and no output schema, this description provides the essential purpose, which is minimally adequate. However, it lacks context on expected output type, usage context, or alternatives, leaving it at the boundary of viable.

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 documents taskId with 100% coverage, so the description adds no extra parameter meaning beyond what is structured. The baseline of 3 applies because the schema covers all parameters.

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 gets the number of iterations for a task, using a specific verb and resource. It does not explicitly differentiate it from sibling get_* tools, but the resource is narrow enough to imply 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 is provided on when to use this tool versus other task-related getters like get_task_context or get_task_history. The description only states what it does, not when to prefer it or when to avoid it.

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

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

No annotations are provided, so the description carries the full burden. It discloses the type of data returned (frequency, success rate, usage timeline), which is good. However, it does not mention error behavior (e.g., what happens if the pattern doesn't exist) or any other behavioral nuances. It is a read operation and the description is reasonably transparent for that.

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 action and core content. It is front-loaded and contains no filler or redundant information, making it highly 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?

The tool is simple (one parameter, no output schema), and the description covers the purpose and the key output components. It does not explain the full return shape, but for a basic stats-retrieval tool, the description is largely sufficient. A slightly higher score would require more detail on response format or edge cases.

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%, as the parameter 'pattern' is fully described as 'The pattern name to get statistics for'. The description adds no additional meaning beyond the schema, 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 specifies the tool's purpose: to get detailed statistics for a specific pattern, and lists the specific metrics included (frequency, success rate, usage timeline). This distinguishes it from sibling tools like get_top_patterns or get_trending_patterns, which operate on pattern sets rather than a single named pattern.

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: use when you need statistics for a specific pattern. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or alternative tools. The context is clear but not explicitly differentiated.

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. The verb 'Get' implies a read-only operation, and the scope is clear. However, it does not explicitly state that it is safe, non-mutating, or free of side effects, nor does it mention any potential for large responses or errors. This is adequate but not rich.

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

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

The description is a single, efficient sentence that front-loads the action and resource, with no redundancy or filler. Every word contributes to understanding the tool's purpose.

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

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

Given the tool has only one parameter and no output schema, the description adequately conveys the returned content by listing the key configuration components. It is complete enough for an agent to understand what to expect, though it does not mention any relationship to sibling configuration 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?

The schema covers 100% of parameters (projectId with 'Project ID' description), so a baseline of 3 is appropriate. The description does not add any additional meaning about the parameter, such as format, source, or constraints, 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 retrieves the complete project configuration, listing specific components (tech stack, sub-agents, MCP tools, guidelines, code patterns). This is a specific verb+resource. However, it does not explicitly distinguish itself from the sibling tool get_project_info, which may overlap, so it loses one point.

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 such as get_project_info or the many configuration-modification tools. The description only states what it does, leaving the agent to infer usage context. No exclusions or alternatives are mentioned.

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

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

With no annotations provided, the description carries the burden. It transparently states that the tool returns information (implying a read-only operation) and clarifies the scope as 'current project'. It does not mention error conditions or side effects, but for a parameterless getter, the disclosed scope and fields are sufficient.

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

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

The description is a single concise sentence that front-loads the action ('Returns information') and includes the key resource and fields. There is no wasted wording or unnecessary repetition.

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

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

For a simple tool with no parameters and no output schema, the description fully covers what the tool does and what it returns. It lists the included fields and the project scope, making it complete for its complexity level.

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, so the baseline is 4. The description does not need to explain parameter semantics; it correctly omits any parameter details since none exist.

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 'Returns information about the current project' with specific fields (name, status, description). This distinguishes it from sibling tools focused on tasks, templates, or patterns, making its purpose unambiguous.

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

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

The description implies usage when project-level information is needed, but it does not explicitly state when to use this tool versus alternatives like 'get_project_configuration' or 'get_project_configuration'. No exclusion criteria or alternative references are provided, so guidance is only implied.

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, and the description does not disclose behavioral traits such as return format, how relevance is determined, or whether results are aggregated. This leaves the agent uncertain about the tool's 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?

The description is a single, concise sentence that is front-loaded with the action and object. It contains no redundant information and is easy to parse, meriting a high score for efficiency.

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 lack of annotations, no output schema, and a large set of sibling knowledge tools, the description is too sparse. It doesn't explain how this tool differs from others or what the response will look like, making it incomplete for effective tool selection and 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?

The schema has 100% coverage with descriptions for all three parameters. The description does not add additional meaning beyond the schema, but the schema already adequately documents the parameters, so a 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 that the tool retrieves relevant templates, patterns, and learnings for a task, using a specific resource and context. It distinguishes this from sibling listing tools by emphasizing 'relevant' and 'for a task', though it does not explicitly name alternatives.

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 list_templates, list_patterns, or get_similar_learnings. The agent is left without explicit context for choosing 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?

With no annotations, the description carries the behavioral disclosure burden. It indicates a read operation by using 'Get' and specifies the return type (tasks), which is useful. However, it does not disclose any potential side effects, limitations, ordering, or what 'touch' means, leaving some ambiguity.

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

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

The description is a single, direct sentence with no redundant wording. It efficiently states the tool's purpose without unnecessary detail, 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 one-parameter read tool without an output schema, the description adequately conveys that the tool returns tasks. However, it is vague about the nature of 'touch' (e.g., direct references or transitive dependencies) and does not mention pagination, error cases, or return format, which could be relevant in a complex system.

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 only parameter, resourceId, is already well-described in the schema as 'Resource ID to query usage for'. The description does not add significant new meaning beyond the schema, so it relies on the schema for parameter understanding. Schema coverage is 100%, earning the baseline score of 3.

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 'Get all tasks that touch a specific resource' clearly identifies the tool's function: it retrieves tasks associated with a given resource. The verb 'Get' and the resource-focused scope are specific, and this distinguishes it from generic list_tasks or get_task_context, though it does not explicitly name alternatives.

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 other task-related tools. It does not mention context, prerequisites, or alternatives, leaving the agent to infer the use case from the description 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 are provided, so the description carries the full burden. It mentions the method of 'context and pattern matching' but does not disclose behavioral details such as whether the operation is read-only, how results are sorted, whether pagination is used, or any error conditions. This is insufficient for a tool with no annotation backing.

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, well-structured sentence that front-loads the verb 'Find' and the resource. There is no filler or unnecessary detail, making it highly concise and easy to parse.

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 no output schema and no annotations, the description should explain what the tool returns and any operational nuances. It only states the basic search action, omitting return format, sort order, or limitations. This under-specification leaves important gaps for a tool with four parameters.

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%, so the parameters are fully documented. The description adds no significant meaning beyond the schema; it simply refers to 'context and pattern matching', which are already parameter descriptions. Thus, baseline 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 uses the specific verb 'Find' and clearly identifies the resource as 'similar learnings/feedback', with the basis 'context and pattern matching'. This conveys the core function and differentiates it from general list tools like list_learnings, but it does not explicitly contrast with sibling tools such as get_relevant_knowledge.

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 alternatives like list_learnings or get_relevant_knowledge. It does not mention expected use cases, exclusions, or prerequisites, leaving the agent to infer when this tool is 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 is the only transparency signal. It clearly indicates a read operation via 'Get', which is safe to infer. However, it doesn't disclose ordering, structure, or whether it includes all status changes, which would be useful. Still adequate for a simple getter.

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 of seven words, directly front-loaded with the core action and resource. Zero 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 low-complexity read tool with one fully documented parameter, the description adequately conveys what the tool does. It doesn't specify return value details, but no output schema exists; still, 'status transition history' implies a list of transitions, which is sufficient for simple 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 schema already documents taskId at 100% coverage. The description doesn't add additional parameter semantics beyond reinforcing that it's for a task, so the baseline 3 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 uses a specific verb 'Get' and a specific resource 'status transition history' scoped to a task. It is clear and distinct from most siblings, though 'get_task_history' overlaps, so it doesn't explicitly differentiate.

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 'get_task_history' or how it relates to 'record_status_transition'. There are no when-to-use or 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?

The verb 'get' implies a read-only operation, which provides some behavioral transparency, but the description does not explicitly state that it has no side effects, nor does it disclose any caveats such as permissions, error behavior, or what constitutes a conflict. With no annotations, the description carries the full burden but only partially fulfills it.

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 of 12 words, front-loaded with the action verb 'Get'. Every word contributes meaning, with no filler or redundant details.

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 one parameter, no output schema, and no annotations. The description provides the core purpose and the basis for conflict detection, which is sufficient for an agent to understand the tool's basic behavior. It doesn't describe return format or edge cases, but for a straightforward getter this is acceptable 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 schema covers 100% of the parameter with the description 'Task ID to check for conflicts', which is nearly identical to the tool description. The phrase 'based on resource usage' adds minor context about the conflict type, but essentially the description repeats the schema. With full schema coverage, baseline 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 uses the specific action verb 'Get', identifies the resource as 'potential conflicts for a task', and specifies the basis as 'resource usage'. This clearly distinguishes it from sibling tools like get_resource_usage (which likely returns raw usage data) and get_task_dependency_graph (which maps dependencies).

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 about when to use this tool versus alternatives. It does not mention scenarios like 'before scheduling a task' or 'to check resource availability', and it doesn't reference sibling tools. The intended use is only implicitly derived from the name and description.

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 names what context is returned (dependencies, previous work, guidelines, tech stack) and the verb 'Gets' implies a read-only operation, but it does not explicitly state safety, error behavior, or whether the tool aggregates data from multiple sources. This is adequate but not rich.

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

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

The description is a single, front-loaded sentence that states the action and lists specific content categories without any filler. Every word earns its place, and the structure is 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?

With no output schema, the description must convey what the tool returns; it names four meaningful categories. However, it does not clarify the structure or depth of 'previous work' or mention any potential cost/latency. For a single-parameter read tool, this is mostly complete but could offer more detail.

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 covers the only parameter 'id' with description 'Task ID', giving 100% coverage. The description adds no additional parameter-level detail, so the schema already does the heavy lifting. Baseline 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 uses the specific verb 'Gets' with a clear resource ('comprehensive context for a task') and enumerates the content areas (dependencies, previous work, guidelines, tech stack). This clearly distinguishes it from sibling tools like get_task_dependency_graph or get_relevant_knowledge, which focus on narrower aspects.

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 its use for retrieving broad task context but does not explicitly state when to use it over alternatives or mention specific exclusions. It lacks the explicit guidance found in higher-scoring examples, such as naming sibling tools that should be used for more specific needs.

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 the tool's behavior. It implies a read operation via 'Get' but does not explicitly state safety, permissions, or whether the graph includes transitive dependencies or other details beyond nodes and edges.

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 is front-loaded and contains no filler. It efficiently communicates the core action and output.

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 getter with one parameter and no output schema, the description is minimally adequate. It mentions nodes and edges but does not clarify their exact nature or how the graph relates to other task-related tools, leaving some 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 schema covers 100% of the parameter (taskId) with a description, and the tool description adds no additional meaning. The baseline of 3 applies because the 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?

The description clearly states the tool's function: retrieving the dependency graph (nodes and edges) for a task, using a specific verb and resource that distinguishes it from sibling tools like get_execution_order or get_task_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 on when to use this tool versus alternatives such as get_execution_order or get_task_context. The description does not mention exclusions, prerequisites, or scenarios where another tool 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 burden. It discloses the return content (event history with listed categories) and implicitly signals a read-only operation. Yet it does not mention any quirks such as pagination, sorting, or potential lack of side effects explicitly.

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 is direct and front-loaded. Every word adds value, and it avoids redundancy or unnecessary detail.

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 parameter, no output schema), the description adequately explains what the tool returns by enumerating the categories of history. It does not need to explain return values in depth since it already provides a clear summary, though it could mention the absence of filtering or ordering.

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% coverage with taskId described as 'Task ID'. The tool description adds no further parameter meaning beyond what the schema already states, so the baseline of 3 is appropriate.

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

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

The description specifies the verb 'Get', the resource 'complete event history for a task', and enumerates the included categories (status changes, decisions, code changes, guardian interventions). This distinguishes it from sibling tools that target only one of these categories.

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 'complete event history' implies this tool is for a full view, while sibling tools like get_status_history and get_decisions are more specific. However, no explicit when-to-use or alternative guidance 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?

With no annotations provided, the description must carry the full transparency burden. It states the core operation (get all tasks) but does not disclose any behavioral details such as ordering, pagination, handling of missing or empty user stories, or whether the response is a flat list or nested object.

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 with no filler or redundant information. It gets straight to the point and is appropriately sized for the tool's simplicity.

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 tool, the description is minimally adequate: it states the purpose and the parameter is well-documented in the schema. However, it does not mention the return shape or any edge cases, and with no output schema or annotations, this leaves some ambiguity about what 'all tasks' actually includes.

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 provides 100% coverage for the single parameter userStoryId, describing it as 'UUID of the user story'. The description adds no additional meaning beyond this, so it meets the baseline for high 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 uses a specific verb ('Get') and identifies the resource ('tasks') with a clear scope ('belonging to a specific user story'). This distinguishes it from broader sibling tools like list_tasks, which is a general listing, and get_task_context, which is about context rather than retrieval.

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_tasks or get_task_dependency_graph. There are no exclusions, prerequisites, or alternative tool references, leaving 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?

With no annotations, the description carries the full burden. It only mentions the point-in-time aspect but does not disclose what the snapshot contains, whether it is read-only, how the timestamp is interpreted (exact match, nearest prior), or response structure. Minimal 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?

A single, front-loaded sentence with no extraneous content. Efficient and 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?

For a simple two-parameter read tool, the description is adequate but incomplete: it lacks output schema, return value details, and usage guidance. The 'snapshot' behavior is not fully specified, leaving ambiguity about what is returned.

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 provides detailed descriptions for both parameters (taskId, timestamp with ISO 8601 format), covering 100% of parameters. The description adds no additional parameter-level semantics beyond restating the temporal scope.

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 a task snapshot at a specified timestamp, with a specific verb ('Get'), resource ('task snapshot'), and temporal scope. It differentiates from siblings like get_task_history by focusing on a single point-in-time view.

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 get_task_history or get_task_context. The description does not mention exclusions, prerequisites, or recommended 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It clarifies that the tool returns aggregated statistics with event counts and timeline, which implies a read operation. However, it does not disclose return format, pagination, or potential side effects. This is adequate but not rich.

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

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

The description is a single concise sentence that front-loads the purpose and key details. There is no wasted wording, making it easy to parse quickly.

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

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

The tool has one parameter, no output schema, and no annotations. The description gives the core purpose but lacks specifics on the exact stats returned, timeline structure, or any limitations. Given the simplicity, this is adequate but leaves some ambiguity about the response shape.

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 covers the single parameter taskId with a basic 'Task ID' description, so schema coverage is 100%. The description does not add extra semantic detail beyond what the schema already states, matching the baseline for full schema coverage.

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

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

The description states the tool gets aggregated statistics for a task, including event counts and timeline. This is a specific verb+resource, but it does not explicitly distinguish from sibling tools like get_task_history or get_pattern_stats.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention exclusions, alternatives, or typical use cases, leaving the agent without context for tool selection.

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 of behavioral disclosure. It does add context about sorting (by frequency and recency) and scope (across all tasks), which are useful traits. However, it does not explain what constitutes a 'pattern', how the sorting is computed, or any potential edge cases (e.g., ties). This is adequate 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 a single, well-structured sentence that immediately states the purpose and key behavioral attributes. No unnecessary words or redundancy.

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

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

For a simple read-only tool with one parameter and no output schema, the description conveys the core behavior adequately. However, the lack of any comparative guidance among the many pattern-related siblings and the absence of details about the return format leave some gaps for an agent deciding between 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?

The schema already fully documents the only parameter 'limit' with its description and default. The tool description adds no additional meaning about the parameter beyond what the schema provides. With 100% schema coverage, the baseline of 3 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 tool gets the most frequently used patterns across all tasks, with a specific verb and resource. It also mentions the sorting criterion (frequency and recency), which adds specificity. However, it does not differentiate itself from similar sibling tools like get_trending_patterns or list_patterns.

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 is given on when to use this tool versus alternatives. With multiple pattern-related siblings (e.g., get_trending_patterns, get_pattern_stats), a note about preferring this for overall frequency vs. trending would be valuable. The description implies usage but provides no exclusions or alternative recommendations.

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

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

No annotations are provided, so the description carries the burden. It discloses the key behavioral trait that 'trending' is based on 'most used in recent days', which adds meaning beyond the name. However, it doesn't state whether this is strictly read-only, or any other side effects, though the 'get' prefix suggests a 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 a single, compact sentence that starts with the action verb 'Get' and provides the essential information without any filler. It is perfectly sized.

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 retrieval tool with two optional parameters and no output schema, the description gives the purpose, the time-based definition of 'trending', and a practical use case. It lacks an explicit statement about return format, but the description is otherwise sufficient given the tool's 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 coverage is 100%, with both 'days' and 'limit' each having descriptions and defaults in the schema. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 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 uses the specific verb 'Get' with the resource 'trending patterns' and defines the meaning as 'most used in recent days'. This clearly states the tool's function, but it doesn't explicitly distinguish it from the similar sibling tool 'get_top_patterns'.

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 context by noting it's 'useful for identifying current development patterns', which implies the appropriate use case. However, it doesn't mention exclusions or contrast with alternatives like get_top_patterns or list_patterns.

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 available, the description carries the full burden of behavioral disclosure. It conveys a read-only operation via 'Get all' and previews computed task counts, but it does not explicitly state absence of side effects, data scope semantics (e.g., active vs archived), 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?

A single, front-loaded sentence with an action verb and clear purpose. Every word contributes: 'Get all user stories' defines scope, 'with task counts' defines output, and 'for dashboard display' defines intent.

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 tool, the description provides essential purpose and output shape (user stories plus task counts). It is reasonably complete, though it could mention sibling alternatives or clarify whether any filtering/archiving applies.

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 zero parameters, so the baseline is 4. The description adds no parameter-specific details, but none are required because the tool takes no inputs.

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

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

The description clearly states a specific verb ('Get'), resource ('all user stories'), and additional output detail ('with task counts') for a defined use case ('dashboard display'). This distinguishes it from sibling tools like get_tasks_by_user_story and delete_user_story.

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 get_user_story_health or get_tasks_by_user_story. The phrase 'for dashboard display' implies a use context but does not provide exclusions, prerequisites, or alternative tool recommendations.

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

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

With no annotations, the description carries the full burden. It discloses the type of data returned, which is helpful, but doesn't explicitly state read-only behavior, error conditions, or edge cases. The 'Get' verb implies a read operation, but side effects and assumptions are unaddressed.

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 concise single sentence, front-loaded with the action and resource, and each clause adds specific value (status, completion, safety). 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 zero-parameter tool with no output schema, the description covers the purpose and key output fields. It could mention edge cases or the meaning of 'health', but it is reasonably 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?

The tool has zero parameters, so the input schema is fully sufficient. Baseline 4 applies because there are no parameter details to add; the description already conveys the scope ('all user stories').

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 tool gets health monitoring data for all user stories, with specific output aspects (current vs. suggested status, completion percentage, safety flags). It distinguishes itself from sibling tools like get_user_stories by focusing on health monitoring rather than mere listing.

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 usage guidance or alternatives are mentioned. The description implies use when a health overview is needed, but it doesn't clarify when to prefer this over get_user_stories or other related tools. Adequate but not fully explicit.

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

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

With no annotations, the description must disclose side effects. It only restates the tool's name ('Initialize default configuration') without explaining whether it overwrites existing configuration, requires special permissions, or creates new records. This lack of behavioral disclosure is a significant gap for a mutation 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 a single, front-loaded sentence that directly states the action and scope. It wastes no words, though it could expand to include usage context without compromising 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?

With no output schema and no annotations, the description is too sparse. It does not mention return values, error conditions, or what 'initializing' entails (e.g., whether it replaces existing configuration). The tool's simplicity (one parameter) reduces but does not eliminate the need for this information.

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 already provides full coverage with 'Project ID to initialize', so the description does not need to add parameter details. The description adds no extra meaning beyond the schema, meeting the baseline for high 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 identifies the verb 'Initialize' and resource 'default configuration for a project', specifying it includes tools and guardian agents. This clearly separates it from read tools like get_project_configuration and incremental add tools like add_tech_stack, though it could be more explicit about the full default configuration contents.

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 that this is for initial setup only, nor does it exclude using it on existing projects, leaving the agent without decision-relevant 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 explicitly states that the tool returns a prompt and does not itself perform task creation, which is a key behavioral trait. However, it does not mention potential side effects (e.g., whether it saves anything) or prerequisites, though the absence of such mentions likely indicates a pure generation 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 three sentences and gets to the point quickly. The opening 'INTELLIGENT WORKFLOW' is somewhat promotional, but the rest is informative without unnecessary verbosity. It is appropriately sized and 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?

The tool has no output schema, so the description correctly explains the return value ('Returns a prompt'). It also covers the workflow (Claude Code will use Grep/Glob/Read). For a prompt-generation tool with only two parameters, this is largely complete, though it could briefly mention the structure of the returned prompt.

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%, so parameters are already well-documented. The description adds minimal extra meaning beyond the schema—'REAL project context' hints at the role of projectId, but it does not clarify format or additional semantics. Baseline 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 tool's purpose: it generates a structured prompt for Claude Code to analyze the codebase and decompose a user story. This specific verb+resource combination distinguishes it from sibling tools like create_task or save_story_decomposition, which directly manipulate tasks.

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 context ('based on REAL project context' and 'before creating tasks') but does not explicitly state when to use this tool versus alternatives like create_task or save_story_decomposition. No exclusions or alternative tool references are provided, so the guidance is only implied.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only indicates a read operation ('Lists') without detailing output format, ordering, pagination, or any side effects. The phrase 'from past experiences' adds limited context but does not explain what 'learnings' entail or how they are retrieved.

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 sentence with no redundant information. It is well-structured and front-loaded with the core purpose, making it easy to parse quickly.

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

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

The description is adequate for a simple list tool but lacks clarity on its specific role among many sibling tools and does not explain expected return value or filtering behavior beyond the schema. Given the absence of an output schema, some additional context would be beneficial, but the tool's simplicity prevents this from being a critical 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 input schema describes the single parameter 'tags' as 'Filter by tags (optional)', giving 100% schema coverage. The description itself adds no additional meaning to the parameter, so a 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 states a clear action ('Lists') and resource ('learnings from past experiences'), which conveys the tool's basic purpose. However, it does not differentiate it from sibling tools like 'get_similar_learnings', which also deals with learnings but has a different retrieval focus.

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 such as 'get_similar_learnings' or 'list_patterns'. The description does not mention any specific contexts, exclusions, or prerequisites, leaving the agent without sufficient direction for tool selection.

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 to rely on, the description carries the full behavioral transparency burden. It only states that patterns are 'learned from the codebase', which adds minimal context. It does not disclose sorting, pagination, or how filters interact (e.g., AND/OR), or any other behavioral characteristics.

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 sentence with no wasted words. It is front-loaded and easy to parse.

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 has no output schema, and the description does not mention return values or output format. Additionally, the lack of distinction from sibling tools and absence of usage context makes the description incomplete for an agent to select it correctly among many similar pattern-related 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?

The input schema already provides 100% coverage with descriptions for both parameters (tags and category), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already communicates.

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 (lists) and resource (coding patterns learned from the codebase). It is specific but does not differentiate from sibling tools like get_top_patterns or get_trending_patterns, which are also pattern-related but serve different purposes.

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 get_top_patterns, get_trending_patterns, or get_pattern_stats. The description simply states what it does without any contextual or exclusionary information.

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. 'Lists all tasks' indicates a read-only operation with no side effects, and the filter semantics are clear. However, it does not mention ordering, pagination, or potential domain limits, which would be richer 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?

A single sentence that directly states the action and filter options. No filler or redundant 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 simple read-only list tool with only two optional parameters and no output schema, this description adequately covers the core behavior. It could mention sort/pagination but those are not necessarily expected for this simple 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 input schema already provides full descriptions for both parameters (status and category) with enums. The description's mention of 'optionally filtered by status and/or category' matches the schema but adds no new meaning beyond what schema 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 states 'Lists all tasks' – a specific verb and resource. It distinguishes from sibling tools like get_task_dependency_graph or get_tasks_by_user_story by focusing on the general task list. The optional filtering by status/category further clarifies 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 general task listing, and explicitly mentions optional filters for status and category. However, it does not call out alternatives or conditions where another tool (e.g., get_tasks_by_user_story) 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?

With no annotations provided, the description carries the burden of behavioral disclosure, but it only states the basic action. It does not mention that this is a read-only operation, what the output format is (e.g., names, metadata, content), or any potential side effects. The description adds no safety or behavior context beyond the literal meaning of 'lists'.

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

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

The description is a single concise sentence that is easy to parse and front-loads the key verb and object. It is appropriately brief for a simple tool, though the word 'available' adds little value. It does not waste words, but could have used the spare word budget to clarify the full category set.

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 has only one optional parameter and no output schema, so the description should compensate by explaining what is returned (e.g., template names, metadata, contents) and explicitly covering all categories from the enum. It fails to mention 'architecture' and 'review' categories and gives no indication of output structure or how to proceed after listing. This is a simple tool, but the description leaves important gaps, especially given 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?

Schema description coverage is 100% for the single parameter 'category', including an enum, so the schema already fully documents the parameter. The tool description adds no additional semantic value over the schema; it merely mentions 'prompt and code' while ignoring the other enum values, which is slightly inconsistent. Baseline 3 is appropriate as the 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?

The description clearly identifies the action ('Lists') and the resource ('available prompt and code templates'). However, it fails to mention the 'architecture' and 'review' categories present in the schema, making the scope incomplete and slightly misleading. It distinguishes from siblings like list_patterns and list_learnings by focusing on templates, but could be more explicit.

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

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

No guidance is provided about when to use this tool versus alternatives such as render_template or list_patterns. The description only states what it does, leaving the agent to infer usage context. There is no mention of prerequisites, exclusions, or sibling alternatives.

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?

Since no annotations are provided, the description carries the full burden of transparency. It discloses that the response contains a workflowInstructions field and instructs the agent to follow it. It also names the specific tools (Read, Grep, Glob) that will be leveraged. It does not mention side effects or error behavior, but for a prepare-like tool, the disclosed workflow is substantive.

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 and a warning, front-loaded with the primary purpose. Every sentence adds value: it states the action, describes the output, and provides a clear next step. No filler or redundancy.

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

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

For a tool with only one parameter and no output schema, the description covers all essential aspects: what it does, what it returns, how to interpret the result (workflowInstructions), and what action to take next (call save_task_analysis). The workflow guidance makes it complete for the agent's decision-making.

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% coverage—it already documents taskId with 'Task ID to prepare for execution.' The description adds minimal semantic detail beyond the schema, merely restating that it prepares a task. Per the baseline rule for high coverage, a 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 tool's action: 'Prepares a task for execution by generating a structured analysis request.' It specifies the exact output (a prompt) and the underlying tools (Read, Grep, Glob) it will guide. This is a specific verb+resource and distinguishes it from siblings like get_execution_prompt (which likely executes a prompt) and save_task_analysis (which saves results).

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 strong usage context by outlining a workflow: prepare, analyze, then 'call save_task_analysis with the results.' It tells the agent what to do after this tool. However, it does not explicitly name alternatives or state when NOT to use this tool, so it falls just short of a 5.

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

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

With no annotations provided, the description carries the full burden, but it only states 'read and parse' without detailing return format, error handling, or side effects. It adds the default directory path but lacks 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?

One sentence, front-loaded with the verb and clear object. 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?

The tool is simple with one optional parameter, but without an output schema or annotations, the description should explain what is returned or parsed. It doesn't, so while minimal, it's not fully complete.

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

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

Schema coverage is 100% with the agentsDir parameter fully described, so the baseline is 3. The description's mention of '.claude/agents/ directory' aligns with the schema's default but adds no additional 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?

The description uses a specific verb ('Read and parse') and identifies the resource (Claude Code agents) and location (.claude/agents/ directory), clearly distinguishing it from sibling tools like sync_claude_code_agents which implies a write/sync operation.

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 any exclusions. It simply states what it does, so an agent cannot determine when this is the right choice 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 provided, so the description carries the full burden. It only states the action without disclosing whether records are appended or overwritten, whether the task must exist, or any validation/error behavior. This is minimal disclosure for a write 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, concise sentence with no filler words. It front-loads the important information and gets directly to the point.

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 a fully described schema, the tool's inputs are clear, but the lack of behavioral context (e.g., whether this appends to a history) and absence of output schema information leaves gaps for a writing tool. For a simple recording operation, the description is minimally viable but not rich.

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 provides 100% description coverage for all five parameters, so the baseline is 3. The description adds no additional meaning about parameters such as the optional nature of diff and commitHash.

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 specific verb 'record' with the resource 'code change' and contextual scope 'during task execution'. It clearly distinguishes from siblings like record_decision and record_guardian_intervention, but doesn't explicitly name alternatives.

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 'during task execution' implies the appropriate context for use, but no explicit guidance is given about when not to use it or which alternative tools to prefer. There is no mention of prerequisites like an active task or a comparison with get_code_changes.

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 only that it 'records' a decision, implying a write operation, but does not disclose whether it persists data, requires an existing task, or how it interacts with task history. No information about side effects or permissions is given.

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 with no filler, front-loading the action ('Record') and the object ('a decision') immediately. It is optimally short for the information it conveys.

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 is a mutation with no annotations and no output schema, the description is incomplete. It doesn't explain the purpose within the larger workflow, such as that decisions are logged for later retrieval via get_decisions, nor does it mention any prerequisites (e.g., valid taskId). The schema covers parameters but not operational 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 input schema has 100% coverage with descriptions for all five parameters, so the schema already documents the parameters adequately. The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline for high 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 uses a specific verb 'record' with a clear object 'decision' and context 'during task execution', which clearly distinguishes it from sibling tools like record_code_change or record_guardian_intervention. It unambiguously states 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 provides no guidance on when to use this tool versus other recording tools (e.g., record_code_change, record_status_transition, record_guardian_intervention) or how it relates to get_decisions. No exclusions or alternative recommendations 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 present, so the description carries full responsibility for behavioral disclosure. It only says 'Record a guardian intervention' without mentioning whether this creates a new entry, is idempotent, requires task existence, or returns a confirmation. For a mutation tool, this is a significant transparency gap.

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

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

The description is a single, direct sentence that immediately conveys the core action. It is concise and front-loaded, with no wasted words. The brevity, however, comes at the cost of behavioral detail, which is penalized elsewhere.

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 four required parameters, no output schema, and no annotations, the description is too terse to fully equip an agent. It does not explain what constitutes a guardian intervention, what happens on success or failure, or how this record might be used later. The agent is left to infer critical 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 input schema provides a description for every one of the four parameters, achieving 100% coverage. The tool description adds no parameter-specific meaning beyond what the schema already offers, so the baseline 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 verb 'Record' and the resource 'guardian intervention', making it distinct from retrieval siblings like get_guardian_interventions. However, it does not explicitly differentiate from other record_* tools (e.g., record_decision), and the domain concept is left somewhat unexplained.

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 'during task execution' provides some timing context, and the sibling list implies a record-vs-read relationship with get_guardian_interventions. Yet there is no explicit guidance on when to prefer this tool over alternatives, nor any stated exclusions or prerequisites.

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 does not mention side effects, whether the task's status is also updated, permissions required, or what the tool returns. For a write operation, this is a significant transparency gap.

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

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

The description is a single, efficient sentence with no redundant words. It is front-loaded and clearly communicates the core action without excessive detail.

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 this is a write operation with no output schema and no annotations, the description is too sparse. It fails to explain what a status transition entails, whether it also mutates the task, or any constraints on valid transitions, making it under-specified for an agent to invoke confidently.

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 provides descriptions for all four parameters (100% coverage), so the description need not explain them. The baseline score of 3 applies because the schema does the heavy lifting; the description adds no additional 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?

The description 'Record a status transition for a task' uses a specific verb and resource, clearly distinguishing it from sibling tools like update_task (which updates task fields) and get_status_history (which reads history). It conveys the exact intent without ambiguity.

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 update_task or create_task. There are no contextual hints or exclusions mentioned, leaving the agent to guess the appropriate scenario.

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 states the action 'remove' (destructive) but offers no details on side effects, reversibility, or cascading impacts. For a mutation tool, this lacks necessary transparency about what happens beyond the immediate removal.

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, front-loaded with the verb and object, and contains no filler. It is appropriately sized for the tool's simplicity.

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 nature of the tool (one parameter, no output schema, no annotations), the description is minimally adequate. However, the lack of any behavioral warnings or return-value hints leaves a gap for a destructive operation, so it is not fully complete.

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

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

Schema description coverage is 100% with one clearly described parameter ('Tech stack ID to remove'). The description adds no extra meaning beyond the schema, so the baseline score of 3 applies.

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

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

The description uses the specific verb 'Remove' with resource 'tech stack entry' and scope 'from the project', clearly differentiating it from sibling tools like add_tech_stack and update_tech_stack. It is concise 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 implies usage as the deletion counterpart to add/update tech stack tools, but provides no explicit guidance on when to use it or alternatives. There are no exclusions or prerequisites, leaving the agent to infer the appropriate 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 full responsibility for behavioral disclosure. It only says 'Renders a template', which implies a read-only transformation, but doesn't specify output format, side effects, error behavior, or whether it modifies the template. This is insufficient for a tool with zero 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 conveys the essential purpose. It is appropriately concise, with no wasted words or redundancy.

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

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

The tool is relatively simple with only 2 parameters and no output schema, but the description omits key details like the return format or how it fits into workflows (e.g., with templates listed by sibling tools). It's adequate but leaves gaps for an agent to infer expected 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?

Schema description coverage is 100%, with both templateId and variables having clear descriptions. The tool description adds no new parameter semantics beyond the schema, 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 uses a specific verb 'Renders' with a clear resource 'template', and specifies the input 'provided variables'. It distinguishes from sibling tools like list_templates by focusing on the rendering action, not listing or retrieving templates.

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 given on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., selecting a template via list_templates), exclusions, or when not to use it. The usage is only implied from the name and description.

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 states the action (rollback to a timestamp) but does not disclose whether the rollback is destructive, whether it creates a new version or overwrites, if it is reversible, or what consequences occur for states after the target timestamp. This lack of side-effect information is a significant gap for a mutation 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 a single, front-loaded sentence that states the action and key qualifier. It is concise and free of redundant information, achieving maximum efficiency.

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 rollback is a potentially destructive operation with no output schema and no annotations, the description is under-specified. It does not explain the meaning of 'previous state', whether the rollback is a soft/hard revert, or how the timestamp is validated. More behavioral context is needed for an agent to use it safely, especially since sibling tools like get_task_snapshot and get_task_history exist for related non-destructive actions.

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 already covers both parameters with clear descriptions (taskId and targetTimestamp with ISO 8601 format). The tool description adds no further semantic meaning beyond what the schema provides, and with 100% schema coverage, the baseline 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 uses a specific verb 'rollback' with a clear resource 'task' and qualifies it with 'to a previous state at a specific timestamp'. This precisely distinguishes it from sibling tools like update_task or delete_task by indicating a restore-to-timestamp operation.

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 reverting a task to an earlier state, but it provides no explicit guidance on when to use this tool versus alternatives like update_task or get_task_snapshot. There are no exclusions or alternative recommendations, so the usage context is only implied.

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 to lean on, the description discloses critical behavioral traits: it preserves certain categories of tasks (completed work stories, dependencies) and provides a detailed report of deleted vs. preserved. This goes beyond a generic delete statement, though it doesn't mention irreversibility or 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 is two sentences, front-loaded with the primary action, and every sentence adds value: the first states the core function and safety guard, the second clarifies the output. No wasted words or redundant details.

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 tool with no output schema, the description covers the essential context: the operation, specific preservation logic, and the return report. It omits minor details like behavior when no tasks match, but overall it is sufficiently complete for an agent to decide and execute.

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 already describes the only parameter (status) with an enum and description, providing 100% coverage. The description does not add additional parameter-level meaning beyond what the schema supplies, so it merits the baseline score of 3.

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 tasks), the scope (by status), and the distinguishing safety behavior (preserving user stories with completed work and tasks with dependencies). It is easily differentiated from sibling tools like delete_task, which handles individual deletion.

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 context: use this for bulk deletion by status when safety is needed, as it automatically preserves certain tasks. It does not explicitly mention alternatives or exclusions, but the safe/preserving language provides clear context for when this tool is 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?

With no annotations, the description must fully disclose behavioral traits, but it only states that it saves and detects conflicts. It does not explain whether conflicts are returned, whether the save is blocked, whether existing dependencies are overwritten, or any permissions or side effects. This is a significant transparency gap for a mutation 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 a single concise sentence that immediately states the primary action and secondary behavior. It contains no filler or 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 there is no output schema and no annotations, the description is too terse for a tool that both saves data and detects conflicts. It does not explain return values, failure modes, or how conflict detection affects the save operation, leaving the agent with insufficient context for correct 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 description coverage is 100%, so the schema already documents both taskId and resources. The description adds no additional meaning beyond the schema, so the baseline of 3 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 'Save analyzed dependencies and detect potential conflicts with other tasks' clearly states the specific verb (save) and resource (analyzed dependencies), and includes an additional outcome (conflict detection). This distinguishes it from read-only sibling tools like get_task_dependency_graph and get_task_conflicts.

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 used after dependencies have been analyzed, especially given the schema notes resources come from analyze_dependencies. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or conditions.

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 of behavioral disclosure. It only says 'Saves the decomposition analysis,' which is essentially a restatement of the tool's purpose. It does not disclose whether saving overwrites existing data, requires authentication, or has side effects, which is critical for a mutation/save 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, consisting of two sentences that front-load the purpose and then immediately provide usage guidance. No redundant or filler 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 rich schema (nested analysis object with many fields), the description does not need to enumerate parameters. It provides the key contextual cue about when to call (after intelligent_decompose_story) and what the analysis should include ('real file paths and dependencies'). However, it lacks any note about return values or what happens after saving, but the schema and tool name carry enough weight.

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%, so the baseline is 3. The description adds some context by mentioning 'real file paths and dependencies,' which hints at the analysis content, but it does not explain individual parameters. The schema itself documents the parameters sufficiently, so the description provides only marginal added meaning.

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 function: 'Saves the decomposition analysis performed by Claude Code after exploring the codebase.' The verb 'saves' and resource 'decomposition analysis' are specific and unambiguous, and it differentiates from siblings like intelligent_decompose_story and save_task_analysis by focusing on the post-analysis save step.

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

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

The description explicitly states when to use the tool: 'Call this after intelligent_decompose_story once you've analyzed the codebase and created the task breakdown with real file paths and dependencies.' This gives a clear usage context, though it does not mention when not to use it or name alternatives beyond the preceding tool.

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 transparency burden. It discloses key behavioral aspects: the tool records dependencies, risks, and recommendations, and importantly, the response includes 'nextSteps guidance' that should be followed. This goes beyond the schema, though it doesn't describe side effects like overwrites or appending 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?

The description is three clear, information-dense sentences. It front-loads the core purpose, then provides the usage trigger and a critical warning about nextSteps. Every sentence earns its place with no redundancy or 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?

The tool has nested parameters and no output schema, but the description covers the essential context: when to call it, what data it records, and that the response includes nextSteps guidance. It doesn't detail the full return structure, but for a save operation, this is reasonably complete, given the rich schema and usage instruction.

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% (taskId: 'Task ID', analysis: 'Analysis results from codebase inspection'). The description mentions recording dependencies, risks, and recommendations, which maps to the schema's nested properties but doesn't add new parameter-level meaning beyond what the schema already provides. Baseline 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 tool's purpose: 'Saves the codebase analysis performed by Claude Code.' It names a specific action (save) and resource (codebase analysis), and distinguishes itself from sibling tools like save_dependencies and save_story_decomposition by focusing on task analysis.

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 clear usage context: 'Call this after analyzing the codebase following the prepare_task_for_execution prompt.' This tells the agent when to use it. It doesn't explicitly mention alternatives or when not to use it, but the context is sufficient for a 4 scoring.

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

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

With no annotations, the description carries the burden of disclosing safety and behavioral traits. It only describes the output and 'AI-powered' nature, but does not explicitly state it is read-only, requires permissions, or has side effects, leaving behavioral transparency incomplete.

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 (two sentences), front-loaded with the primary action, and contains no redundant information. Every sentence 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?

The tool is relatively simple with three parameters and no output schema. The description covers the output format and inputs, but lacks details on failure modes, how projectId is used, or differentiation from similar tools. It is sufficiently complete for a straightforward suggestion 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 schema already describes all parameters (100% coverage), but the description adds value by explaining that task description and category are the basis for suggestions, connecting parameters to purpose. The mention of 'top 3 most relevant agents' gives context to the output but not the parameters themselves.

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 gets agent suggestions for a task based on description and category, and specifies it returns top 3 agents with confidence scores. This distinguishes it from sibling tools like suggest_tools_for_task.

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. The description implies usage from purpose but does not mention alternative tools 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 carries the full burden of behavioral disclosure. It reveals that the tool returns the top 3 most relevant tools with confidence scores, which is useful. However, it does not mention side effects (though 'suggest' implies no mutation), permissions, error behavior, or rate limits, leaving aspects undocumented.

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 is front-loaded with the action and result. Every word contributes to understanding the tool's purpose and output. There is no fluff or redundancy, making it highly concise and well-structured.

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