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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the tool's purpose and usage context, it lacks details about what the tool actually does behaviorally—such as whether it returns a list of features, provides interactive guidance, or displays documentation. For a tool with zero annotation coverage, this is a significant gap in transparency.

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

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

The description is extremely concise and well-structured, consisting of two sentences that directly address purpose and usage guidelines. Every word earns its place, with no redundant information, making it easy to parse and understand 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?

Given the tool's complexity (low, with no parameters) and the lack of annotations and output schema, the description is adequate but incomplete. It covers purpose and usage well, but fails to describe what the tool outputs or how it behaves, which is crucial for an AI agent to understand the result of invocation. This leaves gaps in contextual understanding.

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 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately focuses on purpose and usage. A baseline of 4 is justified as the description compensates well for the lack of parameters by providing clear 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 tool's purpose: 'Show what Callout can do and how to use it.' This specifies the verb ('show') and resource ('Callout capabilities and usage'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'init' or 'coach', which might have overlapping introductory functions.

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

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

The description provides explicit guidance on when to use this tool: 'Call this when a user first connects or asks about Callout.' This clearly defines the triggering conditions (initial connection or user inquiries about Callout), making it easy for an AI agent to decide when to invoke it versus 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what the tool does (analyzes behavior patterns) and what it doesn't do (review code quality), but lacks details about how the analysis works, what the output format is, whether it requires specific permissions, or if there are any rate limits. The description adds some context but doesn't fully compensate for the lack of annotations.

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

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

The description is efficiently structured in two sentences. The first sentence clearly states the purpose, and the second sentence provides crucial usage guidance by distinguishing it from a sibling tool. Every sentence adds value with no wasted words, making it appropriately concise 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?

Given the complexity of behavioral analysis and the lack of both annotations and an output schema, the description is somewhat incomplete. It explains the purpose and usage guidelines well but doesn't describe what the analysis output looks like, how comprehensive it is, or any behavioral constraints. For a tool with no structured output information, more context about results would be helpful.

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 1 parameter with 100% description coverage, so the schema already documents the parameter. The description doesn't add any parameter-specific information beyond what's in the schema. With 0 parameters, the baseline would be 4, but here we have 1 parameter fully covered by the schema, so a score of 4 is appropriate as the description doesn't need to compensate for schema gaps.

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: 'Analyzes your project setup, development habits, and knowledge blind spots to reveal what you don't know you're doing wrong when working with AI coding tools.' It specifies the verb (analyzes) and resource (project setup, habits, blind spots), and explicitly distinguishes it from the sibling 'review' tool by stating 'Does NOT review code quality (use review for that) — instead reviews YOUR behavior 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?

The description provides explicit guidance on when to use this tool versus alternatives: 'Does NOT review code quality (use review for that) — instead reviews YOUR behavior patterns.' It clearly states what this tool is for (analyzing behavior patterns with AI coding tools) and what it is not for (code quality review), directing users to the 'review' sibling tool for the latter.

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 effectively describes the tool's behavior: scoring across 10 dimensions with a skeptical stance and returning a verdict. However, it lacks details on potential limitations (e.g., accuracy, data sources), error handling, or performance characteristics like rate limits, which would be valuable for an agent to know.

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 front-loaded with the core purpose in the first sentence, followed by specific details on dimensions and verdicts. Every sentence adds value without redundancy, and the structure is clear and efficient, 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?

Given the tool's complexity (scoring across 10 dimensions) and the absence of both annotations and an output schema, the description does a good job of explaining what the tool does and what it returns. However, it could be more complete by detailing the output format (e.g., structured scores vs. summary) or potential edge cases, which would help an agent better anticipate results.

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

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

Schema description coverage is 100%, so the schema already documents both parameters well. The description adds context by explaining that the tool infers from README and project context if 'idea_description' is not provided, which clarifies the parameter's optional nature and default behavior. This goes beyond the schema's technical description, earning a score above 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 specific action ('Score your idea across 10 dimensions') and the resource ('idea'), with explicit details on the 10 scoring dimensions and the four possible verdict outcomes. It distinguishes itself from sibling tools like 'coach' or 'review' by focusing on quantitative scoring rather than qualitative feedback or general assistance.

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 ('with a skeptical default stance') and mentions that the tool infers from README/project context if no idea is provided, giving some guidance on when to use it. However, it does not explicitly state when to choose this tool over alternatives like 'coach' or 'review', nor does it provide exclusions or prerequisites for usage.

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 tool returns rules for enabling triggers and that the host should append them to a file, which gives some behavioral context (output format and intended action). However, it lacks details on permissions needed, whether it modifies files directly, error handling, or rate limits. For a tool with no annotations, this is minimal but not entirely absent.

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

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

The description is two sentences that are front-loaded with the core purpose and output, followed by the intended action. Every sentence earns its place: the first explains what the tool does and returns, the second specifies how to use the output. There's no wasted verbiage 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?

Given no annotations, no output schema, and a simple input schema, the description provides basic completeness by stating the tool's purpose and output usage. However, for a tool that likely involves file system operations or configuration changes, it lacks details on side effects, error conditions, or return values beyond 'CLAUDE.md rules.' This is adequate but leaves gaps in understanding the full 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 1 parameter with 100% description coverage, so the schema already documents 'project_path' well. The description doesn't add any parameter-specific information beyond what's in the schema, but with high coverage and only one parameter, the baseline is strong. Since there are no parameters mentioned in the description, it doesn't compensate but also doesn't detract, fitting the baseline for this case.

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: 'Initialize Callout in a project' and specifies what it returns ('CLAUDE.md rules that enable automatic review/coach/recommend triggers'). It distinguishes from siblings like 'callout_help' or 'review' by focusing on initialization rather than execution of those functions. However, it doesn't explicitly contrast with all siblings, so it's not a perfect 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 implies usage context by stating 'The host should append these rules to the project's CLAUDE.md file,' suggesting this tool is for setup/configuration rather than runtime operations. However, it doesn't provide explicit guidance on when to use this vs. alternatives like 'callout_help' or 'set_target_user,' nor does it specify prerequisites or exclusions. Usage is implied but not clearly articulated.

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 describes what the tool does (scanning, showing status, generating advice) but lacks details on behavioral traits such as whether it modifies files, requires specific permissions, has rate limits, or what the output format looks like. For a tool that interacts with directories and AI, this is a significant gap in transparency.

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

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

The description is concise and front-loaded, using two sentences that efficiently convey the tool's core functions. Every sentence adds value: the first sets the context and main actions, and the second specifies the output (resource allocation advice). There's no redundant or vague language, 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?

Given the tool's complexity (involving directory scanning, health metrics, and AI advice) and lack of annotations or output schema, the description is incomplete. It doesn't explain what 'health status' entails in detail, how risks are assessed, the format of the AI advice, or any behavioral constraints. For a tool with no structured data beyond the input schema, more context is needed to ensure proper usage.

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

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

The description doesn't explicitly mention parameters, but the input schema has 100% coverage with one parameter ('projects_root') that is well-documented in the schema. Since schema coverage is high, the baseline is 3, but the description's context about scanning directories for projects implicitly aligns with the parameter's purpose, adding slight value. With only one parameter, this is sufficient.

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: scanning directories for projects, showing health status metrics (todos, review history, risks), and generating resource allocation advice from a founder perspective. It uses specific verbs like 'scans', 'shows', and 'asks AI to give advice', making the function explicit. However, it doesn't distinguish this from sibling tools like 'todo_summary' or 'review', which might overlap in functionality.

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 mentions it's for 'founders managing multiple projects', but doesn't specify prerequisites, exclusions, or compare it to sibling tools like 'todo_summary' or 'review' that might handle similar aspects. Without this context, users must infer usage scenarios independently.

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 mentions that recommendations are based on current task and dependencies and that 'Same scenario is not recommended twice,' which adds some context about uniqueness and input-based behavior. However, it lacks details on permissions, rate limits, error handling, or what the output looks like (e.g., format of recommendations), which is a significant gap for a tool with no annotation coverage.

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

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

The description is concise and front-loaded, stating the core purpose in the first sentence. The second sentence elaborates on the types of tools/services, and the third adds a behavioral note about not repeating scenarios. Each sentence adds value without redundancy, making it efficient 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 complexity (a recommendation tool with 2 parameters, no annotations, and no output schema), the description is moderately complete. It covers the purpose and some behavioral traits but lacks details on output format, error cases, or integration with sibling tools. Without an output schema, the agent is left guessing what the recommendations look like, which is a notable gap for effective tool 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 input schema has 100% description coverage, with clear documentation for both parameters ('task' and 'project_path'). The description adds minimal value beyond the schema: it implies the 'task' parameter influences recommendations but doesn't specify how, and it doesn't mention the 'project_path' at all. Since schema coverage is high, the baseline is 3, as the description doesn't significantly enhance parameter understanding.

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: 'Detect what the project needs and recommend the best tool/service for each scenario.' It specifies the verb (recommend) and resource (tools/services like auth, database, payments, deployment tools) and mentions it's based on current task and existing dependencies. However, it doesn't explicitly distinguish this from sibling tools like 'coach' or 'idea_score' that might also involve guidance or recommendations, leaving some 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 implies usage context: 'based on current task and existing dependencies' and 'Same scenario is not recommended twice,' which suggests it's for project development scenarios and avoids duplicates. However, it doesn't explicitly state when to use this tool versus alternatives like 'coach' or 'idea_score,' nor does it provide exclusions or prerequisites, leaving the agent to infer appropriate usage.

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 tool 'dismisses' a scenario, implying a mutation, but doesn't clarify if this is permanent, reversible, requires specific permissions, or has side effects like affecting other recommendations. For a mutation tool with zero annotation coverage, this leaves significant behavioral 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 purpose, followed by usage guidance. Every word earns its place with zero waste, making it highly efficient and easy to parse for an AI agent.

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 a mutation tool with no annotations and no output schema, the description is adequate but incomplete. It covers purpose and usage well but lacks details on behavioral traits like permanence, permissions, or return values. For this complexity level, it should do more to compensate for missing structured data, resulting in a mid-range score.

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

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

Schema description coverage is 100%, with clear descriptions for both parameters: 'scene' as the scenario to dismiss and 'project_path' with a default. The description adds no additional parameter semantics beyond what the schema provides, such as examples of scenarios or context for 'project_path'. 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 states the action ('dismiss') and resource ('recommendation scenario') with a specific purpose ('so it won't be suggested again'). It distinguishes from siblings like 'recommend' (which suggests) and 'recommend_reset' (which resets dismissals), though not explicitly named. The purpose is specific but could be more precise about what a 'scenario' entails.

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

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

The description provides explicit usage context: 'Use when the user says they don't need a recommendation for a particular area.' This gives clear guidance on when to invoke the tool. However, it doesn't mention alternatives like 'recommend_reset' for undoing dismissals or exclusions for when not to use it, keeping it from a perfect score.

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 tool performs a reset action (implying mutation) and shows 'what was previously dismissed,' adding some behavioral context. However, it lacks details on permissions, side effects, or response format, leaving gaps 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 concise and front-loaded, consisting of two clear sentences that directly state the tool's action and effect. Every sentence adds value without redundancy, making it efficient 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 complexity (a mutation operation with no annotations and no output schema), the description is adequate but incomplete. It explains the reset action and effect but omits details like return values, error handling, or specific behavioral traits, which are important for a tool that modifies state.

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 1 parameter with 100% description coverage, so the schema already documents it well. The description doesn't add any parameter-specific information beyond what's in the schema, but since there's only one parameter and coverage is high, the baseline is appropriate without needing extra details.

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: 'Reset all dismissed recommendation scenarios' with the effect that 'recommend will detect and suggest tools again for all scenarios.' It specifies the verb ('reset') and resource ('dismissed recommendation scenarios'), but doesn't explicitly differentiate from sibling tools like 'recommend' or 'recommend_dismiss' beyond mentioning their relationship.

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 by stating 'After reset, recommend will detect and suggest tools again for all scenarios,' suggesting it should be used when recommendations need to be re-enabled. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'recommend_dismiss' or 'recommend,' nor does it specify prerequisites or exclusions.

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

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

With no annotations provided, the description carries the full burden. It describes the tool's core behavior (analyzing project context, producing findings from expert viewpoints) and mentions that 'the full project is still scanned for context', which adds useful operational context. However, it doesn't disclose important behavioral traits like whether this is a read-only analysis or makes changes, what permissions are needed, execution time, or output format.

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

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

The description is efficiently structured in three sentences that each earn their place: first states the core purpose, second explains the 'focus' parameter, third explains the 'perspective_group' parameter. No wasted words, front-loaded with the main functionality, and appropriately sized for a 5-parameter tool.

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

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

For a complex analysis tool with 5 parameters and no annotations or output schema, the description provides adequate but incomplete context. It explains the tool's purpose and two key parameters well, but doesn't cover what the output looks like (findings format), whether it's a read-only analysis or has side effects, or how it interacts with the project path. Given the complexity, more behavioral context would be helpful.

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 5 parameters thoroughly. The description adds meaningful context by explaining the purpose of 'focus' ('to zoom in on a specific feature, page, or decision') and 'perspective_group' ('to select a predefined group instead of listing individual perspectives'), which helps the agent understand when and why to use these parameters beyond their technical definitions.

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

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

The description clearly states the tool performs a 'multi-perspective architecture review' that 'analyzes full project context and produces actionable findings from expert viewpoints.' This specifies both the verb (review/analyze/produce) and resource (project architecture), and distinguishes it from siblings like 'coach' or 'idea_score' which have different purposes.

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

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

The description provides clear context about when to use parameters (e.g., 'Use focus parameter to zoom in on a specific feature...', 'Use perspective_group to select a predefined group...'), but doesn't explicitly state when to choose this tool over sibling alternatives like 'coach' or 'recommend'. It gives good parameter usage guidance but lacks tool-level comparison.

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 states this is a save operation (implying mutation/write) and mentions enabling progress tracking, but lacks details on permissions, side effects (e.g., overwriting history), error handling, or response format. For a mutation tool with zero annotation coverage, this is a significant 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 two sentences, front-loaded with the core purpose and followed by usage guidance. Every sentence earns its place by adding value, with zero waste or redundancy. It's appropriately sized for the tool's complexity.

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

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

Given no annotations and no output schema, the description is moderately complete. It covers the purpose and usage context well, but for a mutation tool, it lacks details on behavioral traits like what 'save' entails (e.g., appending vs. overwriting), authentication needs, or return values. The schema handles parameters, but overall completeness is adequate with clear gaps.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (summary and project_path) with good descriptions. The tool description doesn't add any parameter-specific details beyond what's in the schema. With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't need to.

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: 'Save a summary of review findings to the project history.' It specifies the verb (save) and resource (summary to project history). However, it doesn't explicitly distinguish this tool from siblings like 'review' or 'todo_add' that might also involve project tracking, missing full differentiation.

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

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

The description provides clear context for when to use this tool: 'Call this after completing a review to enable progress tracking across reviews.' This gives a specific trigger (post-review) and goal (progress tracking). It doesn't mention when not to use it or name alternatives among siblings, so it's 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 tool sets a target user for reviews and mentions auto-detection as a fallback, which adds context. However, it lacks details on behavioral traits like whether this is a persistent setting, if it requires specific permissions, or what happens on invocation (e.g., error handling). The description doesn't contradict annotations, but it's incomplete for a mutation tool with no annotations.

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

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

The description is appropriately sized and front-loaded: it starts with the core purpose in the first sentence, followed by context and auto-detection details. Both sentences earn their place by clarifying usage without redundancy, making it efficient 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 moderate complexity (2 parameters, no output schema, no annotations), the description is partially complete. It explains the purpose and some usage context but lacks details on behavioral aspects like return values or error conditions. Without annotations or output schema, more information on what happens after setting (e.g., confirmation message) would improve completeness, leaving gaps.

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

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

Schema description coverage is 100%, so the schema already documents both parameters ('target_user' and 'project_path') with clear descriptions. The description adds no additional parameter semantics beyond implying that 'target_user' is used for reviews and auto-detection occurs if not set, but this doesn't enhance the schema's details. With high coverage, the baseline is 3, and the description doesn't compensate with extra value.

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

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

The description clearly states the tool's purpose: 'Set who the target user of this project is.' It specifies the verb ('Set') and resource ('target user'), and explains the function ('used by the customer perspective in reviews to give feedback as that specific type of user'). However, it doesn't explicitly differentiate from sibling tools like 'review' or 'coach', which might involve user perspectives, so it doesn't reach 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 implied usage guidance: it mentions that the target user is 'auto-detected from README/CLAUDE.md if not set manually,' suggesting this tool is for manual override. However, it doesn't explicitly state when to use this vs. alternatives (e.g., when auto-detection fails or for specific review contexts), and no exclusions or sibling tool comparisons are provided, so it's 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 provided, the description carries full burden and does well by disclosing key behavioral traits: it produces a specific output format ('plain language' with coverage details, failure explanations, and manual verification needs), generates a time-bound deliverable ('15-minute manual test script'), and implies transformation of technical input into non-technical output. It doesn't mention error handling, rate limits, or authentication needs.

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 perfectly front-loaded with the core purpose in the first sentence, followed by specific output details. Every sentence earns its place by adding distinct value: purpose, audience, output components, and deliverable specification. 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?

Given 2 parameters with 100% schema coverage and no output schema, the description provides good contextual completeness for a transformation tool. It clearly explains what the tool produces and for whom, though it could benefit from mentioning error cases or what happens when test_output is empty beyond the schema's note about Callout prompting.

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 parameters thoroughly. The description doesn't add meaningful semantic context beyond what's in the schema descriptions - it mentions 'test results' which aligns with 'test_output' but provides no additional parameter guidance. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the specific action ('translate test results into plain language'), the target resource ('test results'), and the intended audience ('non-technical founder'). It distinguishes from sibling tools by focusing on test result interpretation rather than general help, coaching, or task management functions.

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

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

The description provides clear context about when to use this tool ('translate test results into plain language' for 'non-technical founder'), but doesn't explicitly state when not to use it or name specific alternatives among the sibling tools. The guidance is sufficient to understand the primary use case but lacks explicit 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?

With no annotations provided, the description carries full burden for behavioral disclosure. While 'Add' implies a write operation, it doesn't specify whether this requires authentication, what happens on duplicate items, if there are rate limits, or what the response looks like (success/failure indicators). The description mentions the source of items but lacks other critical behavioral context 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 two concise sentences that get straight to the point. The first sentence states the core purpose, and the second provides usage context. There's no wasted verbiage or unnecessary elaboration. However, it could be slightly more structured by explicitly separating purpose from guidelines.

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

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

For a mutation tool with 5 parameters, 80% schema coverage, and no output schema, the description is minimally adequate. It covers the basic purpose and provides some usage context, but lacks important behavioral information about authentication, error handling, and response format. The absence of annotations increases the burden on the description, which it doesn't fully meet.

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 80% (4 out of 5 parameters have descriptions), so the baseline is 3. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions 'findings from review and coach' which loosely relates to the 'source' parameter but doesn't provide additional semantic context about parameter usage or relationships.

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 ('Add') and resource ('item to the project todo list'), making the purpose immediately understandable. It distinguishes from sibling tools like 'todo_list' (which likely lists items) and 'todo_update' (which likely modifies existing items). However, it doesn't explicitly differentiate from 'save_review_findings', which might have overlapping functionality.

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 some context by stating 'All findings from review and coach should be added here', which implies usage after those processes. However, it doesn't explicitly state when NOT to use this tool or mention alternatives like 'todo_update' for modifying existing items. The guidance is implied rather than comprehensive.

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 mentions that the tool shows items with optional filtering, but doesn't cover critical aspects like whether it's read-only, how results are returned (e.g., pagination, format), or any limitations (e.g., rate limits, authentication needs). For a retrieval tool with zero annotation coverage, this is a significant 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 that front-loads the core purpose ('Show all todo items') and adds a concise qualifier about filtering. There is no wasted language, making it appropriately sized 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?

Given the tool's complexity (3 parameters, no output schema, no annotations), the description is incomplete. It lacks details on behavioral traits, doesn't fully cover parameters (e.g., 'project_path' is unexplained), and provides no output information. For a tool with moderate complexity and no structured support, this leaves significant gaps for an agent.

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

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

The description adds minimal value beyond the input schema. It mentions optional filtering by status or priority, which aligns with two parameters, but doesn't explain the 'project_path' parameter (33% of parameters lack schema descriptions). With 67% schema description coverage, the baseline is 3, and the description doesn't compensate for the undocumented 'project_path' parameter.

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 ('Show') and resource ('all todo items'), making the purpose understandable. It distinguishes from siblings like 'todo_add' (creation) and 'todo_update' (modification) by focusing on retrieval. However, it doesn't explicitly differentiate from 'todo_summary', which might also involve listing items, making it slightly less specific.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'todo_summary' or other filtering methods. It mentions optional filtering but doesn't specify scenarios where filtering is appropriate or when other tools might be better suited, leaving the agent with minimal 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?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool 'shows' information (implying read-only) and provides counts and priority items, but doesn't address permissions needed, rate limits, whether it's real-time or cached data, or what format the output takes. Significant behavioral gaps remain.

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 - just two brief sentences that efficiently convey the core functionality. Every word earns its place with no wasted text, and the information is front-loaded appropriately.

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 summary tool with 1 parameter and no output schema, the description covers the basic purpose adequately. However, it lacks important context about the parameter meaning, output format, and behavioral constraints that would be needed for optimal agent usage.

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 1 parameter with 0% description coverage. The tool description doesn't mention the 'project_path' parameter at all, providing no semantic context beyond what the bare schema offers. However, with only 1 parameter, the baseline is higher than for multi-parameter tools with poor coverage.

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

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

The description clearly states the tool's purpose: to provide a 'quick health check' showing counts of items by status (open, in progress, done) and top priority items. It uses specific verbs ('shows') and identifies the resource (todo items), though it doesn't explicitly distinguish from sibling tools like todo_list or todo_add.

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 todo_list. It mentions it's a 'quick health check' which implies a summary view, but doesn't specify when this summary is preferable to a detailed list or other sibling tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While 'update' implies a mutation operation, the description doesn't specify permissions required, whether changes are reversible, error conditions, or what happens to unspecified fields. It lacks critical behavioral context 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, efficient sentence with zero wasted words. It's appropriately sized for a straightforward update operation and front-loads the essential 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 mutation tool with 6 parameters, 33% schema coverage, no annotations, and no output schema, the description is inadequate. It should explain more about the update behavior, error handling, and parameter interactions. The agent lacks sufficient context to use this tool effectively.

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

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

Schema description coverage is only 33% (2 of 6 parameters have descriptions). The description mentions 'status or details' which hints at the status parameter and suggests other fields can be updated, but doesn't explain the semantics of title, description, priority, or project_path parameters. It adds marginal value beyond the schema but doesn't compensate for the low coverage.

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

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

The description clearly states the verb ('update') and resource ('todo item'), specifying what fields can be modified ('status or details'). It distinguishes from sibling tools like todo_add and todo_list by focusing on modification rather than creation or listing. However, it doesn't explicitly differentiate from other potential update operations in the system.

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 doesn't mention prerequisites, when not to use it, or how it relates to sibling tools like todo_add or todo_list. The agent must infer usage from the tool name alone.

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