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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, so the agent knows this is a safe, non-destructive, idempotent read operation. The description adds useful behavioral context beyond annotations: it explains what 'capture' means (visible content or history) and mentions use cases like reading command output. However, it doesn't cover aspects like error handling or performance implications, keeping it from a perfect score.

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

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

The description is well-structured and appropriately sized: it starts with a clear purpose statement, lists parameters with brief explanations, and ends with a usage note. Every sentence adds value, and there's no wasted text. However, the parameter list is somewhat redundant given the schema, slightly reducing efficiency, so it doesn't achieve a perfect score.

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 (6 parameters, no output schema) and rich annotations, the description is mostly complete. It explains what the tool does, provides parameter insights, and gives usage context. However, without an output schema, it doesn't describe the return format (e.g., text content, structure), leaving a minor gap. Overall, it's sufficient but not 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 100%, meaning all parameters are well-documented in the input schema. The description includes an 'Args' section that repeats parameter information (e.g., 'start_line (negative = history, 0 = top of visible)'), which adds minimal value beyond the schema. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.

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

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

The description clearly states the tool's purpose: 'Capture the visible content or history of a tmux pane.' It specifies the verb ('capture') and resource ('tmux pane content/history'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like tmux_list_panes (which lists panes rather than capturing their content), so it doesn't reach the highest score.

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

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

The description provides some usage context: 'This tool is useful for reading command output or checking the state of a pane.' This implies when to use it, but it doesn't explicitly state when to use this tool versus alternatives (e.g., tmux_list_panes for listing panes vs. this for capturing content) or when not to use it. The guidance is helpful but not comprehensive.

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

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

Annotations already indicate this is a non-destructive, non-readonly, non-idempotent creation operation. The description adds valuable behavioral context beyond annotations: it specifies the session is created in detached mode (important operational detail) and mentions the purpose ('to start new working environments'). No contradictions with annotations 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 efficiently structured with a clear purpose statement first, followed by parameter documentation, and ending with usage guidance. Every sentence serves a distinct purpose with no redundancy or wasted words. The two-sentence format is optimal for this tool.

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

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

For a creation tool with no output schema and comprehensive annotations, the description provides adequate context about the operation's behavior and usage. The main gap is lack of information about return values or error conditions, but given the annotations cover safety aspects and the purpose is straightforward, this is a minor omission.

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

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

With 100% schema description coverage, the schema already documents all three parameters thoroughly. The description repeats the parameter explanations verbatim from the schema without adding additional semantic context (e.g., format constraints, examples, or relationships between parameters). This meets the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Create a new tmux session') and distinguishes it from siblings like tmux_create_window (creates windows within sessions) and tmux_list_sessions (lists existing sessions). It specifies the resource being created (tmux session) with no 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 clear context for when to use this tool ('Use this to start new working environments') and mentions the session is created in detached mode, which helps differentiate from other session-related operations. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, etc., so the agent knows this is a non-destructive write operation. The description adds minimal behavioral context beyond annotations—it doesn't explain what happens if the session doesn't exist, whether the window becomes active, or if naming conflicts occur. With annotations covering safety, a 3 reflects some value but limited behavioral disclosure.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by a structured Args section. It's efficient with minimal waste, though the Args section could be integrated more seamlessly. Every sentence earns its place, but slight structural improvements are possible.

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 (3 parameters, no output schema), annotations cover safety aspects, but the description lacks details on error conditions, return values, or interaction with sibling tools. It's adequate as a basic definition but has clear gaps in contextual guidance 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 100%, with each parameter documented in the schema. The description repeats the parameter names and purposes verbatim from the schema without adding extra meaning (e.g., format examples, constraints like valid directory paths). Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the specific action ('Create a new window') and resource ('in a tmux session'), distinguishing it from sibling tools like tmux_create_session (creates sessions) or tmux_kill_window (destroys windows). The verb+resource combination is precise and unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., session must exist), compare to tmux_split_window (which creates panes within windows), or specify scenarios where creating a window is preferred over other operations. Usage context is implied but not articulated.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true, but the description adds valuable context beyond this: it explicitly warns that 'This will terminate the process running in the pane,' clarifying the destructive nature in practical terms. It doesn't contradict annotations and provides meaningful behavioral insight.

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 parameter details and a critical warning. Every sentence serves a distinct purpose with no redundancy, making it easy to parse and front-loaded with 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's complexity (destructive operation with 3 parameters), annotations cover safety and idempotency, and the description adds crucial behavioral context (process termination). However, without an output schema, it doesn't describe return values or error conditions, leaving a minor gap in 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 100%, with each parameter clearly documented in the schema. The description's Args section repeats this information without adding significant semantic context beyond what's already in the schema, meeting the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Kill (close)') and resource ('a pane in a tmux window'), distinguishing it from sibling tools like tmux_kill_session and tmux_kill_window which target different resources. The verb+resource combination is precise and unambiguous.

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

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

The description provides clear context for when to use this tool (to terminate a pane), and the WARNING section implies it should be used cautiously. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings (e.g., tmux_select_pane for navigation instead of termination).

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true, but the description adds valuable context beyond this: it explicitly warns that 'This will terminate all processes running in the session,' which clarifies the scope of destruction. However, it doesn't mention authentication needs or rate limits.

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, followed by parameter details and a warning. Every sentence earns its place by providing essential information without redundancy, making it efficient and well-structured.

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

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

Given the tool's complexity (destructive operation with one parameter) and rich annotations (destructiveHint, idempotentHint), the description is mostly complete. It lacks output schema details, but the warning adequately covers behavioral aspects. A minor gap is the absence of explicit error handling or success indicators.

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

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

Schema description coverage is 100%, with the parameter 'name' fully documented in the schema. The description repeats the parameter info in the 'Args' section but doesn't add meaningful semantics beyond what the schema provides, such as format examples 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 verb ('kill/terminate') and resource ('tmux session and all its windows/panes'), making the action specific. It distinguishes from siblings like tmux_kill_pane and tmux_kill_window by specifying it affects the entire session rather than individual components.

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 terminate a session and all its contents), but it doesn't explicitly mention when not to use it or name alternatives. For example, it doesn't contrast with tmux_kill_pane for partial termination.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true, but the description adds critical behavioral context beyond this: it warns that killing the window terminates all running processes, which is valuable operational insight not covered by annotations. No contradiction with annotations.

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

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

The description is front-loaded with the core purpose, followed by parameter details and a critical warning. Every sentence earns its place: the first defines the action, the Args section clarifies inputs, and the WARNING highlights important behavioral consequences. No wasted words.

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

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

For a destructive tool with no output schema, the description is reasonably complete: it explains what the tool does, documents parameters (via schema), and warns about process termination. However, it lacks details on error conditions or return values, which would be helpful given the destructive nature.

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

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

Schema description coverage is 100%, with both parameters clearly documented in the schema. The description repeats the same parameter information in the 'Args' section, adding no new semantic meaning beyond what the schema provides, meeting the baseline for high coverage.

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

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

The description clearly states the specific action ('Kill (close)') and resource ('a window in a tmux session'), distinguishing it from sibling tools like tmux_kill_session (for sessions) and tmux_kill_pane (for panes). The verb 'kill' is precise and matches the tool name, avoiding tautology.

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 it targets windows in tmux sessions, but does not explicitly state when to use this tool versus alternatives like tmux_kill_session or tmux_kill_pane. The WARNING provides guidance on consequences, but no explicit comparison to siblings.

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

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

Annotations already indicate read-only, non-destructive, and idempotent behavior, but the description adds valuable context by specifying what information is returned ('index, dimensions, and current command'), which is not covered by annotations. This enhances the agent's understanding of the tool's output.

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 concise parameter and return details. Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension.

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, rich annotations, and high schema coverage, the description is mostly complete. It lacks an output schema but describes return information. A minor gap exists in not detailing format or pagination, but overall it provides sufficient context for effective 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 100%, with both parameters well-documented in the schema. The description adds minimal value by restating the session parameter and noting the window defaults to current/active, but this is largely redundant with the schema. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the specific action ('List all panes') and resource ('in a tmux window'), distinguishing it from siblings like tmux_list_sessions or tmux_list_windows. It precisely defines the scope of what is being listed.

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 the required session parameter and optional window parameter, but it does not explicitly state when to use this tool versus alternatives like tmux_list_windows or tmux_select_pane. No explicit exclusions or comparisons to siblings 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?

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable context about what information is returned (session name, windows count, creation time, attachment status) and the tool's role in session discovery workflow, which goes beyond annotations.

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

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

The description is perfectly front-loaded with the core purpose in the first sentence, followed by specific return details in a bulleted list, and ends with clear usage guidance. Every sentence earns its place with no wasted words.

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

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

For a zero-parameter read-only tool with comprehensive annotations, the description provides exactly what's needed: clear purpose, output details (compensating for lack of output schema), and explicit usage context. It's complete without being verbose.

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

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

With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the tool's output semantics, which is helpful given no output schema is provided.

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 active tmux sessions') and distinguishes it from siblings by focusing on session discovery rather than creation, manipulation, or window/pane operations. It explicitly names the resource (tmux sessions) and verb (list).

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

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

The description provides explicit guidance on when to use this tool: 'Use this tool to discover available sessions before operating on them.' This directly contrasts with sibling tools like tmux_create_session, tmux_kill_session, or tmux_rename_session, which are for operating on sessions after discovery.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable context about what information is returned (index, name, active status, pane count), which goes beyond annotations and helps the agent understand the output structure. No contradictions with annotations 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 structured breakdown of args and returns. Every sentence adds value: the first states the action, the second clarifies the parameter, and the third details the return information. No wasted words or redundancy.

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

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

For a read-only listing tool with rich annotations and a simple parameter schema, the description is mostly complete. It covers purpose, parameter context, and return details. The lack of an output schema is compensated by the return information description. Minor gaps include no explicit sibling differentiation or error handling details.

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

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

Schema description coverage is 100%, with the parameter 'session' fully documented in the schema. The description repeats the parameter name and requirement but doesn't add meaningful semantics beyond what the schema provides, such as format examples or session naming conventions. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the specific action ('List all windows') and resource ('in a tmux session'), distinguishing it from sibling tools like tmux_list_sessions (which lists sessions) and tmux_list_panes (which lists panes). The verb+resource combination is precise and unambiguous.

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

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

The description implies usage when needing to list windows within a specific session, but doesn't explicitly state when to use this tool versus alternatives like tmux_list_sessions or tmux_list_panes. No guidance is provided on prerequisites or exclusions, leaving usage context inferred rather than explicit.

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

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

Annotations provide readOnlyHint=false (mutation), idempotentHint=true (safe to retry), and destructiveHint=false (non-destructive). The description adds minimal context beyond this, confirming it renames an existing session but not detailing side effects like session continuity or error conditions. It doesn't contradict annotations, so baseline 3 is appropriate given annotations cover core behavioral traits.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by a clear Args section. It's appropriately sized with no redundant information, though the Args section slightly duplicates schema content. Every sentence serves a purpose, making it efficient but not perfectly minimal.

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 (mutation with idempotency), annotations provide good coverage, and schema coverage is 100%, but there's no output schema. The description lacks details on return values or error handling, which could be helpful. It's adequate but has gaps in completeness for a mutation tool without output schema.

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

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

Schema description coverage is 100%, with both parameters (old_name, new_name) fully documented in the schema. The description repeats this information in the Args section but doesn't add meaningful semantics beyond what the schema provides, such as naming constraints or examples. Baseline 3 is correct as the schema handles parameter documentation adequately.

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

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

The description clearly states the specific action ('Rename') and target resource ('an existing tmux session'), distinguishing it from sibling tools like tmux_create_session (creates new) and tmux_rename_window (renames windows instead of sessions). The verb+resource combination is precise and unambiguous.

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

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

The description implies usage by stating 'Rename an existing tmux session,' which suggests it should be used when a session already exists, but it doesn't explicitly contrast with alternatives like tmux_create_session or provide guidance on when not to use it. No explicit when/when-not statements 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?

Annotations already declare readOnlyHint=false (mutation), destructiveHint=false (non-destructive), and idempotentHint=true (safe to retry). The description adds minimal behavioral context beyond this, confirming it's a rename operation but not detailing effects (e.g., whether renaming affects window references, if names must be unique). No contradiction with annotations exists.

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. However, the Args section duplicates schema information unnecessarily, adding bulk without value. The core description is efficient, but the overall structure includes redundant content.

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

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

For a mutation tool with good annotations (idempotent, non-destructive) and full schema coverage, the description is minimally adequate. However, it lacks output information (no schema provided) and doesn't address potential errors (e.g., invalid session/window). Given the complexity of tmux operations, more context on behavior and results would be helpful.

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

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

Schema description coverage is 100%, with each parameter clearly documented in the schema. The description repeats the same parameter information verbatim without adding extra meaning (e.g., format examples, constraints like name length limits). Baseline 3 is appropriate when the schema fully covers 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 specific action ('Rename a window') and resource ('in a tmux session'), distinguishing it from sibling tools like tmux_rename_session (which renames sessions) and tmux_create_window (which creates new windows). The verb+resource combination is precise and unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., session must exist), exclusions, or comparisons to related tools like tmux_rename_session. The agent must infer usage from the tool name alone.

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

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

Annotations already indicate this is a mutable but non-destructive operation (readOnlyHint=false, destructiveHint=false). The description adds minimal behavioral context beyond this - it doesn't explain what 'resize' means operationally, whether changes are immediate/reversible, or how it interacts with tmux's layout system.

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 opening statement followed by parameter documentation. While the Args section is somewhat redundant given the schema, the overall text is appropriately sized and front-loaded with the core functionality.

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

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

For a pane manipulation tool with full parameter documentation but no output schema, the description adequately covers what the tool does but lacks context about typical workflows, error conditions, or visual feedback. It's minimally complete but could better prepare an agent for real-world 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 100% schema description coverage, the schema already documents all parameters thoroughly. The description's Args section essentially repeats what's in the schema without adding meaningful semantic context about parameter relationships or tmux-specific conventions.

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 a pane') and resource ('in a tmux window'), distinguishing it from sibling tools like tmux_kill_pane or tmux_select_pane. It uses precise terminology that matches the tool's domain.

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 tmux_split_window for changing pane layout, or how it relates to other pane management tools. It lacks context about typical use cases 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?

Annotations cover key behavioral traits (non-read-only, non-destructive, idempotent), so the description's burden is lower. It adds minimal context by implying a state change ('Switch to'), but doesn't detail effects like focus shifting or error conditions. No contradiction with annotations exists.

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 parameter list. It's efficient with minimal waste, though the parameter section could be integrated more seamlessly rather than as a separate block.

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 (state-changing but non-destructive), 100% schema coverage, and annotations, the description is adequate but lacks output details (no schema) and usage context. It meets minimum viability but leaves gaps in guiding the agent effectively.

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

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

Schema description coverage is 100%, providing full parameter documentation. The description lists parameters with basic types but adds no meaningful semantics beyond the schema (e.g., format examples or constraints like pane indexing). Baseline 3 is appropriate as the schema handles the heavy lifting.

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

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

The description clearly states the specific action ('Switch to a specific pane') and resource ('in a tmux window'), distinguishing it from siblings like tmux_select_window (for windows) or tmux_list_panes (for listing). 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?

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active tmux session) or differentiate from similar tools like tmux_select_window, leaving the agent to infer usage context independently.

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

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

Annotations already indicate this is a non-destructive, idempotent operation (destructiveHint: false, idempotentHint: true), which the description doesn't contradict. However, the description adds minimal behavioral context beyond annotations—it doesn't explain what 'switching' entails (e.g., visual focus change, no data loss) or potential errors (e.g., invalid session/window).

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 one clear sentence, followed by a structured Args section. It's appropriately sized with no redundant information, though the Args section could be omitted since it duplicates the schema without added value.

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 (2 parameters, no output schema) and rich annotations, the description is minimally adequate. However, it lacks context on usage scenarios, error handling, or visual effects of switching windows, which would help an agent use it correctly in a tmux workflow.

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

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

Schema description coverage is 100%, with both parameters clearly documented in the schema. The description's Args section repeats this information without adding meaningful semantics (e.g., format examples for window names vs. indices, session naming conventions). Baseline 3 is appropriate as the schema carries the full burden.

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 resource ('a specific window in a tmux session'), distinguishing it from siblings like tmux_select_pane (selects pane) or tmux_list_windows (lists windows). 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 doesn't mention prerequisites (e.g., needing an active tmux session), exclusions, or comparisons to siblings like tmux_create_window (for creating new windows) or tmux_list_windows (for viewing available windows).

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

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

Annotations already declare this is not read-only, not open-world, not idempotent, and not destructive. The description adds useful context about the 'enter' parameter behavior (pressing Enter after sending keys) and provides examples of special key sequences like 'C-c' for Ctrl+C, which goes beyond what annotations provide.

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

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

The description is well-structured with clear sections (purpose, Args, Examples) and front-loaded with the core functionality. The examples are helpful but slightly verbose. Every sentence serves a purpose, though the Args section somewhat duplicates schema information.

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

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

For a tool with 5 parameters, 100% schema coverage, and comprehensive annotations, the description provides adequate context. The examples cover common use cases, and the tool's purpose is clear. Without an output schema, the description doesn't need to explain return values, making it reasonably complete for this complexity level.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema - it lists parameters in the Args section but doesn't provide additional semantic context. The examples illustrate parameter usage but don't add new information about parameter meaning.

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

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

The description clearly states the specific action ('Send keys or commands') and target resource ('to a tmux pane'). It distinguishes from sibling tools like tmux_capture_pane (which reads output) and tmux_kill_pane (which destroys panes) by focusing on input transmission to panes.

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 input to tmux panes, but doesn't explicitly state when to use this tool versus alternatives like tmux_create_session for session creation or tmux_select_pane for navigation. The examples provide some context but no explicit guidance on tool selection.

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

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

Annotations indicate this is a non-read-only, non-destructive, non-idempotent, non-open-world operation, covering basic safety. The description adds minimal behavioral context beyond this, such as the default vertical split and percentage range, but doesn't detail effects like pane focus changes or error conditions. No contradiction with annotations exists.

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 lists parameters without redundancy. Every sentence serves a clear purpose, 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 (5 parameters, no output schema) and rich annotations, the description is mostly complete. It covers the action, parameters, and defaults, but could improve by mentioning typical use cases or interaction with sibling tools. The absence of an output schema means return values aren't explained, but this is acceptable as annotations provide safety 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 100%, providing full parameter documentation. The description adds slight value by clarifying the default for 'horizontal' (false = vertical) and the percentage range (1-99), but most semantics are already in the schema. This meets the baseline for high coverage.

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

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

The description clearly states the specific action ('Split a window into panes') with the resource ('window'), distinguishing it from siblings like tmux_create_window (creates new window) or tmux_resize_pane (modifies existing pane). It precisely defines 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 implies usage for splitting windows but provides no explicit guidance on when to use this tool versus alternatives like tmux_create_window for new windows or tmux_resize_pane for adjusting pane sizes. It lacks context about prerequisites or typical scenarios for splitting.

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