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

No annotations are provided, so the description carries the full burden. It mentions the action ('Activate') and effect ('bring to front'), but does not disclose behavioral traits such as whether this requires specific permissions, if it affects other applications, or any side effects like interrupting current processes. 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 a single, efficient sentence that front-loads the core action and effect with zero wasted words. It is appropriately sized for a simple, parameterless tool, 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 simplicity (0 parameters, has output schema), the description is minimally adequate but lacks depth. It does not explain what 'activate' entails beyond 'bring to front', nor does it cover potential errors or the output format. With no annotations and an output schema present, more context on behavior 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 tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add parameter semantics beyond the schema, but with no parameters, a baseline score of 4 is appropriate as it avoids unnecessary 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 specific action ('Activate iTerm2') and the effect ('bring to front'), using a precise verb+resource combination. It distinguishes itself from sibling tools like 'app_get_focus' or 'window_focus' by explicitly targeting the application activation rather than window or session focus.

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

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

The description implies usage when iTerm2 needs to be brought to the foreground, but it does not explicitly state when to use this tool versus alternatives like 'window_focus' or 'session_focus'. No guidance on prerequisites or exclusions is provided, leaving usage context partially inferred.

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 retrieves information (a read operation), which is useful, but it does not add behavioral details such as permissions needed, rate limits, or what specific data is returned (though an output schema exists). The description is accurate but lacks rich 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, efficient sentence that directly states the tool's function without any wasted words. It is front-loaded with the core action and resource, making it highly concise and well-structured for quick understanding.

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 annotations) and the presence of an output schema, the description is complete enough for a read-only information retrieval tool. It clearly states what information is retrieved, though it could benefit from mentioning the output schema's role in detailing return values, but this is not required.

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 the input schema has 100% coverage, so no parameter information is needed. The description does not mention parameters, which is appropriate, earning a baseline score of 4 as it avoids redundancy and focuses on the tool'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 'Get' and the resource 'information about the currently focused window, tab, and session', making the purpose specific and actionable. However, it does not explicitly differentiate from sibling tools like 'window_focus' or 'session_focus', which focus on changing focus rather than retrieving information, so it falls short of a perfect score.

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

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

The description implies usage when information about the current focus is needed, but it does not provide explicit guidance on when to use this tool versus alternatives like 'window_list' or 'session_list' for broader information. No exclusions or prerequisites are mentioned, leaving usage context somewhat vague.

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 the dual get/set functionality and lists theme options, but lacks details on permissions needed, whether changes are persistent, side effects, or error handling. For a tool that can modify application state, 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 efficiently structured: a clear purpose statement followed by a focused 'Args' section. Every sentence earns its place by providing essential information without redundancy. It's front-loaded with the core functionality and 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 the tool's moderate complexity (dual get/set operation), no annotations, and an output schema present (which handles return values), the description is reasonably complete. It covers the parameter semantics well and states the purpose clearly. However, it lacks behavioral details like persistence or permissions, which would be helpful for a mutation-capable tool.

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

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

The schema description coverage is 0%, so the description must compensate. It fully explains the single parameter 'value': its purpose (theme to set), valid enum-like values (light, dark, etc.), and the semantic meaning of omitting it (to get current theme). This adds substantial meaning beyond the bare schema, though it doesn't cover all possible edge cases.

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: 'Get or set the iTerm2 theme.' It specifies the verb ('get or set') and resource ('iTerm2 theme'), making the functionality unambiguous. However, it doesn't explicitly differentiate from siblings like 'profile_apply' or 'profile_show' that might also affect appearance, which prevents a perfect score.

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

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

The description provides implied usage guidance: omit the 'value' parameter to get the current theme, include it to set a theme. It lists valid theme values, which helps in decision-making. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., 'profile_apply' for broader settings) or mention any prerequisites, leaving some ambiguity.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, the description doesn't specify whether this requires permissions, has side effects, or details about the return format (though an output schema exists). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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

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

The description is a single, clear sentence with zero wasted words. It is front-loaded with the essential action and resource, making it highly efficient 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 simplicity (0 parameters, output schema provided), the description is reasonably complete for its purpose. However, the lack of behavioral details (e.g., permissions, side effects) and usage guidelines slightly reduces completeness, though the output schema mitigates some of this by handling return values.

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 the input schema coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't mention parameters, which aligns with the schema. A baseline of 4 is given since no parameters exist, and the description doesn't add unnecessary 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 with a specific verb ('Get') and resource ('iTerm2 version'), making it immediately understandable. However, it doesn't distinguish this tool from potential siblings like 'app_get_focus' or 'app_theme' beyond the specific resource, which prevents a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (e.g., 'app_get_focus', 'app_theme'), there is no indication of context, prerequisites, or exclusions for selecting this tool over others.

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

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

With no annotations provided, the description carries full burden and does well: it explains sequential execution, the special 'sleep' operation, error handling with 'stop_on_error', and the return format. It doesn't mention rate limits, authentication needs, or side effects, but covers core behavioral aspects adequately.

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?

Well-structured and appropriately sized: starts with core purpose, details parameters with examples, and ends with return format. Every sentence adds value, with no redundancy or fluff. The example batch is particularly helpful for understanding.

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 (batch execution with many operation types), no annotations, and 0% schema coverage, the description is remarkably complete. It explains purpose, parameters, behavior, and includes an output schema (Returns section), making it fully self-contained 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?

Schema description coverage is 0%, so the description must compensate fully. It provides detailed semantics for both parameters: 'operations' with available ops, examples, and sleep syntax, and 'stop_on_error' with its effect. This adds substantial meaning beyond the bare schema.

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

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

The description clearly states the tool's purpose: 'Execute a batch of iTerm2 operations sequentially within a single connection.' It specifies the verb ('execute'), resource ('batch of iTerm2 operations'), and distinguishes from siblings by handling multiple operations together rather than individual actions like session_run or window_new.

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 when to use this tool (for executing multiple operations sequentially) but doesn't explicitly state when to use it versus individual sibling tools. It mentions 'within a single connection' which provides some context, but lacks explicit alternatives 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 full burden but offers minimal behavioral context. It states the tool creates something but doesn't disclose what happens after creation (e.g., whether the group is immediately active, if it persists across sessions, what permissions are needed, or what the output contains). This is inadequate for a creation tool with zero 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 appropriately brief with two sentences: a purpose statement and parameter explanation. The Args section is clearly separated. However, the title being null and lack of output explanation slightly reduce structural completeness.

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 1 parameter with 0% schema coverage and an output schema exists, the description provides basic purpose and parameter meaning but lacks important context. For a creation tool with no annotations, it should explain more about the broadcast group concept, how it relates to other broadcast tools, and what the creation entails.

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

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

Schema description coverage is 0%, but the description adds basic semantics for the single parameter: 'List of session IDs to include in the broadcast group.' This clarifies what session_ids represents beyond the schema's type information. However, it doesn't explain format constraints, valid session ID sources, or minimum/maximum list size.

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 'Create' and the resource 'broadcast group', specifying it's done 'with specific sessions'. This distinguishes it from siblings like broadcast_on/off which likely toggle broadcast state rather than create groups. However, it doesn't fully differentiate from potential session grouping tools that might exist.

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

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

No guidance is provided about when to use this tool versus alternatives. While siblings include broadcast_on and broadcast_off, the description doesn't explain the relationship between creating a broadcast group and turning broadcast on/off, nor does it mention prerequisites like needing existing sessions.

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 implies a mutation ('Disable'), suggesting this tool changes system state, but doesn't specify effects (e.g., whether it's reversible, impacts on sessions/tabs, or error conditions). No additional context like rate limits or auth needs is included, leaving behavioral traits unclear.

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

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

The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient. Every word earns its place, and there's no 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 tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, as a mutation tool with no annotations, it should ideally explain more about behavioral aspects (e.g., what 'disable' entails, side effects). The output schema helps, but the description could be more complete for clarity.

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 no parameter documentation is needed. The description doesn't add parameter semantics, but this is acceptable given the lack of parameters. A baseline of 4 is appropriate as it avoids redundancy and focuses on the tool's action.

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

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

The description states the action ('Disable') and the resource ('input broadcasting'), providing a basic purpose. However, it doesn't differentiate from sibling tools like 'broadcast_on' or 'broadcast_add', leaving the scope vague. It's clear but lacks specificity about what 'input broadcasting' entails in this context.

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

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

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether broadcasting must be enabled first), exclusions, or related tools like 'broadcast_on' for enabling. The description is standalone with no contextual usage hints.

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 states the action ('Enable input broadcasting') but doesn't explain what 'input broadcasting' entails, what permissions are needed, whether it's reversible, or what side effects occur. For a 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 a single, clear sentence with no wasted words. It's front-loaded with the core action and target, making it immediately understandable. Every word earns its place in conveying 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?

Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, for a tool that enables a potentially impactful feature like 'input broadcasting' with no annotations, the description should provide more context about what this feature does and its implications. The existence of an output schema means return values are documented elsewhere, but behavioral context is lacking.

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 with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter information, and it appropriately doesn't mention any. Baseline 4 is appropriate for zero-parameter tools.

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 ('Enable input broadcasting') and target ('to all sessions in the current tab'), making the purpose immediately understandable. It distinguishes from sibling 'broadcast_off' by indicating the opposite state. However, it doesn't fully differentiate from 'broadcast_add' 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 implies usage context ('in the current tab') but doesn't explicitly state when to use this tool versus alternatives like 'broadcast_off' or 'broadcast_add'. No prerequisites, exclusions, or specific scenarios are mentioned, leaving usage guidance at an implied level.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. While it states what the tool does, it lacks critical behavioral details: whether this requires specific permissions, if the change is reversible, what happens to existing session settings, or potential side effects. The description doesn't mention error conditions, rate limits, or authentication requirements.

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

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

The description is appropriately sized with clear front-loading of the main purpose followed by parameter details. The two-sentence structure is efficient with zero wasted text. However, the parameter documentation could be integrated more seamlessly rather than as a separate Args section.

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

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

Given the tool has an output schema (which handles return values) and only 2 parameters with good description coverage, the description is reasonably complete for basic usage. However, as a mutation tool with no annotations, it should provide more behavioral context about what 'apply' entails, potential impacts, and error scenarios to be fully complete.

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

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

With 0% schema description coverage, the description compensates well by explaining both parameters in the Args section. It clarifies that 'name' is the profile name to apply and 'session_id' is optional with default behavior (omit for active session). This adds meaningful context beyond the bare schema, though it doesn't specify format constraints or valid values.

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 ('apply') and target resource ('an iTerm2 profile to a session'), providing specific verb+resource pairing. It distinguishes from siblings like profile_list and profile_show by focusing on application rather than listing or displaying. However, it doesn't explicitly differentiate from session-related tools that might also affect sessions.

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 through the parameter documentation (session_id omission for active session), but doesn't provide explicit guidance on when to use this tool versus alternatives. No sibling tool comparisons or specific scenarios are mentioned, leaving usage context partially inferred rather than clearly stated.

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 lists profiles but doesn't mention whether this is a read-only operation, if it requires permissions, how results are formatted, or any rate limits. For a 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 a single, efficient sentence that front-loads the core action ('List all iTerm2 profiles') and adds essential details ('with their GUIDs and names'). There is no wasted verbiage, and every word contributes to understanding the tool's function, 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, 100% schema coverage, and an output schema exists), the description is reasonably complete. It specifies what the tool does and what data it returns. However, with no annotations, it could benefit from mentioning behavioral aspects like read-only nature or output format, but the output schema likely covers return values, keeping it adequate.

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, but it implicitly confirms no inputs are required by stating it lists 'all' profiles without filtering. This aligns perfectly with the schema, earning a baseline 4 for parameterless tools.

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 ('List all iTerm2 profiles') and the resources returned ('with their GUIDs and names'). It distinguishes itself from sibling tools like 'profile_apply' and 'profile_show' by focusing on listing rather than applying or displaying individual profiles, making the purpose unambiguous and well-differentiated.

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. While it implies usage for retrieving profile information, it doesn't mention prerequisites, exclusions, or when to choose other tools like 'profile_show' for specific profiles, leaving the agent without contextual usage instructions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool shows detailed information, implying a read-only operation, but doesn't specify what 'detailed information' includes (e.g., profile settings, colors, commands), whether it requires specific permissions, or how errors are handled. For a tool with no 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 appropriately sized and front-loaded, with the main purpose stated clearly in the first sentence and parameter details following. There's no wasted text, though the structure is basic. It could be slightly more polished but remains efficient.

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

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

Given the tool's low complexity (1 parameter), the presence of an output schema (which handles return values), and no annotations, the description is reasonably complete. It covers the core purpose and parameter, though it could improve by adding usage context or behavioral details. For a simple read operation, it's adequate but not comprehensive.

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 semantics beyond the input schema: it explains that the 'name' parameter is 'The profile name,' which is slightly more informative than the schema's title 'Name.' However, with 0% schema description coverage, the description doesn't fully compensate by detailing format, constraints, or examples. The baseline is 3 due to the single parameter being straightforward, but it lacks depth.

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 detailed information') and resource ('about an iTerm2 profile'), making the purpose specific and understandable. It distinguishes from sibling tools like 'profile_list' (which lists profiles) and 'profile_apply' (which applies profiles), though it doesn't explicitly name these alternatives. However, it lacks explicit sibling differentiation, preventing a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'profile_show' instead of 'profile_list' or other profile-related tools, nor does it specify prerequisites or exclusions. This leaves the agent without contextual usage instructions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what the tool does (sends Ctrl+L to clear screen) and the optional parameter behavior (omit for active session). However, it doesn't mention potential side effects, error conditions, permissions needed, or what happens if the session_id is invalid. The description adds basic context but lacks comprehensive behavioral details.

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?

Perfectly structured with a clear purpose statement followed by parameter documentation. Every sentence earns its place: the first sentence explains what the tool does, the second explains parameter behavior. No wasted words, appropriately sized for a simple 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?

Given this is a simple action tool with one optional parameter and an output schema exists (though not shown), the description is nearly complete. It explains the action, parameter usage, and default behavior. The main gap is lack of information about return values or error conditions, but the output schema should cover that. For a Ctrl+L screen clear operation, this is appropriately 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 0%, so the description must fully compensate. It provides complete parameter semantics: explains what session_id is ('Target session ID'), documents the default behavior ('Omit for the active session'), and clarifies the parameter is optional. This adds significant value beyond the bare schema which only shows the parameter name and type.

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 ('Clear the screen') and the target resource ('an iTerm2 session'), with precise implementation detail ('sends Ctrl+L'). It distinguishes itself from sibling tools like session_close, session_restart, or session_send by focusing solely on screen clearing without affecting session state or sending arbitrary commands.

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: to clear the terminal screen in iTerm2. It doesn't explicitly state when not to use it or name alternatives, but the specificity of the action (Ctrl+L for screen clearing) naturally differentiates it from other session operations like closing, restarting, or sending data.

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 the action ('Close') but does not describe what closing entails (e.g., whether it terminates processes, requires confirmation, or is reversible), potential side effects, or permissions needed. For a destructive operation 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 front-loaded with the core purpose in the first sentence, followed by a concise parameter explanation. Every sentence earns its place by providing essential information without redundancy, making it efficiently structured 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 (destructive action, one parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete behavioral details, it leaves gaps in understanding the full impact of closing a session, making it only partially complete for safe agent use.

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

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

The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'session_id' targets a specific session and can be omitted for the active session, clarifying default behavior and usage. With only one parameter, this compensation is effective, though it doesn't detail format constraints (e.g., ID structure).

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

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

The description clearly states the verb ('Close') and resource ('an iTerm2 session'), making the purpose specific and unambiguous. It distinguishes this tool from sibling tools like session_clear, session_restart, or tab_close by focusing on session termination rather than clearing content, restarting, or closing tabs.

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 by specifying it closes sessions in iTerm2. However, it does not explicitly state when not to use it or name alternatives (e.g., vs. tab_close or window_close for different resources), though the sibling list helps infer distinctions. The guidance is practical but lacks explicit 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 full burden for behavioral disclosure. It states the action ('Focus (activate)') which implies a state change, but doesn't describe what happens visually (e.g., brings session to foreground), whether it requires specific permissions, or what happens if the session doesn't exist. The description adds minimal behavioral 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 extremely concise with zero wasted words. The first sentence states the core purpose, followed by a clean 'Args' section for parameter documentation. Every element serves a clear purpose, making it easy to parse quickly.

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

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

Given the tool has an output schema (which handles return values), 1 parameter with 0% schema coverage (compensated by description), and no annotations, the description is minimally adequate. However, for a state-changing tool in a complex terminal environment, it lacks important context about behavior, error conditions, and relationships to sibling tools.

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

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

The description includes an 'Args' section that documents the single parameter 'session_id' and its purpose ('The session ID to focus'), providing meaningful semantics. Since schema description coverage is 0% and there's only 1 parameter, this adequately compensates, though it doesn't specify format requirements (e.g., where to obtain session IDs from 'session_list').

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 ('Focus (activate)') and target resource ('a specific iTerm2 session'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'window_focus' or 'app_get_focus', which also deal with focus/activation concepts in the same iTerm2 context.

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

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

No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing session), exclusions, or comparisons to related tools like 'session_list' (to find session IDs) or 'window_focus' (for window-level activation).

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 states this is a read operation ('Get'), which is helpful, but doesn't mention important behavioral aspects like what happens if the variable doesn't exist, whether this requires specific permissions, or how the value is returned. The description provides minimal behavioral 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 efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence earns its place, and the information is front-loaded with the core functionality stated first. The Args section is well-organized and adds necessary detail without 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 that there's an output schema (which handles return values), 0% schema description coverage, and no annotations, the description does an adequate job. It covers the basic purpose and parameters but lacks behavioral details about error conditions, permissions, or what types of values might be returned. For a read operation with output schema, this is minimally 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?

With 0% schema description coverage, the description compensates well by explaining both parameters: it defines 'variable' with an example ('session.name', 'session.path') and clarifies the optional nature of 'session_id' with usage guidance. This adds significant semantic value beyond the bare schema, though it could provide more examples of valid variable names.

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

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

The description clearly states the action ('Get the value') and resource ('an iTerm2 session variable'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'session_set_variable' beyond the verb difference, but the verb 'Get' versus 'Set' provides inherent 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 some usage context by explaining when to omit the session_id parameter ('Omit for the active session'), which helps with parameter decisions. However, it doesn't offer guidance on when to use this tool versus alternatives like 'session_list' or 'session_set_variable' for related operations.

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. It discloses that this is a read-only listing operation (implied by 'List'), specifies the scope ('all sessions regardless of mcp_enabled status'), and explains the relationship with other tools (only mcp_enabled sessions can be targeted). It doesn't mention rate limits or authentication needs, but those might not be relevant here.

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?

Perfectly structured with three distinct paragraphs: (1) what the tool does, (2) when to use it and limitations, (3) how to enable sessions for MCP. Every sentence earns its place with no wasted words. The technical command is appropriately included as it's essential context.

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

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

Given this is a simple listing tool with 0 parameters, an output schema exists, and no annotations, the description is complete. It explains purpose, usage context, limitations, and even provides remediation steps for disabled sessions. Nothing essential is missing for this 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?

The tool has 0 parameters with 100% schema description coverage, so the baseline would be 3. However, the description adds value by explaining that no filtering parameters are needed - it lists ALL sessions regardless of status, which is useful semantic context beyond the empty schema.

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

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

The description clearly states the verb 'List' and the resource 'iTerm2 sessions', specifying exactly what data is returned (IDs, names, titles, sizes, TTYs, mcp_enabled status). It distinguishes from siblings like session_focus or session_close by focusing on listing rather than manipulation.

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 this tool ('Shows all sessions regardless of mcp_enabled status so you can see which sessions need to be tagged') and provides clear alternatives ('Only mcp_enabled sessions can be targeted by other tools'). It even includes instructions for enabling sessions for MCP access.

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 clearly indicates this is a read operation (not destructive) and specifies what content is retrieved (visible screen contents). However, it doesn't mention potential limitations like read permissions, rate limits, or what happens with invalid session IDs, leaving some behavioral aspects unclear.

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 a cleanly formatted parameter section. Every sentence earns its place - the first establishes purpose, the parameter explanations provide essential usage context without redundancy.

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

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

Given the tool has an output schema (which handles return values), 2 parameters with full semantic coverage in the description, and no annotations, the description is quite complete. It could be slightly improved by mentioning potential error conditions or clarifying the 'visible screen' scope, but it provides solid foundation for tool 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?

With 0% schema description coverage, the description fully compensates by providing clear semantic explanations for both parameters: session_id ('Target session ID. Omit for the active session.') and lines ('Number of lines to return from the bottom. Omit for all visible lines.'). This adds crucial meaning beyond the bare schema.

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

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

The description clearly states the specific action ('Read the visible screen contents') and target resource ('of an iTerm2 session'), distinguishing it from sibling tools like session_list (which lists sessions) or session_send (which sends input). It uses precise terminology that differentiates its function.

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

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

The description implies usage by specifying what the tool reads (visible screen contents), but doesn't explicitly state when to use it versus alternatives like session_get_variable or session_list. It provides some context through parameter descriptions but lacks explicit guidance on tool selection scenarios.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Restart') but doesn't explain what restarting entails (e.g., does it reload configurations, kill processes, or reset state?), potential side effects, permissions required, or error conditions. This leaves significant gaps in understanding the tool's behavior.

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

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

The description is extremely concise and front-loaded, with the core purpose stated in the first sentence and parameter details in a brief 'Args' section. Every sentence earns its place, and there's no unnecessary information or repetition.

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

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

Given the tool has one parameter with low schema coverage (0%) and an output schema exists (which reduces the need to describe return values), the description is moderately complete. It covers the parameter's optional behavior but lacks details on the restart action's effects, making it adequate but with clear gaps for a mutation tool.

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

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

The description adds meaningful semantics for the single parameter 'session_id' by explaining that omitting it targets the active session, which isn't covered in the input schema (0% schema description coverage). This compensates well for the schema's lack of detail, though it doesn't elaborate on format or validation rules.

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 ('Restart') and resource ('an iTerm2 session'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'session_clear' or 'session_close', which also operate on sessions but perform different actions.

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 by mentioning that omitting 'session_id' targets the active session, which helps understand when to use this parameter. However, it doesn't explicitly state when to use this tool versus alternatives like 'session_clear' (which clears output) or 'session_close' (which terminates), leaving some ambiguity.

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. It discloses that the tool 'sends text + Enter' (execution behavior) and describes parameter-driven targeting (active vs. specific vs. all sessions). However, it doesn't cover permissions needed, error handling, rate limits, or what happens if a session doesn't exist—important for a command execution 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 front-loaded with the core purpose, followed by a well-structured Args section. Every sentence earns its place by clarifying behavior or parameters, with zero redundant or vague language.

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 3 parameters with 0% schema coverage and no annotations, the description does an excellent job explaining parameters and basic behavior. However, as a command execution tool with potential side effects, it could benefit from mentioning output handling (though an output schema exists) or error scenarios to be fully complete.

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

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

Schema description coverage is 0%, so the description must compensate fully. It provides clear semantics for all three parameters: command ('command string to execute'), session_id ('Target session ID. Omit for the active session'), and all_sessions ('If true, run in every session'), adding crucial meaning beyond the bare schema.

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

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

The description clearly states the specific action ('Execute a command') and resource ('in an iTerm2 session'), with additional behavioral detail ('sends text + Enter'). It distinguishes from siblings like session_send (which may not send Enter) and session_read (which reads output).

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 specific parameters (omit session_id for active session, use all_sessions for every session). However, it lacks explicit guidance on when to choose this tool over alternatives like session_send or batch, or any prerequisites for execution.

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. It mentions 'without pressing Enter' which adds useful behavioral context about input handling. However, it fails to disclose critical traits: whether this requires specific permissions, if it's destructive (could send commands that alter session state), rate limits, or error handling. 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 front-loaded with the core purpose in the first sentence, followed by a structured Args section that efficiently explains each parameter. Every sentence earns its place with no redundant or vague language, making it appropriately sized and well-organized.

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 3 parameters with 0% schema coverage and no annotations, the description does well on parameters but lacks behavioral transparency. The presence of an output schema means return values needn't be explained, but for a mutation tool that could affect session state, more context on safety and constraints would improve completeness. It's adequate but has clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all three parameters: text (what to send), session_id (target, with omission rule), and all_sessions (broadcast behavior). This adds meaningful context beyond the bare schema, though it doesn't detail format constraints (e.g., text encoding) or interactions between 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 action ('Send text') and target ('iTerm2 session') with a specific behavioral detail ('without pressing Enter'). It distinguishes from siblings like session_run (which likely executes commands) and session_read (which reads output). However, it doesn't explicitly differentiate from session_set_variable or other text-related tools, keeping it at 4 rather than 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 for sending text to terminal sessions, with parameter hints (e.g., omit session_id for active session) that suggest context. However, it lacks explicit guidance on when to use this versus alternatives like session_run or broadcast tools, and no mention of prerequisites or exclusions, making it only implied rather than clear.

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

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

No annotations are provided, so the description carries full burden. It states the tool sets a name, implying a mutation, but does not disclose behavioral traits such as whether this requires specific permissions, if changes are reversible, potential side effects, or error conditions. The description is minimal and lacks crucial operational 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 appropriately sized and front-loaded with the main purpose in the first sentence, followed by parameter details. It avoids unnecessary fluff, but the parameter explanations could be slightly more integrated into the flow rather than listed separately, though this is minor.

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

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

Given that annotations are absent and there is an output schema (which reduces the need to describe return values), the description is partially complete. It covers the basic purpose and parameters but lacks behavioral transparency and detailed usage guidelines, which are important for a mutation tool with no annotation support, leaving gaps in overall 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?

Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics: 'name' is described as 'The new session name' and 'session_id' as 'Target session ID. Omit for the active session.', which clarifies purpose and default behavior beyond the bare schema. This effectively covers both parameters, though it could provide more detail on format or constraints.

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 the name') and target resource ('an iTerm2 session'), which is specific and unambiguous. However, it does not explicitly differentiate from sibling tools like session_set_variable, which might also modify session properties, leaving room for slight ambiguity in sibling 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 implied context by noting that session_id can be omitted for the active session, suggesting usage when targeting specific or default sessions. However, it lacks explicit guidance on when to use this tool versus alternatives like session_set_variable or other session-related tools, and does not mention any exclusions or prerequisites.

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

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

With no annotations provided, the description carries full burden but offers limited behavioral insight. It implies a mutation operation ('Set'), but doesn't disclose effects like whether changes persist, require specific permissions, or affect session state. No rate limits, error conditions, or output details are mentioned, leaving significant gaps 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 efficiently structured with a clear purpose statement followed by parameter explanations in a bullet-like format. Every sentence adds value, though the 'Args:' section could be integrated more smoothly. It's appropriately sized for a simple tool 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 3 parameters with 0% schema coverage and an output schema present, the description provides basic but incomplete context. It covers parameter purposes minimally and relies on the output schema for return values, but as a mutation tool with no annotations, it should better explain behavioral implications and usage scenarios to be fully adequate.

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

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

Schema description coverage is 0%, but the description adds basic semantic context for all 3 parameters: 'variable' as the name, 'value' as the content to set, and 'session_id' with optionality for active sessions. This compensates somewhat for the schema gap, though it lacks details on variable naming conventions, value formats, or session ID specifics.

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 the value') and target resource ('an iTerm2 session variable'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'session_get_variable' beyond the obvious set/get distinction, missing an opportunity to clarify when to use each.

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 minimal guidance, only noting that 'session_id' can be omitted for the active session. It lacks explicit when-to-use instructions, prerequisites, or comparisons with alternatives like 'session_get_variable' or other session manipulation tools, leaving the agent to infer 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?

No annotations are provided, so the description carries full burden. It states the action ('Split') but lacks behavioral details: it doesn't specify if this requires specific permissions, what happens to the original session, whether the split is reversible, or any rate limits. The description is minimal 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 front-loaded with the core purpose in the first sentence, followed by a structured Args section. Every sentence earns its place by explaining parameters without redundancy, making it efficient and well-organized.

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 3 parameters with 0% schema coverage and no annotations, the description adequately covers parameter semantics but lacks behavioral context (e.g., effects, permissions). An output schema exists, so return values need not be explained. However, for a mutation tool with no annotations, more behavioral disclosure 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?

Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all three parameters: explains what 'vertical' controls (orientation), 'session_id' target (with omission rule), and 'profile' usage (for the new pane). This adds meaningful context beyond the schema's titles and types.

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 ('Split an iTerm2 session into a new pane') with the resource ('iTerm2 session') and outcome ('new pane'). It distinguishes from sibling tools like session_close, session_focus, or tab_new by specifying the pane-splitting 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?

No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites (e.g., requires an active session), exclusions, or comparisons to similar tools like tab_new or window_new for creating new interfaces.

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 states the action ('Close') but lacks critical behavioral details: whether this is destructive (likely yes, but not confirmed), what happens to sessions in the tab, if confirmation is needed, or error conditions. For a mutation 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 front-loaded: the first sentence states the core purpose, followed by a brief, clear parameter explanation. Every sentence earns its place with no wasted words, making it easy to scan 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 moderate complexity (a destructive operation with one optional parameter) and the presence of an output schema (which likely covers return values), the description is minimally adequate. However, it lacks behavioral context (e.g., destructiveness, error handling) and sibling differentiation, leaving gaps that could hinder an agent's correct invocation in a broader 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?

With 0% schema description coverage and 1 parameter, the description fully compensates by explaining 'tab_id' semantics: it specifies the parameter's purpose ('The tab ID to close') and adds crucial behavioral context ('Omit for the current tab'), which the schema alone does not provide. This adds meaningful value beyond the input schema.

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

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

The description clearly states the verb ('Close') and resource ('an iTerm2 tab'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'session_close' or 'window_close', but the specificity of 'tab' provides some implicit distinction. The purpose is not vague, tautological, or misleading.

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 'session_close' or 'window_close', nor does it mention prerequisites or exclusions. The only usage hint is the optional parameter behavior for 'tab_id', which is basic parameter documentation rather than contextual 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?

No annotations are provided, so the description carries the full burden. It describes the tool's behavior as listing tabs with specific attributes, which is helpful, but lacks details on permissions, rate limits, or error handling. No contradictions exist.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by a concise parameter explanation. 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 low complexity (1 optional parameter) and the presence of an output schema, the description is reasonably complete. It covers the purpose and parameter usage adequately, though additional behavioral context (e.g., permissions) could enhance it further.

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

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

The schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'window_id' filters tabs to a specific window and that omitting it lists all windows, which clarifies the parameter's purpose beyond the schema's basic title.

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 ('List') and resource ('all iTerm2 tabs') with specific output details (IDs, window IDs, indices, session counts, active state). It distinguishes from siblings like 'window_list' by focusing on tabs rather than windows.

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 usage with the 'window_id' parameter (omit for all windows, specify for filtered results). However, it does not explicitly state when to use this tool versus alternatives like 'session_list' or 'window_list', though the focus on tabs implies differentiation.

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 states the action ('Move a tab') but lacks details on permissions needed, whether the move is reversible, effects on tab state (e.g., URL, history), or error conditions (e.g., invalid tab_id). This is a significant gap for a mutation tool with zero annotation coverage, though it does hint at default behavior for current tab.

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 action in the first sentence, followed by a concise Args section. Every sentence earns its place by explaining the tool's purpose and parameter usage without redundancy. It's appropriately sized for a simple tool with one parameter.

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 nested objects) and the presence of an output schema (which handles return values), the description is mostly complete. It covers purpose and parameter semantics adequately. However, as a mutation tool with no annotations, it could benefit from more behavioral context (e.g., safety, side effects) to be fully comprehensive.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics: 'tab_id: The tab ID to move. Omit for the current tab.' This clarifies the parameter's purpose, optionality, and default behavior, going beyond the schema's basic title 'Tab Id' and null handling. With only one parameter, this is sufficient to earn a high 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 ('Move a tab') and the outcome ('to its own new window'), providing a specific verb+resource combination. It distinguishes from siblings like tab_close, tab_select, and window_move by focusing on tab relocation rather than closure, selection, or window movement. However, it doesn't explicitly contrast with tab_new or session_split, which could create similar windows.

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 by mentioning 'Omit for the current tab,' suggesting it's for moving either a specific or the active tab. It doesn't provide explicit when-to-use guidance versus alternatives like tab_new (create new tab) or session_split (split pane), nor does it mention prerequisites or exclusions, leaving some ambiguity about optimal use cases.

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 it mentions the basic action of creating a tab, it doesn't describe what happens after creation (e.g., does focus shift to the new tab?), whether there are permission requirements, rate limits, or error conditions. 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 perfectly structured and concise. The first sentence states the core purpose, followed by a well-organized Args section with clear explanations for each parameter. Every sentence earns its place with no wasted words, and the information is front-loaded effectively.

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

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

Given that there's an output schema (which handles return values), 3 parameters with good semantic coverage in the description, and no annotations, the description is mostly complete. It explains what the tool does and how to use parameters effectively. The main gap is in behavioral transparency for a mutation tool, but the presence of an output schema reduces the need to describe return values.

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 provides excellent parameter semantics in the Args section, explaining what each parameter does beyond the schema's basic titles. It clarifies that 'profile' is a name for the new tab, 'window_id' can be omitted for the current window, and 'command' runs in the new tab. With 0% schema description coverage, this fully compensates and adds meaningful 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 specific action ('Create a new tab') and resource ('in an iTerm2 window'), distinguishing it from sibling tools like tab_close, tab_list, or window_new. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.

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

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

The description provides clear context for when to use this tool (creating tabs in iTerm2) and includes usage guidance in the Args section (e.g., 'Omit for the current window'). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools, which prevents 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?

With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention what happens if there's no next tab (e.g., wraps to first, does nothing, or errors), whether it's a read-only operation, or any side effects like focus changes. This leaves significant gaps for an agent to understand tool behavior.

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

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

The description is a single, front-loaded sentence with zero wasted words. It immediately conveys the core functionality without unnecessary elaboration, making it highly efficient and easy for an agent 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 low complexity (0 parameters, simple action) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks behavioral context that would help an agent use it correctly in edge cases, such as what happens with single-tab windows or after execution.

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 with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter semantics, and it correctly implies no parameters are required by not mentioning any. This meets the baseline for zero-parameter tools.

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 ('Switch to') and target resource ('the next tab in the current window'), distinguishing it from sibling tools like tab_prev, tab_select, and tab_list. It uses precise terminology that leaves no ambiguity about what the tool does.

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

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

The description implies usage context by specifying 'in the current window,' which helps differentiate from window-level operations. However, it doesn't explicitly state when to use this versus alternatives like tab_select or tab_prev, nor does it mention prerequisites like requiring an open window with multiple tabs.

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 but only states the basic action. It doesn't disclose behavioral traits like what happens if there's no previous tab, whether it cycles through tabs, or if it requires specific window/tab states to work.

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 front-loaded with the core action and provides exactly the information needed to understand what the tool does.

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, has output schema), the description is reasonably complete for understanding its basic function. However, it could benefit from more behavioral context about edge cases or limitations.

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 with 100% schema coverage, so the schema already fully documents the empty parameter set. The description appropriately doesn't discuss parameters, maintaining focus on the tool'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 specific action ('Switch to') and target resource ('previous tab in the current window'), distinguishing it from siblings like 'tab_next', 'tab_select', and 'tab_list' which perform different tab operations.

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 implicitly indicates usage context (when you want to navigate to the previous tab in a window), but doesn't explicitly state when NOT to use it or name alternatives like 'tab_next' for forward navigation.

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

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

No annotations are provided, so the description carries full burden. It states the action ('Select a tab') which implies a focus/activation operation but doesn't disclose behavioral traits like: whether this changes application focus, what happens if the tab doesn't exist, if there are permission requirements, or what the visual/UI effect is. The description is minimal 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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a clear Args section. Every sentence earns its place by explaining parameter usage without redundancy. No wasted words or 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 2 parameters with 0% schema coverage and an output schema (which handles return values), the description is moderately complete. It explains parameter purposes but lacks context on prerequisites (e.g., need to identify tabs first), error conditions, or integration with sibling tools like tab_list. For a selection tool with no annotations, 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 0%, so the description must compensate. It adds meaningful semantics: explains tab_id_or_index accepts 'Tab ID string, or a numeric index (0-based)' and window_id is for 'index-based selection' and can be 'Omit for the current window'. This clarifies parameter purposes beyond schema types. However, it doesn't explain where to get tab IDs (e.g., from tab_list) or window IDs.

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 ('Select a tab') and the resource ('by its ID or numeric index'), providing specific verb+resource. It distinguishes from sibling tools like tab_list, tab_close, and tab_move by focusing on selection rather than listing, closing, or moving tabs. However, it doesn't explicitly differentiate from tab_next/tab_prev which are also selection tools but with different mechanisms.

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 through parameter explanations: 'Omit for the current window' suggests when to leave window_id unspecified. It doesn't provide explicit when-to-use vs. alternatives like tab_next/tab_prev (sequential navigation) or tab_list (to discover tab IDs). No explicit exclusions or named alternatives are mentioned.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't specify details like whether it returns metadata, pagination, or error conditions. This is a significant gap for a tool with zero annotation coverage.

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

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

The description is a single, efficient sentence that directly states the tool's purpose with zero waste. It's appropriately sized and front-loaded, making it easy to understand at a glance.

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, output schema exists), the description is adequate but incomplete. It covers the basic purpose but lacks behavioral details (e.g., return format) that aren't fully compensated by the output schema alone. This meets minimum viability 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?

The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description appropriately doesn't mention parameters, aligning with the schema. A baseline of 4 is given since it doesn't add unnecessary 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 verb ('List') and resource ('all saved window arrangements'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'window_list' or 'window_arrange_restore', which prevents a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives such as 'window_list' (which might list open windows) or 'window_arrange_restore' (which might restore arrangements). It lacks explicit context or exclusions, leaving usage unclear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('restore') but lacks critical details: whether this requires specific permissions, what happens to current windows (e.g., are they replaced or rearranged?), if it's reversible, or any side effects. For a tool that likely modifies window states, 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 front-loaded, with the core purpose stated in the first sentence and a brief parameter note. There's no wasted text, and the structure is clear, 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 moderate complexity (restoring arrangements implies state changes), no annotations, and an output schema (which might cover return values), the description is incomplete. It lacks behavioral context and usage guidelines, but the presence of an output schema and low parameter count prevents a lower score. It's minimally adequate but has clear gaps.

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

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

The description adds minimal value beyond the input schema. It mentions the 'name' parameter but doesn't explain what constitutes a valid name (e.g., format, constraints, or how to obtain names from 'window_arrange_list'). With 0% schema description coverage and only one parameter, the baseline is 3, as the description doesn't compensate for the lack of schema details but doesn't worsen it either.

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 ('restore') and resource ('saved window arrangement'), making the purpose immediately understandable. It distinguishes itself from siblings like 'window_arrange_save' and 'window_arrange_list' by focusing on restoration rather than creation or listing. However, it doesn't explicitly contrast with other window manipulation tools like 'window_focus' or 'window_move', which slightly limits 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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a saved arrangement via 'window_arrange_save'), exclusions, or how it differs from other window-related tools like 'window_focus' or 'window_resize'. This leaves the agent with minimal context for decision-making.

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 the tool saves arrangements but doesn't explain what 'saving' entails (e.g., persistence format, storage location, whether it overwrites existing arrangements with the same name). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and effects.

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 front-loaded, with the core purpose stated in the first sentence and parameter details following in a clear 'Args:' section. Every sentence earns its place, and there's no redundant or verbose language, making it efficient 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 moderate complexity (saving arrangements), no annotations, and an output schema present, the description is minimally adequate. It covers the basic action and parameter but lacks details on behavioral traits (e.g., how saves are stored) and doesn't leverage the output schema to explain return values. It's complete enough for basic use but has clear gaps for informed tool selection.

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 meaningful context for the single parameter 'name' by specifying it's 'Name for the saved arrangement,' which clarifies its purpose beyond the schema's basic 'Name' title. With 0% schema description coverage and only one parameter, this compensates well, though it doesn't detail constraints like length or allowed characters. A baseline of 4 is appropriate for a single parameter with good semantic clarification.

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 ('Save') and resource ('current window arrangement'), making the purpose immediately understandable. It distinguishes from sibling tools like 'window_arrange_list' and 'window_arrange_restore' by focusing on saving rather than listing or restoring arrangements. However, it doesn't explicitly differentiate from all siblings (e.g., 'window_close', 'window_move'), 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing window arrangement to save), exclusions, or comparisons to sibling tools like 'window_arrange_restore' for loading saved arrangements. Usage is implied from the name and description but not explicitly stated.

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 the action ('Close') but does not disclose critical behavioral traits such as whether this operation is destructive (e.g., if closing a window terminates processes), requires specific permissions, has side effects, or provides confirmation. 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 appropriately sized and front-loaded, with the core purpose stated in the first sentence and parameter details following in a clear, bullet-like format. Every sentence earns its place by providing essential information 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 complexity (a mutation with one parameter) and the presence of an output schema (which reduces the need to explain return values), the description is moderately complete. However, it lacks details on behavioral aspects (e.g., destructiveness) and does not fully compensate for the absence of annotations, leaving gaps in understanding the tool's impact.

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 meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'window_id' identifies the window to close and specifies that omitting it targets the current window, clarifying default behavior not evident from the schema alone. With only one parameter, this compensation is effective, though it could detail format or constraints.

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 ('Close') and resource ('an iTerm2 window'), distinguishing it from sibling tools like 'tab_close' or 'session_close' by specifying it operates on windows rather than tabs or sessions. It provides a complete verb+resource combination that is 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 clear context for usage by explaining that the window_id parameter can be omitted to close the current window, which implies when to use this tool. However, it does not explicitly mention when not to use it or name alternatives (e.g., compared to 'tab_close' or 'session_close'), so it falls short of 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 of behavioral disclosure. It states the action ('Focus (activate)') but lacks details on effects (e.g., whether it brings the window to foreground, changes focus in the OS, or requires specific permissions), error handling, or response format, which is insufficient 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 front-loaded with the core purpose in the first sentence, followed by a brief parameter note. It avoids redundancy and is appropriately sized for a simple tool, though the parameter section could be integrated more seamlessly.

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) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks behavioral context (e.g., effects, errors) and usage guidance, leaving gaps that reduce completeness for effective agent use.

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

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

Schema description coverage is 0%, but the description adds minimal value by naming the parameter ('window_id') and stating it's 'The window ID to focus.' This clarifies the parameter's purpose but does not provide format details (e.g., numeric vs. string, how to obtain it from window_list) or constraints, resulting in a 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 specific action ('Focus (activate)') and resource ('a specific iTerm2 window'), distinguishing it from sibling tools like window_list, window_close, or window_resize. It precisely communicates the tool's function without ambiguity.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a valid window_id from window_list), exclusions, or comparisons to similar tools like session_focus or app_activate, leaving usage context unclear.

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 it mentions the action ('Set fullscreen state'), it doesn't describe what happens when the state changes (e.g., visual effects, impact on other windows), whether this requires specific permissions, or potential side effects. The description is minimal and lacks behavioral 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 extremely concise and well-structured. The first sentence states the purpose clearly, followed by a brief but complete parameter explanation in bullet-point style. Every sentence earns its place with no wasted words, 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 moderate complexity (2 parameters, one optional), no annotations, but with an output schema present, the description is reasonably complete. It covers the core functionality and parameters adequately. The output schema means return values don't need explanation in the description, though additional behavioral context would improve completeness for a state-changing operation.

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

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

Schema description coverage is 0%, so the description must compensate. It effectively documents both parameters: 'state' with its allowed values ('on', 'off', 'toggle') and 'window_id' with its optional nature and default behavior ('Omit for the current window'). This adds crucial semantic meaning beyond the bare schema, though it doesn't explain parameter interactions or edge cases.

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 ('Set fullscreen state') and resource ('for an iTerm2 window'), making the purpose specific and unambiguous. It distinguishes this tool from siblings like window_focus or window_resize by focusing on fullscreen functionality rather than other window operations.

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 fullscreen state changes are appropriate, or how it relates to other window management tools in the sibling list. The only implied usage is for setting fullscreen state, but no context is given.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what data is returned but lacks details on permissions, rate limits, error handling, or whether the list is real-time or cached. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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

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

The description is a single, efficient sentence that front-loads the key action and details without any wasted words. It directly communicates the tool's purpose and output in a structured manner.

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), high schema coverage (100%), and presence of an output schema, the description is reasonably complete. It specifies the output content, though it could benefit from more behavioral context given the lack of annotations.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately omits parameter details, focusing instead on the tool's output, which aligns with the high schema coverage baseline.

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

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

The description clearly states the action ('List') and the resource ('iTerm2 windows'), specifying exactly what information is returned (IDs, tab counts, positions, sizes, fullscreen state). It distinguishes from siblings like 'window_focus' or 'window_new' by focusing on enumeration rather than manipulation.

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. While it's implied for listing windows, there's no mention of prerequisites, context (e.g., after creating windows), or comparisons to similar tools like 'session_list' or 'tab_list' for related information.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. While it states what the tool does (move window), it doesn't mention important behavioral aspects like whether this requires specific permissions, whether the move is immediate or animated, what coordinate system is used (screen vs. display), or error conditions. The description provides basic operation but lacks behavioral 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 appropriately sized with clear front-loading of the main purpose followed by parameter details. The Args section is structured but could be more integrated. Every sentence serves a purpose, though the formatting could be slightly more polished.

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, 3 parameters, 0% schema coverage, but with an output schema present, the description is moderately complete. It explains the core operation and parameters adequately but lacks behavioral context about side effects, error handling, or coordinate system details that would be important for safe use.

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

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

With 0% schema description coverage, the description compensates well by explaining all three parameters: x and y as pixel coordinates with reference points (from left/top), and window_id with its optional behavior (omit for current window). This adds meaningful semantic context beyond the bare schema types, though it doesn't specify coordinate range limits or window_id format.

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 ('Move an iTerm2 window') and the target ('to a specific screen position'), distinguishing it from sibling tools like window_resize, window_focus, or window_close. It uses precise verb+resource language that leaves no ambiguity about the tool's function.

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

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

The description implies usage context through the parameter documentation (window_id defaults to current window), but doesn't explicitly state when to use this tool versus alternatives like window_arrange_* tools or window_resize. No explicit when-not-to-use guidance or named alternatives are provided.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. While it states the tool creates something ('Create a new iTerm2 window'), it doesn't disclose important behavioral traits like whether this requires specific permissions, what happens to existing windows, whether the window becomes focused automatically, or what the output contains. For a creation 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 perfectly front-loaded with the core purpose in the first sentence, followed by clear parameter documentation. Every sentence earns its place with no wasted words, making it easy for an agent to quickly understand the tool's function and parameters.

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

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

Given the tool has an output schema (which handles return values), 2 parameters with good semantic coverage in the description, and relatively simple functionality, the description is mostly complete. The main gap is the lack of behavioral context about permissions, focus behavior, or side effects, which would be helpful for a creation 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% schema description coverage, the description compensates well by explaining both parameters: 'profile' (with guidance to omit for default) and 'command' (to run in the new window). This adds meaningful semantics beyond the bare schema, though it doesn't specify format constraints or provide examples.

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 ('Create a new iTerm2 window') with the resource ('iTerm2 window'), distinguishing it from sibling tools like 'tab_new' or 'session_split' which create different terminal components. It uses precise verb+resource terminology that leaves no ambiguity about what the tool does.

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

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

The description provides implied usage context through the parameter documentation ('Omit for the default profile'), but doesn't explicitly state when to use this tool versus alternatives like 'tab_new' or 'session_split'. It lacks clear guidance on scenarios where creating a window is preferable to creating tabs or sessions.

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 it states the action ('Resize'), it doesn't disclose important behavioral traits: whether this requires specific permissions, what happens if invalid dimensions are provided, whether the change is immediate or animated, what happens to window content during resize, or what the tool returns. The description only covers basic parameter semantics without behavioral context.

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

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

The description is appropriately sized and front-loaded with the core purpose first. The Args section is well-structured but could be more integrated. Every sentence earns its place, though the formatting as a docstring with separate 'Args:' section slightly reduces structural elegance.

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

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

Given the tool has an output schema (which handles return values), no annotations, and 3 parameters with good semantic coverage in the description, the description is minimally adequate. However, for a mutation tool that changes window state, it should provide more behavioral context about effects, constraints, and error conditions to be truly 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?

With 0% schema description coverage, the description fully compensates by explaining all three parameters: width and height as 'New width/height in pixels' and window_id with the important semantic that it can be 'Omit for the current window.' This adds crucial meaning beyond the bare schema, though it doesn't specify pixel range constraints or window_id format.

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 ('Resize') and target resource ('an iTerm2 window'), distinguishing it from sibling tools like window_move, window_focus, or window_close. It provides a complete verb+resource statement without being tautological.

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 resizing is appropriate, or how it differs from similar tools like window_move or window_fullscreen. The only contextual hint is that window_id can be omitted for the current window, but this is parameter guidance rather than usage guidance.

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