mcp-tmux

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a specific tmux operation with clear, non-overlapping purposes. Even related tools like tmux_run, tmux_send_keys, and tmux_command have distinct behaviors: run executes and captures output, send_keys sends input, and command runs arbitrary tmux commands. Buffer tools are also clearly differentiated.
Naming Consistency5/5
All tools follow the consistent 'tmux_verb_noun' pattern in snake_case. Verbs are imperative and predictably describe the action (e.g., list_*, kill_*, set_*, select_*). No mixing of styles or ambiguous abbreviations.
Tool Count3/5
With 71 tools, the set is large and may feel heavy for agents, but it mirrors tmux's extensive command set. The number is reasonable given the server aims to provide comprehensive control of a complex terminal multiplexer, though it exceeds the typical well-scoped range.
Completeness5/5
The tool surface covers virtually all tmux operations: session, window, pane management; buffer handling; environment, options, hooks, key bindings; copy mode; streaming; and auxiliary commands like version check and server info. No significant gaps are apparent.
Average 3.6/5 across 71 of 71 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- Last stable release on June 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, permissions, or state changes beyond the bare action of swapping.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (three words) but omits essential information. Conciseness is penalized when it sacrifices clarity and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with no schema descriptions, no output schema, and no annotations, the description is completely inadequate to enable correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the three parameters (src, dst, target). Schema coverage is 0%, and without description, an agent cannot infer how to specify windows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Swap two windows' clearly states the verb (swap) and resource (windows), distinguishing from sibling tools like tmux_swap_pane. However, it could be more specific (e.g., 'swap positions of two windows').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like tmux_move_window or tmux_link_window. No context for when swapping is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as 'destructive', which matches the annotation destructiveHint=true but adds no new behavioral context beyond what annotations already provide. No additional details on side effects or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) with no wasted words, but it is too terse and omits essential information. Conciseness is not improved by lack of substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the absence of output schema, the description should at least explain the effect and parameters. It fails to provide adequate context for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the parameters (target_pane, target). It does not clarify their format, meaning, or how to specify a pane.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Kill' and resource 'pane', distinguishing it from other kill tools (tmux_kill_session, etc.). However, it lacks specifics on what happens (e.g., removing the pane or terminating the process), making it less informative than a high-quality description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like tmux_break_pane or tmux_kill_window. The description does not mention prerequisites or usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It only states a simple state change, missing details on prerequisites (e.g., session context), possible errors, or side effects. The mutating aspect is implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While very concise (one sentence), it sacrifices informativeness. Under-specification reduces utility; the description should add value beyond the name and title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no output schema, and no annotations, the description is incomplete. It lacks essential information like parameter semantics, error cases, and behavioral context, leaving the agent with insufficient guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description adds no explanation for the two parameters. 'target_pane' is self-explanatory but 'target' is ambiguous; no interaction details between them are given. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('make a pane the active one') and resource ('pane'). It distinguishes from siblings like kill_pane or break_pane by focusing on activation. However, 'active one' could be more precise for users unfamiliar with tmux terminology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like tmux_last_pane or tmux_select_window. The description provides no context for appropriate usage scenarios or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Description only states the basic action, omitting details like negative values, boundary behavior, effect on other panes, or return value. Lacks essential 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded, but too brief for the tool's complexity. Could include more details without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, 6 parameters with only 1 required, and 0% schema coverage, the description fails to provide necessary context for correct invocation. Lacks parameter explanations, usage conditions, and behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema), and the high-level description does not explain individual parameters. 'By a number of cells in one or more directions' vaguely covers left/right/up/down but ignores target_pane, target, and how values affect resizing. No added meaning beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool resizes a pane by cells in directions. It's specific to resizing, but doesn't differentiate from sibling tools that might also affect pane dimensions, though no siblings directly resize. Still, purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like tmux_split_window or tmux_select_pane. No prerequisites or conditions mentioned, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. 'Swap' is vague—does it exchange positions? content? It does not mention side effects, prerequisites, or whether it is destructive. The behavioral implications are unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence. While concise, it sacrifices clarity and completeness. It is appropriately short but fails to provide essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a swap operation with three parameters and no output schema or annotations, the description is severely lacking. It does not explain the behavior, parameter meanings, or results, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions). The description does not explain what src, dst, or target represent (e.g., pane identifiers, indexes, or formats). This leaves the agent without necessary information to properly invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Swap two panes' clearly states the verb (Swap) and resource (panes). It distinguishes from sibling tools like tmux_swap_window (swaps windows) and tmux_select_pane (selects a pane). However, it is minimal and lacks additional context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool compared to alternatives like tmux_break_pane, tmux_join_pane, or tmux_select_pane. The description does not provide any context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as whether the rename affects other sessions, requires specific permissions, or any side effects. The minimal description fails to inform the agent about mutation risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is front-loaded and efficient, though it could benefit from slight expansion for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% parameter description coverage, the description is severely lacking. It does not explain return values, side effects, or the role of the optional 'target' parameter, making it incomplete for a 3-parameter mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter names ('session', 'new_name', 'target') are somewhat self-explanatory, but with 0% schema description coverage, the agent may not understand that 'session' is the current identifier or the purpose of the optional 'target' parameter. The description adds no clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Rename a session.' clearly states the action and the object (session). The verb 'rename' and resource 'session' are specific, but it does not differentiate from sibling tools like `tmux_rename_window`, though the naming suffices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., `tmux_rename_window`). The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'rename a window' without saying what happens to the old name, whether it affects other windows, or any restrictions (e.g., requires an active session). This is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is appropriately front-loaded. However, conciseness comes at the cost of completeness, but the structure itself is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, three parameters, and no output schema, the description is severely lacking. It does not explain parameter relationships, valid inputs, or any behavioral context like session selection. This makes it incomplete for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% because the description adds no parameter information. While parameter names ('window', 'new_name', 'target') are somewhat self-explanatory, the description fails to explain what values they accept (e.g., window formats, valid names) or how 'target' differs from 'window'. The burden to compensate for low coverage is unmet.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Rename') and resource ('a window'), making the basic purpose obvious. However, it does not differentiate this tool from siblings like 'tmux_new_window' or 'tmux_select_window', and lacks specificity about which window is being renamed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites, context (e.g., session), or when renaming is appropriate versus other window operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description lacks details on side effects (e.g., rearrangement of panes, destructiveness). Does not disclose behavior beyond applying a layout.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence, front-loaded with key information. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 params, no schema descriptions, and no output schema, the description is incomplete. It omits how to target a specific window, what a layout string looks like, and any prerequisites or results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description adds meaning for 'layout' (named layouts) but provides no semantics for 'window' or 'target' parameters, which are critical for usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Uses verb 'apply' with resource 'layout to a window', lists specific named layouts, and implies distinction from siblings like 'tmux_next_layout'. However, it doesn't explicitly contrast with cycling layouts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs alternatives (e.g., tmux_next_layout, tmux_resize_pane). Usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states the action (make window active) but does not disclose side effects, error handling for missing windows, or whether it requires specific session context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very concise (one sentence plus example). While efficient, it may be too brief; adding a bit more detail without verbosity would improve completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema and two undocumented parameters, the description lacks essential context such as return value, behavior on invalid input, and interaction with sessions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description only explains the 'window' parameter with an example. The 'target' parameter is completely undocumented, leaving a gap in understanding its purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool makes a window active, with an example format. However, it does not differentiate from similar sibling tools like tmux_find_window or tmux_select_pane, which also deal with window selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Implied usage from 'make a window active' but no context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description repeats 'destructive' but adds no further behavioral context, such as irreversible effects, permissions required, or implications for attached clients. With annotations covering safety, a baseline score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it very concise. However, it may be too terse, omitting critical details. It is front-loaded with the action, but the lack of parameter explanation reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with an output schema, the description should explain what happens after killing (e.g., window closed, pane processes terminated). It also lacks usage context and parameter semantics. The agent is left with incomplete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 does not explain the meaning of the 'window' parameter (e.g., window ID, name, index?) or the 'target' parameter. Without this information, the agent cannot correctly construct arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'kill' and the resource 'window'. It distinguishes from sibling kill tools (pane, session, server) by specifying 'window'. However, it does not elaborate on what 'killing a window' entails (e.g., closing all panes, terminating processes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like tmux_kill_pane or tmux_kill_session. The agent has no context for deciding between destructive window vs. pane or session operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only states the basic action without disclosing side effects, permissions, or whether the operation is destructive. Behavioral traits beyond the action are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose. It effectively conveys the core function without waste, but could include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 params, many siblings, no output schema), the description is incomplete. It explains only two of three parameters and provides no context to differentiate from the many window manipulation siblings. Missing guidance on when to use this vs others.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the example 'sess:5' adds meaning for src and dst, clarifying the expected format. However, the optional 'target' parameter is completely unexplained, and the exact syntax for session:window is not fully detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Move/renumber a window' and specifies the resource. It gives an example format for src/dst, which helps distinguish from sibling tools like link or swap. However, it does not explicitly differentiate from similar operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like tmux_link_window or tmux_swap_window. There is no mention of prerequisites, conditions, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the basic action and the effect of the delete parameter. Missing details include default behavior (past most recent buffer if name not given), error conditions, side effects, and return value. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states the purpose and key option. It is concise and front-loaded. However, it sacrifices completeness for brevity; it could include more details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is incomplete. It fails to clarify all parameter semantics, prerequisites, or return behavior. A more complete description would cover target_pane format, buffer selection behavior, and potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must add meaning. It only explains the delete parameter as 'removes the buffer after (-d)'. No description is given for target_pane (what format?), name (how to specify?), or target (optional target). This is inadequate for 4 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Paste a buffer into a pane.' It uses a specific verb (paste) and resource (buffer into a pane). This distinguishes it from sibling tools like tmux_delete_buffer or tmux_list_buffers, which have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. It lacks information about prerequisites (e.g., buffer must exist) or when to prefer this over other buffer-related tools like tmux_set_buffer or tmux_load_buffer. Only the delete parameter option is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark as readOnlyHint true. The description adds the exact fields returned, but does not disclose any further behaviors (e.g., authentication, side effects). It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise: one sentence and a return field specification. Every word is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple with one optional parameter and no output schema, the description covers the return fields but omits explanation of the parameter. It is partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description completely ignores the 'target' parameter. With 0% schema description coverage, the description fails to add any meaning about the parameter's purpose or usage, leaving it entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports basic server facts (pid, socket path, version). It distinguishes from siblings like tmux_version by listing multiple fields, but does not explicitly contrast with similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like tmux_version or other info commands. The description does not specify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose whether the buffer must already exist, if the operation is destructive, or any side effects. Only hints at naming via -b.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no wasted words. However, brevity sacrifices necessary detail for a tool with 3 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description is too minimal. Lacks explanation of data semantics, target usage, and return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description should compensate but only mentions the name parameter indirectly via '-b'. Data and target are left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Set' and resource 'paste buffer's contents', distinguishing it from sibling tools like tmux_delete_buffer or tmux_paste_buffer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like tmux_load_buffer or tmux_save_buffer. Lacks context for optimal invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is clearly read-only. The description adds the return format. However, it does not disclose what 'scope' options are shown or any limitations. For a read-only tool with annotations, this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point, with one sentence and a return format note. No wasted words, though some might argue it is too concise and lacks necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters and no output schema, the description should provide more context about parameter interactions and the full return structure. It only mentions the return format partially but leaves out parameter semantics. The tool is not fully specified for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only vaguely hints at the 'scope' parameter by saying 'for a scope'. It offers no explanation for the other three parameters (target_entity, global_, target). This fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool shows tmux options for a scope, and indicates the return format. It distinguishes from sibling tools like tmux_set_option which sets options. However, it could be more specific about what 'scope' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_show_environment or tmux_show_hooks. No context on when-not-to-use is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the description doesn't need to restate that. It adds the return format, which is useful. However, it doesn't disclose any additional behavioral traits like side effects, performance characteristics, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence and a return format spec. No wasted words, but it lacks necessary details about parameters, which makes it too terse for effective use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and no output schema, the description should explain inputs and outputs more thoroughly. It does cover the return value minimally, but omits parameter semantics and context for the target field, leaving the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides no explanation of the 'session' or 'target' parameters. The agent cannot determine what values to provide or how they affect behavior. This severely limits correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check whether a session exists.' It specifies the return format as a JSON object with a boolean field, making the goal unmistakable. This distinguishes it from sibling tools like tmux_list_sessions or tmux_kill_session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as tmux_list_sessions or tmux_has_session itself. No exclusion criteria or context for when not to use it. Implicitly it's for a simple existence check, but an agent lacks decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the description adds 'Ends all its windows and panes' which clarifies the scope. However, it does not explain what happens to clients, buffers, or if there are confirmation steps. The target parameter is undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences that front-load the core purpose. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with two undocumented parameters and no output schema, the description is insufficient. It lacks input format hints (e.g., session name vs ID), behavior of the optional 'target' parameter, and return value information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description provides zero information about the 'session' or 'target' parameters. No hints on format, allowed values, or purpose beyond the tool's name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action 'Kill a session' and specifies the consequence 'Ends all its windows and panes.' It distinguishes well from sibling tools like tmux_kill_pane or tmux_kill_window by naming the resource explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like tmux_has_session or tmux_list_sessions. No prerequisites or exclusions noted. The destructive label is present but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, indicating safe read-only operation. The description adds no further behavioral details beyond what annotations already offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded. However, it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter, the description is adequate but incomplete. It lacks explanation of the 'target' parameter and context on what paste buffers are.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'target' is not explained in the description. Schema coverage is 0%, so the description should clarify its meaning, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states verb 'List' and resource 'paste buffers' with attributes 'names and sizes'. Clearly distinguishes from sibling tools like tmux_delete_buffer and tmux_paste_buffer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like tmux_list_clients or tmux_list_panes. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions the return value and the effect of 'select', but it does not explicitly state that the pane is moved (destructive) or other side effects. The term 'break out' implies removal from the original window, but this is not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences and a brief code block for parameter notes. It is front-loaded with the primary action. Some redundancy could be trimmed (e.g., the code block could be integrated into sentences), but overall it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, 0% schema coverage, and no output schema, the description covers the action, return type, and two parameters. However, it misses explanations for the required 'target_pane' and optional 'target' parameters, and lacks detail on destructive behavior. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains two parameters ('window_name' and 'select') and their effects, but 'target_pane' (required) and 'target' are not described beyond their names. Since schema coverage is 0%, the description adds some value but leaves gaps for half the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Break a pane out into a new window of its own.' This is a specific verb+resource combination. It is distinguishable from siblings like tmux_split_window or tmux_join_pane, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage details for the 'window_name' and 'select' parameters (e.g., naming the new window, using -d for background creation). However, it lacks guidance on when to prefer this tool over alternatives like tmux_split_window or tmux_join_pane, and no prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 explains that output feeds to stdin, the toggle effect of only_new, and the return value. However, it does not disclose potential side effects (e.g., resource usage) or details on how multiple pipes interact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with two paragraphs, includes an example command, and uses clear language. It front-loads the purpose and adds detail without excessive verbosity, earning its sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (piping output), 4 parameters, no annotations, and no output schema, the description provides adequate coverage of core behavior and return but lacks details on parameter formats (e.g., target_pane identifier), default values, and exact meaning of the boolean return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 explains 'command' with an example and 'only_new' behavior, but does not describe 'target_pane' (required) or 'target' at all, leaving half of the parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool pipes pane output to a shell command and highlights it is great for logging. It uses a specific verb 'pipe' and resource 'pane's output', but does not explicitly differentiate from siblings like tmux_capture_pane or tmux_stream_*, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to stop piping (no command) and toggle behavior (only_new), but does not provide guidance on when to use this tool versus alternatives like tmux_capture_pane for one-time capture or tmux_stream_* for streaming. Usage context is implied 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral traits. It fails to disclose side effects like persistence of options, error conditions, or required permissions. Basic usage is described but deeper implications are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the main purpose. It lists scope options efficiently. However, it could be more structured by including a clear parameter list. Still, no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description lacks essential context. It does not mention valid option names, return values, or error handling. The tool is one of many tmux siblings, and the description does not sufficiently help the agent choose correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 explains 'scope' and 'target_entity' but does not describe the required 'name' and 'value' parameters, nor the optional 'target'. This leaves significant ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Set a tmux option,' specifying a specific verb and resource. It distinguishes from siblings by explaining scope and target_entity, aligning with its naming convention.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use different scopes and target_entity. However, it lacks explicit guidance on when not to use this tool or alternatives among the many sibling tools, such as tmux_set_environment or tmux_set_hook.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds beyond the readOnlyHint annotation by specifying what is reported: the version string and a supported flag (1.8+). This is useful context. No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core functionality with no unnecessary words. It is ideally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, read-only, no output schema), the description is mostly adequate. However, the lack of parameter definition leaves a gap that could cause incorrect usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description does not explain the 'target' parameter. The word 'target' appears only in the purpose statement without clarifying its meaning, format, or allowed values. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports the target's tmux version and whether it is supported (1.8+). It uses a specific verb and resource, distinguishing it from other tmux tools that perform different actions. However, it does not explicitly differentiate from siblings like tmux_server_info, which might also provide version info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For example, it does not explain when to use tmux_version instead of tmux_server_info or tmux_list_sessions. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive action (destructiveHint=true). Description adds minimal beyond confirming deletion. No further behavioral details (e.g., reversibility, confirmation prompts).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no waste, appropriately brief for a simple operation. However, slight under-specification on parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a basic destructive operation given annotations, but missing parameter explanations and usage context. Not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and description does not explain the meaning of parameters 'name' and 'target'. Agent is left to infer semantics from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (delete) and resource (named paste buffer). It effectively distinguishes from sibling tools like paste, set, load, save, list buffers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites, when deletion is appropriate, or exclude conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover all behavioral traits. It explains the -d behavior and return format, but does not discuss side effects, error handling, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and front-loaded, but could be better structured by listing parameters explicitly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It lacks parameter details and contextual usage notes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description should describe all parameters. It only explains session and select, leaving name, start_directory, command, and target undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a window,' which is a specific verb+resource. It distinguishes from sibling tools like tmux_kill_window or tmux_select_window.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the -d flag (select=False) for background creation, but lacks guidance on when to use this tool versus alternatives like tmux_new_session or tmux_split_window.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains that root=True removes the need for a prefix and repeat=True allows repeating, which is good. However, it does not mention that the binding overrides existing ones, the scope (session vs server), or any potential errors, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with three sentences that directly explain the purpose, key parameters, and return value. It front-loads the core action and uses a clear example, earning its place in every sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description is mostly adequate but misses the target parameter and does not mention side effects like overriding existing bindings or the temporary nature. Given the complexity and sibling tool presence, more detail is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains five of six parameters (key, command, table, root, repeat) with examples and meanings. The target parameter is not mentioned, which is a gap, but the description adds value beyond the schema for the majority of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it binds a key to a tmux command, which is a specific verb+resource. However, it does not explicitly distinguish from sibling tools like tmux_unbind_key or tmux_send_keys, which could be confusing for an agent selecting between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus alternatives. It explains some options (root, repeat) but does not provide context about when binding is appropriate or what typical use cases are, such as overriding existing bindings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It notes the tool may enter copy mode first and details how direction and amount work, but it does not explain side effects (e.g., stays in copy mode?), potential errors, or read-only nature. Transparency is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-line purpose followed by necessary details on direction and amount. It avoids wasted words, though the list of direction values could be seen as dense. Overall, it is efficiently structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (1 required) and no output schema or annotations, the description explains half the parameters (direction, amount) but omits target_pane and target. It also does not mention return values. Completeness is sufficient for a simple scroll action but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate. It explains 'direction' and 'amount' meaningfully (e.g., direction values, amount ignored for top/bottom), but 'target_pane' and 'target' are left unexplained. This partial coverage meets a baseline but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrolls within copy mode, a specific action on a specific resource. It also provides details on direction and amount, and mentions it enters copy mode if needed, distinguishing it from related tools like tmux_copy_mode and tmux_copy_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It only says 'Scroll within copy mode.' Without mentioning when not to use it or suggesting alternatives, the agent lacks context for decision-making among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, consistent with 'list'. Description adds value by specifying the fields returned (id, name, window count, etc.), which is useful context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler, front-loaded with action and resource. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description is adequate but minimal. It describes what is listed but omits details about the output format or how the target parameter affects results, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter (target), but description does not explain its meaning or acceptable values (string or null). With 0% schema description coverage, description fails to compensate, leaving the agent unclear on how to use the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('all sessions'), and specifies included fields (id, name, window count). It effectively distinguishes from sibling tools like tmux_list_panes and tmux_list_windows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives or when not to use it. The description implies it's for listing sessions, but lacks explicit context for selection among many list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description covers key behaviors: orientation, percentage sizing, focus behavior with select, and return value. However, it omits potential side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loads purpose. It could be slightly more structured but avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 optional parameters and no output schema/annotations, the description lacks completeness: missing parameter explanations and usage context among many sibling tools. Return value is partially described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must explain parameters but only covers vertical, percentage, and select. Leaves start_directory, command, target, target_pane unexplained, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it splits a pane, specifies default orientation (left/right) and how to change to top/bottom, and mentions key parameters. It effectively communicates the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use split vs alternatives like break_pane, join_pane, or new_window. The description does not help distinguish among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility. It discloses the target-dependent path resolution and the return format. However, it omits error behavior (e.g., file not found), permissions needed, or side effects like overwriting buffers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences and a return statement. Every word adds value, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core functionality and a critical behavioral note. Missing prerequisites (read access), error handling, and buffer size limits. Adequate for a simple tool but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains that 'name' corresponds to the -b flag and that 'path' is resolved on the target. However, the 'target' parameter is only implicitly described via an example; no formal semantics are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads a file's contents into a paste buffer, referencing the tmux command 'load-buffer'. It is specific and unambiguous, but does not explicitly differentiate from sibling buffer tools like tmux_save_buffer or tmux_set_buffer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides important context about path resolution on the target (local vs remote), which helps agents understand when to use it. However, lacks explicit guidance on alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals important behaviors: path resolution on the target host (critical for SSH), default buffer selection (most recent), and append mode. It also specifies the return format. While annotations are absent, these disclosures add substantial value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: three short sentences covering purpose, parameters, and return value. No superfluous text; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and many siblings, the description adequately explains core functionality and key behavioral nuances (target resolution). However, it omits the 'target' parameter and lacks usage differentiation from siblings, leaving moderate gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains name (default, selection), append (mode), and path (required, target resolution). However, the 'target' parameter is completely undocumented, leaving a gap for 1 of 4 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a paste buffer to a file using tmux's save-buffer command. It identifies the resource (paste buffer) and action (save to file), which is specific enough to distinguish from siblings like tmux_load_buffer or tmux_paste_buffer, though it does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like tmux_set_buffer or tmux_load_buffer. The description focuses solely on what the tool does without providing context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the readOnlyHint annotation, confirming no side effects. It adds the return format, providing transparency beyond what annotations offer. However, it could mention potential scope (server vs session) more explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus the return format. Every word is necessary, no redundancy. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three undocumented parameters and no output schema, the description is insufficient. It gives the high-level purpose but fails to explain how to use the tool effectively, especially regarding the parameters that control scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the three parameters (global_, target_entity, target). With 0% schema coverage, the description should clarify parameter usage, but it fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows hooks on server/session and provides the return format. It uses a specific verb 'show' and resource 'hooks', distinguishing it from sibling tools like tmux_set_hook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when you need to inspect hooks) but does not explicitly state when not to use or mention alternatives. No guidance beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explains that errors from tmux are raised and that output from commands appears as %output events via tmux_stream_read. However, it does not disclose potential side effects or whether the command can be destructive, leaving ambiguity about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise at 4 sentences with a clear front-loaded purpose. No redundant information, but could be more structured (e.g., bullet points for params).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Mentions return format and error handling but lacks prerequisites (e.g., needing an active stream) and does not relate to sibling stream tools or explain integration with tmux_stream_read and tmux_stream_start.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must add meaning. It explains the 'command' parameter with an example but does not elaborate on 'stream_id' (how to obtain or format it) or 'timeout' (no explanation of its purpose or effect).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it runs a tmux command over a stream's control connection, specifying that the command is a tmux command line without the 'tmux' prefix and giving an example. This distinguishes it from other tmux tools like tmux_command which may not use streams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage within a stream context but does not explicitly state when to use this tool over alternatives like tmux_command or tmux_send_keys. No when-not-to-use or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return type {"window": window} and basic action but lacks details on layout wrapping, side effects, or prerequisites like window existence. Adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, no redundancy. Every sentence adds value: purpose and parameter behavior. Perfect conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two params and no output schema, the description covers the return value and window parameter but misses the target parameter and layout cycling behavior. Adequate but missing one param explanation offsets completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'window' parameter (as -t flag) but completely ignores the 'target' parameter. Schema description coverage is 0%, so compensation is needed but only partial. Two params exist, only one explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool rotates a window to its next preset layout, using the verb 'rotate' and specifying the resource 'window'. It distinguishes from sibling tmux_select_layout by implying cycling through layouts as opposed to selecting a specific one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use -t parameter but does not explicitly mention when to prefer this tool over tmux_select_layout or other layout tools. No exclusions or alternatives are provided, though context of 'next layout' implies sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true, so the description adds only explicit context ('ends ALL sessions'). No contradictions. Some other behaviors (e.g., effect on attached clients) are omitted, but annotations cover the destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, front-loaded with the action and consequence. It is concise but could include parameter guidance without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the core behavior adequately. However, missing parameter documentation limits completeness for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not document the 'target' parameter. Schema coverage is 0%, and the agent cannot infer what 'target' refers to (e.g., server name, socket path). This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'kill' and the resource 'tmux server', and explicitly notes it ends ALL sessions, distinguishing it from sibling tools like tmux_kill_session or tmux_kill_pane.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description warns 'destructive: ends ALL sessions', which implies when not to use it. It does not explicitly list alternatives, but the warning provides clear guidance on impact.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint, description provides return format (raw bindings with lines) and output structure. Also mentions optional table restriction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy, essential information front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks explanation of target parameter, which may be important for context. Otherwise sufficient for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Explains table parameter with examples (prefix, root, copy-mode), but target parameter is left unexplained. Schema coverage is 0%, so description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists key bindings with optional table filtering, and specifies the return format. Distinguishes from modification tools like tmux_bind_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs alternatives like tmux_bind_key or tmux_unbind_key. Does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions the return format but does not disclose destructiveness or prerequisites (e.g., requiring an active tmux session). This 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences that front-load the main action and key options. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and no output schema, the description only covers basic functionality. It omits details about 'table' and 'target', and does not provide prerequisite context (e.g., tmux session requirement).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates partially by explaining 'key', 'all', and 'root'. However, it does not explain 'table' or 'target' comprehensively, leaving some parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Unbind a key' and distinguishes itself from the sibling 'tmux_bind_key' by performing the inverse operation. It specifies the resource (key bindings) and the action (unbinding).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use 'key' vs 'all' vs 'root' parameters, providing clear context. However, it does not explicitly mention when not to use this tool or compare it to other unbinding tools like 'tmux_unlink_window'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it enters copy mode if needed, requires tmux 2.4+, and returns a dict. This is beyond minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each essential. No redundant information. Front-loaded with key action and parameter behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and no output schema, the description explains the main action and return structure vaguely but misses explaining 'target_pane' and 'target'. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only adds meaning for 'pattern' and 'backward' (direction semantics). It omits 'target_pane' and 'target' entirely, leaving two parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as searching the scrollback in copy mode for a given pattern, using explicit verbs and resource. It distinguishes from siblings like tmux_copy_mode and tmux_copy_scroll by stating it searches and enters copy mode if needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direction context ('the usual direction for finding recent output') and mentions entering copy mode, but does not explicitly state when to use this over alternatives like tmux_find_window or tmux_capture_pane. Guidance is implied but not comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly states that the tool switches the active window and returns a fixed response '{"selected": "last"}'. While it doesn't detail error conditions or edge cases, the behavior is straightforward and well-summarized for a simple navigation action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences plus a return note, with zero redundancy. The first sentence front-loads the action, the second adds parameter context, and the final line specifies the return value. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, no output schema, no annotations), the description covers the core action and one parameter adequately. However, the unexplained 'target' parameter and lack of comparison to sibling navigation tools mean it is not fully complete for an agent to use correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must explain all parameters. It adequately explains the 'session' parameter as mapping to the -t flag. However, the 'target' parameter is completely ignored, leaving its purpose ambiguous. This is a significant gap, as only half the parameters are documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Switch to the previously selected window (last-window).' This is a specific verb+resource combination that distinguishes it from siblings like tmux_last_pane or tmux_select_window. The reference to 'last-window' further clarifies the tmux command being invoked.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the effect of the session parameter, providing context for when to use it with a specific session vs the current one. However, it does not explicitly compare this tool to alternatives or state when not to use it, leaving the agent to infer usage scenarios from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint) are already present. The description adds context by revealing the underlying tmux command (display-message -p) and the return format ({"value": <expanded string>}). It does not contradict annotations and provides useful behavioral details beyond the structural fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no fluff. Essential information is front-loaded (purpose, example, underlying command). Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool, the description covers purpose, mechanism, and output format. However, it does not handle the missing 'target' parameter, error cases, or restrictions (e.g., valid format strings). This is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains 'format' and 'target_pane' well, but the 'target' parameter is completely omitted. This is a significant gap for an AI deciding which parameter to use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates a tmux format string using display-message -p, with a concrete example. It distinguishes from siblings like tmux_command (which runs commands) and list tools (which retrieve lists, not evaluate format strings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like tmux_list_panes or tmux_display_message. It provides an example and optional target_pane but lacks guidance on selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 exit sends the copy-mode cancel command (tmux 2.4+) and describes the return format. However, it does not address potential side effects or behavior when both page_up and exit are true. This is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (four lines) and front-loaded with the main purpose. Each sentence adds necessary information without redundancy. Technical details are appropriately placed in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (1 required) and no output schema or annotations, the description covers the core behavior and two key parameters. It lacks explanation for the target parameter and does not explicitly state the nature of the operation (state change). It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains page_up (scrolls up one page on entry) and exit (leaves copy mode), but does not clarify target_pane or target. It provides partial but significant value for two of four parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Enter (or exit) copy mode in a pane.' This is a specific verb-resource pair, and it distinguishes itself from sibling tools like tmux_copy_scroll and tmux_copy_search by focusing on mode entry/exit rather than scrolling or searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the effects of the page_up and exit parameters, helping the agent understand when to use each. It also mentions the return value. However, it does not explicitly contrast with alternatives like tmux_copy_scroll or tmux_copy_search, though the context is fairly self-explanatory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return value format and the effect of the `window` parameter. Since no annotations are provided, it carries the full burden and does so adequately for a simple toggle action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) and front-loaded with the main action. However, the omission of `target` parameter information makes it efficient but incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema and low schema coverage, the description is adequate for the primary function but lacks explanation for all parameters. It documents the return value, which is helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds meaning to the `window` parameter but completely ignores the `target` parameter, leaving half the parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Switch to the previously active pane') and resource ('pane'). It distinguishes itself from sibling tools like tmux_select_pane and tmux_last_window by naming 'last-pane'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the `window` parameter ('acts on that window; otherwise the current one'), providing clear context. It does not explicitly exclude alternatives, but the purpose is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations confirm readOnlyHint: true, and the description adds scoping behavior (window, session, all). However, it does not disclose return format, ordering, or any potential side effects, leaving some 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences front-loading the main action and scoping options. Every word is informative, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with readOnlyHint and no output schema, the description is mostly adequate but incomplete regarding the 'target' parameter and output format. It covers the core scoping but misses some details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaning for 'window' and 'session' parameters by mapping to tmux flags (-t, -s). However, it does not explain the 'target' parameter from the schema, leaving one parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List panes' with a specific verb and resource, and distinguishes from sibling tools like tmux_list_windows and tmux_list_sessions by explicitly mentioning scoping options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each parameter: window (-t), session (-s), or whole server (default -a), providing clear context for usage. However, it doesn't explicitly mention alternatives for other listing tasks, though the tool name and siblings make it implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation by specifying the scope of listing (specific session vs. all sessions). However, it does not disclose details like output format or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no fluff. The key action is front-loaded, and the conditional behavior is clearly stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary behavior and the main parameter, but ignores the `target` parameter and does not describe the output. Given the tool's simplicity and lack of output schema, some details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by explaining the `session` parameter's effect. However, it fails to mention the `target` parameter at all, leaving its purpose unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List windows') and distinguishes between two modes: with a specific session or all windows (-a). This differentiates it from sibling list tools like tmux_list_panes or tmux_list_buffers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use the `session` parameter versus omitting it, providing clear context. However, it does not mention when to avoid using the tool or suggest alternative tools for other purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains key behavioral traits: stdout is not returned but goes to a buffer, background mode runs without waiting, and the return format is `{output, exit_code}`. It could further detail error handling or side effects, but the major behavioral aspects are well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 4 sentences, front-loads the purpose, and uses clear structure. It efficiently conveys key info without extra fluff. Minor improvement could be listing parameters more explicitly, but overall it is well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity of a command runner tool and the lack of an output schema, the description explains return values and core behavior. However, it omits descriptions for `target_pane` and `target` parameters, and does not mention prerequisites (e.g., tmux session existence) or error conditions. This creates gaps for a fully informed agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 mentions only the `background` parameter and its effect. The critical parameters `command`, `target_pane`, and `target` are not described, leaving the agent to infer their meaning from the schema alone. This is insufficient for a 4-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run a shell command from tmux via `run-shell`.' It distinguishes itself from the sibling tool `tmux_run` by explicitly noting that `tmux_run` is preferred for capturing output, making the purpose and differentiation very clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 vs `tmux_run`, advising to prefer `tmux_run` for capturing command output. It also explains the effect of the `background` flag. However, it does not cover usage scenarios for all siblings or provide explicit 'when not to use' beyond this comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: detaching the control client, session continuation, connection freeing, and return value. However, it does not mention error conditions or side effects for invalid stream_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, no extraneous words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description explains the tool's purpose, effect, and return format. It could include a usage hint (e.g., 'after starting a stream with tmux_stream_start') but is otherwise adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate for the undocumented 'stream_id' parameter. The description only mentions stream_id in the return value, not explaining what it is or how to obtain it. This adds minimal meaning beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Stop a stream' with a specific verb and resource. It explains the implications (detach control client, session keeps running, free connection) and mentions the return value, distinguishing it from sibling stream tools like tmux_stream_start.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a stream needs to be stopped, but it does not explicitly state when to use this tool versus alternatives, nor does it provide any prerequisites or conditions (e.g., stream must be active). Context about when not to use it is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool displays on the tmux screen, expands #{...} format variables, and returns a simple JSON. It is a read-only, non-destructive operation, which is clear from the description. The return format is specified. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, no filler. The most important information (purpose, distinction from sibling) is front-loaded. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior (display message, format expansion, return value) but does not detail all parameters or edge cases. For a simple display tool with no output schema, it is adequate but leaves room for improvement in parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains that 'message' is the content displayed and that format variables are expanded against 'target_pane' context if given. However, 'target_client', 'target', and the precise meaning of 'target_pane' are not explained. Only 2 out of 4 parameters receive any clarification, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows a message on a client's status line, using specific verbs ('Show') and resource ('message on status line'). It distinguishes itself from 'tmux_query' by explaining the difference in output location (on-screen vs. printed to stdout). This is precise and leaves no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with 'tmux_query', providing clear guidance on when to use this tool (on-screen display) versus the sibling (stdout printing). It mentions format variable expansion against target_pane context. However, it does not explicitly state when not to use this tool or list alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the search is non-interactive and implemented via list-windows, and mentions the return format. Annotations already mark it as read-only; the description adds detail on the matching behavior and why it differs from the built-in command. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three focused sentences covering purpose, behavior, and differentiation. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters and no output schema. The description covers pattern and session adequately and states the return format. However, the 'target' parameter is missing from the description, and there is no guidance on edge cases (e.g., no matches). For a search tool, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains pattern (matching) and session (scoping), but the 'target' parameter is not described at all, leaving its purpose unclear. The description provides partial but incomplete parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it finds windows matching a pattern, specifies the fields searched (name, title, current command), and clarifies case-insensitive substring matching. It distinguishes from the interactive tmux find-window, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains that the search can be scoped to a session or the whole server, and contrasts with tmux's interactive version, indicating when this non-interactive alternative is appropriate. While it doesn't provide explicit when-not-to-use guidance, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the window appears in both spots and that select=False links in the background (-d). However, it does not explain the 'target' parameter, and with no annotations provided, the description should cover all behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs, front-loading the purpose in the first sentence. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the tool's function and main parameters for a specific tmux concept. However, it omits the 'target' parameter and could elaborate on the simultaneous dual-location behavior. An output schema is absent, but return values are not essential for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to src and dst with example formats (e.g., 'sess1:2', 'sess2:') and explains select. However, it omits explanation for the 'target' parameter, and schema description coverage is 0%, so the description should compensate more fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('link') and resource ('window'), explaining that the window appears in both locations. This distinguishes it from siblings like tmux_unlink_window and tmux_move_window.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides example syntax for src and dst, and explicitly mentions using tmux_unlink_window to remove a link. However, it does not compare with tmux_move_window or tmux_swap_window to clarify when linking is preferred over moving or swapping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds value by disclosing the return format ('{"clients": [...]}') and that each client includes tty, attached session, and size. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three short sentences, front-loading the main purpose. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return value, which is needed since no output schema exists. However, it fails to document the 'target' parameter, leaving a gap in completeness. The tool is otherwise simple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning parameters are not described in the schema. The description explains the 'session' parameter but entirely omits the 'target' parameter, leaving it undefined. This is insufficient for a low-coverage tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List clients attached to the server,' with a specific verb and resource. It distinguishes itself from sibling tools like tmux_list_sessions or tmux_list_panes by focusing on clients.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the optional session parameter for filtering, which guides usage. However, it does not explicitly state when not to use the tool or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true. The description adds value by explaining the return format (environment dict and removed list) and how removed variables are reported (removed=True, null value). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a front-loaded main purpose and no superfluous words. The return format is clearly specified, though a bit more structure could help.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully documents the return structure without an output schema, but only partially explains the parameters (session and target are not described). For a read-only tool, the missing param details reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains global_ and name parameters but omits details on session and target. This partial coverage adds some meaning but leaves ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it shows a session's environment, with options for global and specific variables, and distinct handling of removed variables. This differentiates it from modification tools like tmux_set_environment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for using the tool (showing environment, global flag) but does not explicitly discuss when to use it over alternatives like tmux_set_environment, or the role of session and target parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates the tool is safe and non-destructive. The description adds that it lists 'local' plus named profiles, which is useful but minimal extra behavioral context. No additional traits like permissions or side effects are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded with the verb and resource, making it easy for an agent to quickly understand the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, a readOnlyHint annotation, and a straightforward purpose, the description is complete. It explains what the tool returns (local plus named profiles), which is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the input schema provides full coverage. The description does not need to add parameter details, and the tool's simplicity makes the description sufficient. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists configured targets, specifically 'local' and named profiles from config. The verb 'List' and resource 'targets' are precise, and the description distinguishes it from other list tools like tmux_list_sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to list targets, but does not explicitly state when to use it over alternatives or when not to use it. Given the many sibling list tools, some guidance would be helpful, but the name and description provide enough context for basic usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the version requirement (tmux 2.6+), no-op behavior on older versions, and specifies the return format. This adequately covers behavioral aspects for a simple set operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each serving a distinct purpose: action, clarifying context, and return format. It is well-structured and front-loaded with the core behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the lack of output schema, the description covers the return format, version constraints, and no-op behavior. It differentiates from related tools but lacks parameter details. Overall, it provides sufficient context for a straightforward task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters with 0% description coverage. The description does not explain their semantics or usage, such as the difference between target_pane and target. It only references target_pane in the return format, leaving the agent without guidance on parameter roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set a pane's title' with the verb and resource, and includes the tmux command and version requirement. It effectively differentiates from sibling tools like tmux_rename_window by noting it does not change the window name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the purpose of the title as a label for agents managing panes, and clarifies it does not affect the window name. It also mentions version requirements and no-op behavior, providing context for when to use it. However, it does not explicitly state when to avoid it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains key behaviors: default split direction, vertical stacking, percentage sizing, and focus behavior via select. It does not discuss reversibility, side effects, or requirements, but covers the main 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with front-loaded purpose and no redundant words. Every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and multiple sibling tools, the description covers the main purpose and key options. It could mention prerequisites or error conditions, but the essential information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explaining src, dst, vertical, percentage, and select. It omits explanation for the 'target' parameter, but overall adds meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'join' and the resources 'src' pane into 'dst' window, and distinguishes it as the inverse of break-pane, which differentiates it from sibling tools like tmux_break_pane.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as the inverse of break-pane, but does not explicitly state when to use this tool versus alternatives or provide exclusions. It covers behavior options but lacks clear guidance on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral transparency burden. It discloses that setting affects commands spawned afterwards, explains the difference between remove (mark for removal) and unset (delete), and notes it is race-free. Minor omission: does not describe effects on existing child processes or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loaded with purpose. It uses parentheses, dashes, and clear terminology. The explanation of race-free alternative adds value but could be trimmed slightly. Overall, efficient for the content conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 1 required, no output schema, and no annotations, the description covers major behaviors (set, unset, global, session) but lacks clarity on the 'target' parameter and default behavior when neither remove nor unset is specified. The return format is partially described but could be more explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 explains global_, value, remove, unset, and session well. However, it confuses session with target (stating 'session is the -t target') without clarifying the separate target parameter. This ambiguity reduces semantic clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set or unset an environment variable for a session (or globally).' This provides a specific verb (set/unset), resource (environment variable), and scope (session/global), distinguishing it from sibling tools like tmux_set_option or tmux_set_hook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: to set environment variables as a race-free alternative to export, and to clear variables using remove or unset. However, it does not explicitly state when not to use it or list alternatives among siblings, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It discloses the failure condition (window only linked once unless not last) and the constraint that tmux refuses to leave a window with no links. This provides sufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a parenthetical clarification. The main action is front-loaded, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the purpose and behavior are well-explained, the lack of parameter explanations leaves the tool incomplete. The agent cannot determine how to specify the window or optional target without additional knowledge. This gap reduces overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, meaning the description must explain parameter meanings. It fails to describe either 'window' or 'target', leaving their semantics unclear. For example, it doesn't specify what format the window identifier should take or what the target parameter does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Unlink a window (remove one of its links).' It also distinguishes from the sibling tool tmux_kill_window by noting that unlinking fails if the window has only one link and suggests using kill_window to destroy it outright.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when not to use this tool (when the window is only linked once) and suggests an alternative (tmux_kill_window). The note about 'refuses to leave a window with no links' clarifies the behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that only the scrollback buffer is cleared, leaving the visible screen untouched. Annotations indicate destructiveHint=true, and the description confirms this non-destructive effect on visible content and specifies the return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loaded with the core action, and efficiently explains the use case and return value without extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and optional parameters, the description covers behavior, use case, and return value. However, the lack of parameter documentation (0% schema coverage) is a missing piece that slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 mentions target_pane only implicitly in the return format and through the tmux command syntax, but does not explain the difference between target_pane and target, their formats, or defaults. This leaves a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool wipes a pane's scrollback history using the tmux command 'clear-history -t pane'. It distinguishes from siblings like tmux_capture_pane and tmux_send_keys by explaining the use case for a clean slate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using this before tmux_send_keys or tmux_run to ensure a clean capture start. It does not provide explicit when-not-to-use criteria, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fully covers behavior: default respawn only if exited, kill flag, env version dependency, return value. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured paragraphs: first for purpose, second for parameters. No redundant sentences. Could slightly tighten env explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides return object and key behaviors. Missing prerequisites like session existence and error handling. For a tool with no output schema and 6 params, it's nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Describes command, start_directory, env, and kill with meaningful context. However, 'target' parameter is unexplained, and schema coverage is 0%. Adds value but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Restart the command in a pane (respawn-pane), reusing it in place,' which is a specific verb+resource. It differentiates from siblings like tmux_respawn_window by focusing on panes without recreating layout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'retrying a crashed command or supervising a service.' Explains kill=True for force-restart. Lacks explicit alternatives or when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the behavior of `text` with literal=True/False, that `keys` are sent directly, and that `enter=True` adds an Enter press. It also states the return value. This is sufficient for understanding the tool's actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two paragraphs and uses effective formatting (e.g., separating modes). It is front-loaded with the main verb and resource. A slightly more structured grouping of parameters could improve readability, but it is already efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (1 required) and no output schema, the description covers the essential functionality (modes, key behaviors). It does not elaborate on error handling or edge cases, but for a tool of this complexity, the provided context is complete enough for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description does not individually describe schema parameters. However, the description adds significant meaning for core parameters (`text`, `keys`, `enter`, `literal`), though it misses `target_pane` (the required one) and `target`. The provided parameters are well explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Send' and the resource 'input to a pane', distinguishing it from sibling tools like tmux_command or tmux_run_shell. The two modes (text/keys) are explicitly explained, making the specific use case unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two modes and provides examples for each, as well as the purpose of the `enter` parameter. However, it does not explicitly state when not to use this tool or mention alternatives among siblings, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to state safe read. It adds the output format example, which gives some behavioral context beyond the annotation, but does not disclose potential limitations or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with purpose and then an example of the return structure. No wasted words, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with no parameters and an annotation confirming safe read, the description is complete: it states what it does and shows the output format. No missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 params), so the description does not need to provide parameter info. The baseline for 0 params is 4, and the description adds the output structure example, which is helpful beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'active control-mode streams and their state'. It distinguishes itself from sibling tmux_stream_* tools (read, resize, send, start, stop) which 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage: when you need to see active control-mode streams and their state. No explicit when-not or alternatives are provided, but given it is the only stream list tool, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral details beyond the readOnlyHint annotation: it explains the polling behavior, the condition for returning (unchanged for idle_seconds or timeout), and the exact return format {'idle', 'elapsed', 'content'}. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 lines) and front-loaded with the main purpose. It uses a clear structure: purpose, then details. Slightly verbose in listing return fields but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and minimal annotations, the description adequately covers the tool's behavior and return value. It lacks details on the 'target' parameter and potential blocking nature, but is sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'idle_seconds' and 'timeout' with their roles, but does not explain 'target_pane' (required), 'poll_interval', or 'target'. With 0% schema coverage, the description provides partial but insufficient parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Wait until a pane's visible content stops changing.' It uses a specific verb ('Wait') and resource ('pane's visible content'), distinguishing it from siblings like tmux_capture_pane (snapshot) and tmux_wait_for_text (wait for text).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when the tool returns: after 'idle_seconds' of no change or after 'timeout'. It provides clear usage context but does not explicitly contrast with alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the return format (stdout, stderr, exit_code) and that non-zero exit codes are returned not raised. It does not mention the timeout parameter or potential side effects, but given the nature of running arbitrary commands, the description is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: first sentence states purpose, then usage example, return format, and target parameter. Every sentence adds value without redundancy, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides return format. It positions itself among 60+ sibling tools as the universal escape hatch. The only gap is the undocumented timeout parameter, but overall it provides sufficient context for tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds significant meaning: it explains that 'args' is a list of subcommand and flags (with example), and describes target values (local, profile, ssh). Timeout is not explained, so not all parameters are covered, but the two key parameters are well-described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run an arbitrary tmux command and return its raw result' and labels it as 'universal escape hatch', which unambiguously defines its purpose. It distinguishes itself from the large set of sibling tools (specific tmux commands) by being the generic fallback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (anything not covered by siblings) with an example of argument format. It also explains the target parameter (local, profile, ad-hoc ssh). However, it does not explicitly state when not to use it or recommend alternatives, though it's implied by the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains conditional execution, format mode, and background flag. It does not cover error handling or side effects, but overall provides good transparency for a conditional command.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs with a clear summary line followed by parameter details. No unnecessary words. Well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and conditional logic, the description covers the core behavior and most parameters. Missing explanation of target parameter, but otherwise sufficient for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It explains condition, if_command, else_command, background, is_format. However, the target parameter is not mentioned, leaving it semantically incomplete for a 6-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a tmux command conditionally based on a shell command or format condition. It differentiates itself from other tmux tools by focusing on conditional execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the condition behavior and two modes (shell vs format). It does not explicitly mention when to use this tool versus alternatives like tmux_command, but the conditional nature is implied. Clear context for typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the effect of key parameters (global_ for server-wide, unset for removal) and notes the tmux 2.2+ requirement. It does not describe side effects like overwriting existing hooks or response format, but the core behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the purpose, then parameter explanations, then version requirement. Every sentence adds value, and there is no repetition or fluff. Extremely concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (1 required) and no output schema, the description covers the main functional aspects. It misses the 'target' parameter and could mention scope, but overall it provides enough to use the tool effectively. A minor gap prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It explains all parameters except 'target' with concrete examples (e.g., 'pane-died', 'gone'). The omission of 'target' is a gap, but the other four parameters are well-described, adding significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set (or unset)' and the resource 'hook that runs a tmux command on an event', distinguishing it from sibling tools like tmux_set_environment or tmux_set_option. It specifies that hooks are event-driven, which is unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: to define behavior upon events. However, it does not explicitly mention when not to use it or list alternatives, such as using tmux_show_hooks for inspection. The context is sufficient but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the size sticks across auto-reconnects and returns a specific object. It does not mention destructive effects or prerequisites, but the operation is clearly a resize and likely safe. Overall, it provides sufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences and a return specification. Every sentence provides essential information: the action, the use case, persistence behavior, and output format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (3 parameters, no output schema, no annotations), the description covers the core functionality, use case, and output. It does not explain error conditions or parameter constraints, but for a resize operation, this level of detail is likely sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It mentions width and height in the context of the resize operation and in the return format, implying their meaning. However, it does not explicitly define each parameter (e.g., that stream_id is the target stream). This is adequate but leaves some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'stream's control-client size', and provides a specific use case for when pane output wraps at the wrong width. It distinguishes itself from sibling stream tools (list, read, send, start, stop) by focusing on resizing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this when pane output wraps at the wrong width', giving a clear condition for when to invoke this tool. It also mentions the default size (80x24) and that the size persists across reconnects, providing context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description covers key behaviors: persistent connection, idempotency, auto-reconnect, event capture, size re-application. Does not mention prerequisites like session existence or potential failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two paragraphs, each sentence earns its place. Front-loaded with purpose, then behavior, then parameter details. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers return format, idempotency, auto-reconnect, and size behavior. No output schema, but description explains return value. Could mention potential limits on number of streams, but overall complete for a stream initialization tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond input schema: explains session is required, width/height together set client size, default 80x24, and target is optional. Schema coverage is 0%, so description compensates well, though target could be clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Open (or reuse) a control-mode stream attached to session.' It specifies the verb (open/reuse) and resource (stream). Idempotency note and distinction from sibling stream tools (read, send, stop) enhance clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use (starting a stream, setting size with width/height), and mentions subsequent tools (read, send, stop). However, lacks explicit when-not-to-use or alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint annotation, description discloses return format {matched, elapsed, content}, history capability, and the caveat about matching echoed input. Adds significant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with core purpose and parameter list. No redundant words; every sentence adds value. Well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main parameters and return values, but omits details on poll_interval and target. For a 7-parameter tool with no output schema, it's fairly complete but could be slightly more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains pattern (substring vs regex), timeout, regex flag, and history. However, poll_interval and target are not described, leaving gaps. Partial compensation earns a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for a pattern to appear or timeout, with specific verb 'Wait' and resource 'pane'. It distinguishes from siblings like tmux_capture_pane or tmux_run by noting to prefer tmux_run for waiting for command completion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use an alternative: 'To wait for a command to *finish* and get just its output, prefer `tmux_run`.' Also warns about the caveat of matching echoed input, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations give readOnlyHint=true, and the description reinforces read-only behavior. It details special behaviors: start/end line range handling, escapes, join, trim, and the return format. No contradictions. The description adds value beyond annotations by explaining these nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long, front-loaded with purpose, and each sentence provides essential detail without redundancy. It efficiently conveys the tool's function, parameters, and return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema), the description covers the return value and explains most parameters. The two unmentioned parameters (target_pane, target) are common in tmux tools and may be inferred, but their omission is a minor gap. Overall complete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It thoroughly explains start, end, escapes, join, and trim. However, it omits explanations for target_pane and target, which are two of seven parameters. Despite this, the most critical parameters are well described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Capture (read) the visible contents and/or scrollback of a pane' with a specific verb and resource. It distinguishes itself as 'the primary way to observe output', differentiating from sibling tools like tmux_command or tmux_send_keys which write or execute commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'This is the primary way to observe output.' It implies use for reading pane content. However, it does not explicitly state when not to use it or mention alternative tools for similar tasks, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully bears responsibility. It discloses default behavior, force-kill option, command default, directory setting, environment injection behavior (with tmux version note), and return format. Comprehensive disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise with no wasted words. Front-loaded with purpose, then parameter details. Structured logically from default behavior to overrides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 1 required, and no output schema, description covers behavior, parameters, return value, and version constraints. Missing 'target' parameter and could clarify return format with more detail, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains 5 of 6 parameters (window implied, command, kill, start_directory, env) but misses 'target'. Adds significant meaning beyond schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Restart the command' and resource 'window (respawn-window)', and clearly distinguishes from sibling 'tmux_respawn_pane' by noting it applies to the whole window (single/first pane).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: default behavior only for exited commands, force restart with kill=True, defaults for command and start_directory, and environment handling caveat. However, does not explicitly compare to alternatives or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the exact mechanism (unique markers, polling) and return format ( {"completed", "exit_code", "output", "elapsed"} ), including timeout behavior. No annotations provided, so description carries full burden and meets it well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with purpose, and every sentence adds essential information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core operation, return values, and timeout handling. Lacks explicit explanation of history and target parameters, but overall adequate given no output schema and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning for command, timeout, and poll_interval, but misses target_pane, history, and target. With 0% schema coverage, it partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a shell command in a pane and returns output + exit code, and distinguishes itself from 'send-keys + sleep + capture' as a reliable alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it is intended for non-interactive commands and contrasts with the send-keys approach, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses detached default, `attach_or_create` reuse logic, `env` version dependency, and return format. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but front-loaded with core purpose. Each sentence adds value, though some rephrasing could tighten it slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description thoroughly covers behavior, side effects, version constraints, and return values. It is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for 9 parameters. The description adds meaningful details for all key parameters: `command`, `start_directory`, `width`, `height`, `attach_or_create`, `env`, and return values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new tmux session, detached by default. It distinguishes from siblings like `tmux_has_session` and `tmux_new_window` by detailing the `attach_or_create` idempotency feature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use `attach_or_create=True` and contrasts with tmux's `new-session -A`. It provides context for detached operation but does not explicitly list when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes blocking behavior, return format, filtering, cursor mechanics, and lagged flag. Consistent with readOnlyHint annotation, adding context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose, then return format, then parameter details. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description fully covers return values structure, event types, filtering options, and edge cases like lagged overflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description explains all parameters including timeout, max_events, pane, kinds, cursor, and strip_ansi, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Long-poll new events from a stream' with specific verb and resource, distinguishing it from sibling tools like tmux_stream_start or tmux_stream_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use it (to get new events with blocking) and how cursor auto-advances, but doesn't explicitly state when not to use or list alternatives, though sibling differentiation is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-tmux MCP server](https://glama.ai/mcp/servers/laszlopere/mcp-tmux/badges/card.svg)](https://glama.ai/mcp/servers/laszlopere/mcp-tmux)

Score Badge

Copy to your README.md:

[![mcp-tmux MCP server](https://glama.ai/mcp/servers/laszlopere/mcp-tmux/badges/score.svg)](https://glama.ai/mcp/servers/laszlopere/mcp-tmux)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/laszlopere/mcp-tmux'

If you have feedback or need assistance with the MCP directory API, please join our Discord server