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

Annotations only provide a title ('Close Task'), so the description carries the burden of behavioral disclosure. It indicates this is a mutation tool (closing implies state change) and adds context about user confirmation requirements. However, it doesn't describe what 'closing' entails (e.g., irreversible, affects status), rate limits, or error conditions, leaving 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 that are front-loaded with the purpose and followed by critical usage rules. Every word serves a clear function with zero waste, making it highly 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 simple mutation with one parameter), no output schema, and minimal annotations, the description covers purpose and usage well. It lacks details on behavioral effects (e.g., what closing does) and error handling, but for this context, it's mostly 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 the parameter 'uuid' documented as 'The uuid of the task to close'. The description doesn't add any parameter-specific information beyond this, so it meets the baseline for high schema coverage without 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 action ('Closes') and resource ('the task'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential siblings like 'set_project' that might also modify task states, so it doesn't reach the highest 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?

The description provides explicit usage instructions: 'Use this tool only if the user ask you to close the task. DO NOT use this tool until the user confirms the task is complete.' This clearly defines when to use (user request + confirmation) and when not to use (without confirmation), offering strong 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?

Annotations only provide a title ('Get Current Project'), offering no behavioral hints. The description adds that this is a fetch operation for the 'currently selected' project, implying it returns read-only data about an existing state. However, it doesn't disclose what details are included, error conditions, or authentication requirements, leaving behavioral gaps despite the simple nature of the 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 that front-loads the core purpose ('Fetch details of the currently selected Webvizio project') with zero wasted words. Every element earns its place by specifying the action, target, and context without 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?

Given the tool's simplicity (0 parameters, no output schema, minimal annotations), the description is adequate but has clear gaps. It explains what the tool does but doesn't cover what details are returned, error handling, or how 'currently selected' is determined. For a tool with no output schema, more information about return values 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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose. A baseline of 4 is justified as the description compensates for the lack of parameters by clearly stating what the tool does without unnecessary parameter 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 action ('Fetch details') and target resource ('currently selected Webvizio project'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_projects' or 'set_project', which would require mentioning this tool retrieves only the currently active project rather than listing all projects or modifying one.

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 'get_projects' (which lists all projects) or 'set_project' (which changes the active project). It lacks explicit when/when-not instructions or prerequisites, leaving the agent to infer usage context from the tool name alone.

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

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

Annotations are minimal (only a title), so the description carries more burden. It implies a read operation ('Fetch'), which aligns with no destructive hints, but doesn't disclose behavioral traits like pagination, rate limits, or authentication needs. It adds basic context but lacks depth.

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 directly states the tool's function without unnecessary words. It's front-loaded and wastes no space, 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.

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

Given the tool's simplicity (0 parameters, no output schema, minimal annotations), the description is adequate but incomplete. It doesn't explain what 'all available' entails (e.g., scope, filtering) or the return format, leaving gaps for an agent to infer behavior.

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

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

With 0 parameters and 100% schema description coverage, the schema fully documents the absence of inputs. The description doesn't need to add parameter details, so it appropriately avoids redundancy, earning a baseline score for tools with no 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 verb ('Fetch') and resource ('Webvizio projects'), making the purpose evident. However, it doesn't distinguish this tool from sibling tools like 'get_current_project' or 'get_tasks', which also retrieve project/task-related data, so it misses 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?

No guidance is provided on when to use this tool versus alternatives such as 'get_current_project' for a specific project or 'get_tasks' for tasks within projects. The description lacks context about usage scenarios or exclusions, offering minimal direction.

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

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

Annotations are minimal (only a title), so the description carries the burden of behavioral disclosure. It describes the tool as a 'fetch' operation, implying read-only behavior, which aligns with common expectations for such tools. However, it doesn't add rich behavioral context beyond this, such as rate limits, error handling, or what specific data 'Repro steps' includes. With no annotations to contradict, it meets a baseline but lacks depth.

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, consisting of two sentences that efficiently convey purpose and usage guidelines. Every sentence adds value: the first defines what the tool does, and the second provides clear when-to-use instructions. There is no redundant or unnecessary information, making it easy for an AI agent to parse and understand.

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 (simple fetch operation with one parameter), minimal annotations, and no output schema, the description is reasonably complete. It covers purpose and usage guidelines effectively. However, it lacks details on output format (e.g., what 'Repro steps' look like) and doesn't address potential edge cases, which could be helpful for an AI agent. Overall, it's sufficient but not exhaustive.

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 the 'uuid' parameter clearly documented as 'The uuid of the task to get the action logs for.' The description doesn't add any additional semantic details about parameters beyond what the schema provides, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema handles the parameter documentation adequately.

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: 'Fetches the task action logs (Repro steps) which have been added to the task.' It specifies the verb ('fetches'), resource ('task action logs'), and clarifies that these are 'Repro steps.' However, it doesn't explicitly differentiate from sibling tools like 'get_task_description' or 'get_task_prompt,' which also fetch task-related information, leaving some ambiguity about when to choose this specific tool over others.

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

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

The description provides explicit usage guidelines: 'Use this tool if the task prompt lacks sufficient information for execution. Do not use this tool if the task and its solution methods are entirely clear from the task prompt.' This clearly defines when to use it (insufficient info) and when not to use it (clear info), offering practical guidance for an AI agent.

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

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

Annotations only provide a title, so the description carries the full burden. It discloses the tool's purpose (fetching logs) and usage context, but lacks details on behavioral traits like rate limits, authentication needs, or response format. It adds some context (logs are 'added to the task') but is minimal beyond basic functionality.

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 usage guidelines. Both sentences earn their place by providing essential information without redundancy, making it efficiently structured and appropriately 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?

Given the tool's low complexity (1 parameter, no output schema, simple annotations), the description is mostly complete: it clarifies purpose, usage, and context. However, it lacks details on output (e.g., log format or structure), which would be helpful since there's no output schema, leaving a minor gap in full 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?

Schema description coverage is 100%, so the schema already documents the 'uuid' parameter fully. The description does not add any meaning beyond what the schema provides (e.g., no extra context about UUID format or source), resulting in a baseline score of 3 as the schema handles 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 ('fetches') and resource ('task console logs/Browser console logs'), and distinguishes it from siblings by specifying the type of logs (console vs. network/action logs from other tools). It precisely defines what the tool retrieves.

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 ('if the task prompt lacks sufficient information for execution') and when not to use ('if the task and its solution methods are entirely clear from the task prompt'), directly addressing alternative scenarios without naming specific sibling tools but offering clear decision 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 description doesn't add behavioral context beyond what's implied by 'fetches' (a read operation). With no annotations provided, it fails to disclose potential constraints like authentication requirements, rate limits, or error conditions. However, it doesn't contradict any annotations either.

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 concise with two clear sentences that each serve distinct purposes: stating the tool's function and providing usage guidelines. There's no wasted language or redundancy, 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?

For a single-parameter read operation with no output schema, the description provides adequate context about when to use it versus alternatives. However, it could better explain what a 'task description' contains compared to a 'task prompt' to help the agent understand the return value despite the missing output schema.

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

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

With 100% schema description coverage, the input schema already documents the single 'uuid' parameter thoroughly. The description adds no additional parameter information beyond what the schema provides, meeting the baseline expectation but not enhancing 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 action ('fetches') and resource ('task description'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'get_task_prompt' beyond usage context, missing an opportunity to explain what distinguishes a 'task description' from a 'task prompt' in this 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 explicit guidance on when to use this tool ('only if the user ask you to provide the task description') and when to use an alternative ('If you need information for task execution, use get_task_prompt tool instead'). This directly addresses the agent's decision-making needs with clear boundaries.

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 beyond a title, so the description carries the full burden. It describes the tool's purpose and usage conditions but does not disclose behavioral traits like rate limits, authentication needs, or what data is returned. However, it adds useful context about when to fetch logs, compensating partially.

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 with two sentences, front-loaded with the purpose and followed by usage guidelines, with 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?

Given the tool's moderate complexity (fetching logs) and lack of annotations or output schema, the description is fairly complete with purpose and usage guidelines, but could improve by hinting at return values or behavioral traits.

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 the 'uuid' parameter. The description does not add any meaning beyond what the schema provides, such as format examples or constraints, but meets the baseline for high 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 specific action ('Fetches') and resource ('task network logs (Network requests)'), and distinguishes it from siblings like get_task_console_logs or get_task_action_logs by specifying the type of logs (network requests).

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 ('if the task prompt lacks sufficient information for execution') and when not to use ('if the task and its solution methods are entirely clear from the task prompt'), providing clear context and exclusions without naming 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 beyond title, so description carries full burden. It discloses behavioral traits like UUID extraction from URLs and fallback to get_tasks, though it doesn't mention error handling, rate limits, or authentication needs. No contradiction with annotations.

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

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

Front-loaded with core purpose, followed by usage scenarios. Sentences are purposeful, though slightly wordy in explaining UUID extraction scenarios. Overall efficient with no redundant information.

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

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

For a single-parameter read tool with no output schema, the description provides good context on usage, input handling, and alternatives. It could benefit from mentioning response format or error cases, but covers most essential aspects given the simplicity.

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

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

Schema description coverage is 100% with one parameter (uuid) well-documented. The description adds context about how to obtain the UUID (from name, number, or link extraction), but doesn't provide additional semantic meaning beyond what the schema already states about the parameter's purpose.

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 'fetches' and the resource 'task prompt' with specific content details ('description of the task and relevant technical data'). It distinguishes from siblings like get_task_description by focusing on the prompt for execution, not just general description.

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

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

Explicitly states when to use ('whenever a user requests the execution of a specific task') and provides alternatives (use get_tasks if UUID cannot be obtained). It gives detailed scenarios for different input types (name, number, link) and specific instructions for link handling.

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

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

Annotations only provide a title ('Get Tasks'), so the description carries the full burden. It discloses behavioral traits such as the tool fetching a list (implying read-only, non-destructive), formatting instructions ('Display received tasks as <task number>: <title>'), and exclusions ('Do not show the UUID'), adding valuable context beyond basic functionality.

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, starting with the core purpose. Each sentence adds value: usage guidelines, formatting instructions, and an example. However, the formatting details could be slightly more concise, and the structure is clear but not perfectly optimized.

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

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

Given the tool's low complexity (0 parameters, no output schema, simple annotations), the description is largely complete. It covers purpose, usage, and behavioral aspects like formatting. A minor gap is the lack of details on response structure (e.g., list format or error handling), but this is acceptable for a straightforward tool.

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

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

With 0 parameters and 100% schema description coverage, the baseline is 4. The description adds no parameter-specific information, which is appropriate since there are no parameters to document, and it doesn't need to compensate for any 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 with a specific verb ('fetches') and resource ('users task list'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_current_project' or 'get_projects' which might also retrieve task-related information, though the focus on 'task list' provides some implicit 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 explicit guidance on when to use this tool: 'if a user asks to see their tasks' and 'if the user wants to execute a specific task but you don't have its UUID to use with the get_task_prompt tool.' It also mentions an alternative ('get_task_prompt') and specifies a use case for lacking UUIDs, offering clear context for 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?

The description adds valuable behavioral context beyond annotations (which only provide a title). It explains that screenshots are automatically generated on task creation, include a lilac marker for element location, and may have additional hints from the author. This helps the agent understand what to expect without contradicting any 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 well-structured and front-loaded, starting with the core purpose and then providing usage guidelines. Every sentence adds value—explaining screenshot features, use cases, and exclusions—with no redundant or unnecessary information.

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

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

Given the simple input schema (one parameter with full coverage) and no output schema, the description provides sufficient context for a read-only tool. It covers purpose, behavioral details, and usage guidelines, though it doesn't specify output format or error handling, which would be helpful but not critical here.

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

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

With 100% schema description coverage, the input schema already fully documents the 'uuid' parameter. The description does not add any additional parameter-specific information beyond what the schema provides, so it meets the baseline expectation without 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 verb 'fetches' and the resource 'task screenshot', distinguishing it from sibling tools like get_task_description or get_task_prompt. It specifies that this tool retrieves a visual representation with specific markers, making its purpose distinct 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 provides explicit guidance on when to use ('if the task prompt lacks sufficient information', 'for tasks related to layout or resolving visual bugs') and when not to use ('Do not use this tool if the task and its solution methods are entirely clear from the task prompt'). This clearly differentiates it from alternatives like get_task_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 beyond a title, so the description carries the full burden of behavioral disclosure. It indicates a mutation action ('Set'), implying changes to state, but doesn't specify effects (e.g., persistence, side effects, or error conditions). It adds minimal context beyond the basic action.

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

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

The description is a single, clear sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration.

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 and output schema, the description is insufficient for a mutation tool. It doesn't explain what 'setting a project' entails (e.g., session persistence, effects on other operations), leaving gaps in understanding the tool's behavior and implications.

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 the 'uuid' parameter fully documented. The description doesn't add any meaning beyond what the schema provides, such as explaining what a 'uuid' is or where to find it, but the high schema coverage justifies the baseline score.

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

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

The description clearly states the action ('Set') and the resource ('current Webvizio project'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_current_project' or 'get_projects', which would require a more detailed comparison.

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 'get_current_project' or 'get_projects', nor does it mention prerequisites or exclusions. It simply states what the tool does without contextual usage information.

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