mcp-tmux

Server Quality Checklist

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

Latest release: v0.1.10
Disambiguation2/5
Many tools have overlapping purposes, such as tmux_state vs tmux_readonly_state, tmux_capture_pane vs tmux_context_history, and tmux_tail_pane vs tmux_tail_task. Descriptions help somewhat, but an agent could easily misselect among capture, state, and layout variants.
Naming Consistency4/5
All tools consistently use the tmux_ prefix and lowercase snake_case, with most following a verb_noun pattern (list_sessions, send_keys, kill_pane). However, a few are noun phrases or less conventional (tmux_state, tmux_server_info, tmux_context_history), creating minor inconsistency.
Tool Count2/5
40 tools is excessive for a tmux wrapper; many are near-duplicates or variations (e.g., capture vs state, layout vs profile, tail vs wait). The surface could be reduced to roughly 15-20 distinct tools without losing core functionality.
Completeness5/5
The tool set thoroughly covers tmux lifecycle (sessions, windows, panes), inspection, capture, layout management, and task-based polling. The inclusion of tmux_command as a generic escape hatch ensures any missing subcommand can still be executed, leaving no obvious gaps.
Average 3.5/5 across 40 of 40 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on December 14, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It lists what is checked (availability, PATH/bin, sessions) but does not state whether the tool is read-only, whether it connects via SSH, what side effects might occur, or how failures are handled. This is minimal disclosure for a tool that operates on a host.
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, front-loaded with the action verb 'Check', and is perfectly concise. Every word contributes to the tool's purpose, with no fluff or extraneous 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?
The tool is simple (one optional parameter) but has no output schema, so the description should explain what the result looks like. It only lists the checks performed without describing the return format or how to interpret results. Additionally, there's no usage context or prerequisites, making the description incomplete for fully understanding the tool's behavior and output.
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 input schema already provides full coverage of the single parameter 'host', including a clear description and optionality. The tool description adds little beyond mentioning 'for a host', not enriching the parameter semantics. Baseline 3 is appropriate given the 100% schema coverage.
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 checks tmux availability, PATH/bin resolution, and session listing. The verb 'Check' plus specific resources make the purpose clear, and it distinguishes from siblings like tmux_list_sessions by bundling multiple health-related checks. However, it doesn't explicitly differentiate itself from related tools like tmux_server_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. There is no mention of when a health check is appropriate or how it differs from specific tools like tmux_list_sessions or tmux_state. The title 'Health check' implies a use case, but the description itself gives no explicit usage 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?
With no annotations, the description carries the full burden of behavioral disclosure. It hints at destructiveness via 'Use with care,' but does not mention that the operation is irreversible, that it will terminate processes or close the window's content, or that a confirm parameter must be true for it to proceed. The description is too vague to prepare the agent for the tool's side effects.
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 at two short sentences with no fluff. 'Use with care' is a minimal warning that adds a bit of caution, though it could be more specific. It is well-structured and front-loaded, but the generic warning prevents a perfect score.
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 no annotations and no output schema, the description is insufficient. It does not explain what happens when a window is killed (e.g., whether the session closes, processes are terminated), nor does it mention the confirmation requirement or any side effects. The schema covers parameters, but the description leaves major behavioral 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?
Schema description coverage is 100%, so the description need not add parameter details. The description adds no additional meaning to the parameters; it only restates the tool's action. This meets the baseline for high schema coverage, but does not exceed it.
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 ('Close a tmux window') and resource (window), which distinguishes it from sibling tools like kill_session and kill_pane. However, it doesn't explicitly mention alternatives or why this tool exists beyond the obvious from its name, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The only additional text is 'Use with care,' which is a warning rather than usage context. No prerequisites, alternatives, or scenarios are provided, leaving the agent to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it merely restates the action. It does not mention side effects, validation behavior, or error handling, making it tautological and uninformative.
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, front-loaded sentence with no wasted words. It is appropriately concise for a simple operation.
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?
Although the operation is simple, the description lacks behavioral context and adds nothing beyond the title. With no annotations and no output schema, the tool needs more explanatory depth than a one-line restatement of the name.
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 schema fully documents all parameters with clear descriptions, so the description adds no additional semantic value. The high schema coverage (100%) warrants the baseline score of 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 action (rename) and the resource (a tmux session), distinguishing it from sibling tools like tmux_rename_window, which targets windows instead of sessions.
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, such as tmux_rename_window, or any prerequisites or context indicating when renaming a session 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?
With no annotations, the description carries the full burden of disclosing behavior. It only states that it displays defaults, without confirming read-only nature, output format, or behavior when no defaults are set. The title's 'Show' hints at non-destructive action but does not provide explicit behavioral detail.
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 concise sentence with no extraneous words. It is front-loaded with the verb 'Display' and immediately conveys the core action and object.
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?
There is no output schema and no annotations, so the description should explain what the tool returns. It merely says 'defaults' without specifying the structure (e.g., key-value pairs for host/session/window/pane) or any preconditions, leaving significant gaps for a simple getter.
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?
This tool has zero parameters and full schema coverage. The baseline for 0 params is 4, and the description does not need to explain parameters, though it also adds no additional semantic value beyond the schema.
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 'Display the current remembered defaults' clearly indicates a getter operation, and the title specifies the scope as host/session/window/pane. It distinguishes from sibling tools like tmux_set_default, though it could be more explicit about what 'defaults' refers to in the description itself.
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 information about when to use this tool versus alternatives. It lacks context such as checking defaults before creating a session or comparing against current state, leaving the agent to infer usage from the tool name.
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 implies destructiveness ('Use with care') but does not state that the pane is permanently killed, that running processes are terminated, or that confirmation is required. The mandatory `confirm` parameter is not mentioned in the description, leaving the safety mechanism undocumented.
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 brief—two short sentences with no fluff. It is appropriately concise, though the 'Use with care' phrase is somewhat vague. It is well-structured and front-loaded with the core action.
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 no annotations and no output schema, the description is under-specified. It fails to mention the confirmation requirement, the irreversible nature of the kill, or any context about when it is safe to use. The schema covers parameter meanings but not the behavioral context.
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?
All three parameters have descriptions in the schema (100% coverage), so the description adds no extra parameter insight. The baseline of 3 applies because the schema carries the heavy lifting.
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 states 'Close a tmux pane,' which clearly identifies the verb (close/kill) and the resource (pane). It distinguishes from sibling tools like kill_session and kill_window, which target different tmux objects.
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, nor are there any prerequisites or side effects mentioned. 'Use with care' is a generic caution that does not explain appropriate usage conditions.
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 carries the full burden. It mentions the optional Enter behavior but does not disclose potential side effects of sending keystrokes (e.g., triggering destructive commands in the pane), nor does it cover failure modes or reversibility.
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?
One concise sentence that immediately conveys the tool's primary function. No filler or redundant 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?
With a complete schema and a clear summary, the description covers the 'what' but lacks the 'when' and missing behavioral warnings. As a mutating input tool, it would benefit from context on appropriate use cases and potential risks, making it minimally viable but not fully 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?
Schema descriptions cover all 4 parameters with detailed information (special keys, default pane/host, enter behavior). The tool description itself adds no new parameter information beyond what the schema already provides, so baseline 3 is appropriate.
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 (send keystrokes) and the resource (tmux target) with an optional Enter suffix. It distinguishes from capture/state tools but doesn't explicitly contrast with tmux_command or other input-related siblings.
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 vs alternatives. The description does not mention preferred contexts, exclusions, or relationships to sibling tools like tmux_command or tmux_capture_pane.
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 carries full responsibility for disclosing behavior. It only states the output ('Return sessions, windows, panes, and last lines') and does not disclose whether the operation is read-only, has side effects, or has any limitations. The verb 'Return' implicitly suggests a read operation, but minimal explicit behavioral context is given.
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, well-structured sentence that immediately states what the tool returns. There is no unnecessary information or filler, making it highly concise 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?
The tool has no output schema, and the description does not explain the structure of the returned data or the effect of the optional parameters. Given the many sibling tools with overlapping functionality, the description lacks contextual guidance to help an agent choose appropriately. It is adequate for the simple read operation but leaves 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 input schema has 100% coverage with descriptions for all three parameters (host, session, captureLines). The tool description adds no extra semantic meaning beyond the schema, so the baseline of 3 is appropriate.
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 returns a snapshot of tmux state including sessions, windows, panes, and last lines. The verb 'Return' is specific and the resource list is concrete. However, it doesn't explicitly differentiate from sibling tools like tmux_list_sessions or tmux_capture_pane, so it doesn't fully earn a 5.
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 such as tmux_list_sessions, tmux_capture_pane, or tmux_readonly_state. There is no mention of preferred use cases, exclusions, or alternatives.
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 provided, the description carries the full burden of behavioral disclosure. It states that the session is 'Terminate[d]' and advises care, but it does not disclose permanence, effects on child windows/panes, or the required confirmation step (which exists as the 'confirm' parameter in the schema). The warning is generic and lacks specific consequences.
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 two short sentences with no wasted words. The first sentence states the purpose, the second adds a caution. This is ideal conciseness for a simple tool.
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?
Despite full schema coverage, the description omits critical context for a destructive operation: it does not mention that the action is irreversible, will terminate all windows/panes within the session, or that the tool expects confirm=true to proceed. It relies on the title, name, and schema to carry meaning that should be in the description.
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 input schema fully describes all three parameters (target, host, confirm) with 100% coverage, so the description adds no additional parameter-level meaning. The baseline of 3 is appropriate because the schema already holds the semantic load.
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 uses the specific verb 'Terminate' with the resource 'tmux session', clearly distinguishing it from sibling tools like tmux_kill_window and tmux_kill_pane. This is a precise, non-tautological statement of purpose.
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 given on when to use this tool vs alternatives. 'Use with care' is a caution about handling, not a selection criterion, and there is no mention of when a session should be killed or that sibling tools like tmux_kill_pane/window are more appropriate for finer-grained 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 provided, so the description carries the full burden. It states the primary action but does not disclose side effects (e.g., whether the new window becomes active), error behavior, or any other behavioral traits. The description is superficial and does not help the agent anticipate consequences beyond 'create a window'.
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, front-loaded with the core action. The phrase 'useful for side-by-side collaboration' is somewhat extraneous but not harmful. It is concise and to the point, with no redundant repetition of the name.
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, 100% schema coverage, and no output schema, the description is adequate but lacks important context. It does not mention what happens after creation (e.g., window activation), how it interacts with other tools, or any limitations. There are clear gaps, but not severe enough for a lower score.
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 100%, with every parameter described in the schema (e.g., target as 'Target session (or window)...' and command as 'Optional command to run when the window starts'). The description adds no additional parameter meaning; it merely reiterates 'target session'. Baseline 3 is appropriate because the schema does the heavy lifting.
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: 'Create a window in a target session', which is specific and matches the tool name. It distinguishes from siblings like tmux_new_session by focusing on windows, though it does not explicitly name alternatives. The 'side-by-side collaboration' phrase adds a use case but not differentiation.
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 for creating windows in existing sessions, especially for side-by-side collaboration. However, it provides no explicit when-to-use vs. alternatives, no exclusions, and no mention of prerequisites like whether the target session must exist. This is minimal guidance.
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 does not mention whether saving overwrites existing profiles, whether it requires an active session, or any side effects on the tmux environment. The mutating nature is implied but not detailed.
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 concise sentence that clearly conveys the core purpose without extraneous information. It is effectively front-loaded and appropriately sized.
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?
The description lacks context about default behavior (host/session fallbacks), overwrite semantics, or how this tool relates to sibling tools like tmux_capture_layout. While the schema explains parameters, the overall usage context is under-specified for a tool with optional parameters and no output schema.
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 100%, with all three parameters (host, name, session) having descriptions. The tool description adds no parameter-specific detail beyond the schema, so a baseline score of 3 is appropriate.
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 captures layouts for all windows in a session and stores them under a profile name. This specific verb+resource+scope distinguishes it from sibling tools like tmux_capture_layout (which likely captures current layout) and tmux_apply_layout_profile (which applies profiles).
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_capture_layout or tmux_restore_layout. The description does not mention prerequisites, exclusions, or the recommended context for saving a full-session profile.
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. It only restates the name and function without disclosing behavioral implications, such as that synchronize-panes affects all panes in the target window, whether the change is persistent, or if any permissions are required. This lacks depth 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant wording. It is efficiently front-loaded with the core action. It loses one point for being so minimal that it borders on under-specification, but overall it is appropriately sized.
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 setter with fully described parameters and no output schema, the description is minimally viable. It conveys the essential purpose but omits behavioral context such as the effect on all panes. This is sufficient for a straightforward toggle, hence a score of 3.
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 100%, so the baseline is 3. The description does not add any parameter meanings beyond what the schema already provides. The schema adequately explains 'on' and 'target', so no additional clarification is needed.
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 specific action: 'Enable or disable synchronize-panes for a window.' It identifies the verb (enable/disable), the resource (synchronize-panes), and the scope (a window). This is unambiguous and distinguishes it from sibling tools that handle other tmux settings.
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. It does not mention any exclusions or prerequisites beyond what the schema implies. The tool's purpose is clear, but there is no explicit usage context, which earns a score of 2.
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 provided, the description carries the full burden. It discloses a key behavioral trait: the tool polls without reissuing commands, implying it is non-intrusive and does not send input to the pane. However, it does not describe the output format, whether the pane is read-only in all cases, or any side effects like resource usage or blocking behavior.
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, well-structured sentence that immediately conveys the core action and its key nuance ('without reissuing commands'). No redundant or filler words; the length is appropriate for the tool's simplicity.
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?
The tool has 5 parameters, no output schema, and no annotations. The description covers the polling concept but omits what the tool returns (e.g., accumulated pane text, per-iteration output) and does not explicitly state it is a read-only operation. While the schema fully documents parameters, the lack of output and safety details makes the description incomplete for an agent to fully anticipate behavior.
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 100%, so the baseline is 3. The description adds little to the parameters themselves, but it does clarify that the polling is repeated and non-command-based, which gives context to intervalMs and iterations. The parameter names and schema descriptions already cover their meaning.
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 uses a specific verb 'poll' and a specific resource 'pane', clearly indicating the tool repeatedly fetches pane output. It distinguishes from simple capture by emphasizing 'multiple times' and 'without reissuing commands,' but does not explicitly name alternative tools like tmux_capture_pane.
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 gives no explicit guidance on when to use this tool versus alternatives. It does not mention that tmux_capture_pane is for one-time capture or that tmux_tail_task might be for task-based tailing. The intended use case is implied but not stated, and no exclusions or prerequisites are provided.
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 the burden of disclosing behavioral traits. It mentions that the tool creates a task and that the client polls for incremental results, which hints at async behavior. However, it does not disclose the task lifecycle, auto-completion, error behavior, or how polling interacts with the server-side task, leaving significant 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 only two sentences, front-loaded with the core action, and every word earns its place. It is concise without being under-specified to a tautology, making it an ideal length for the information it conveys.
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 complexity (async task creation, 5 parameters, no output schema, no annotations), the description is too thin to give an agent a full picture. It does not explain what a 'task' means in this environment, how the client polls results, when the task auto-completes, or how it differs from similar tools. The schema covers parameters but not the operational behavior.
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 100% with each parameter described (host, lines, target, intervalMs, iterations). The description adds no extra parameter semantics beyond the schema, so the baseline of 3 applies. There is no additional nuance or context provided for 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 creates a task to poll pane output over time, with a specific verb ('create') and resource ('task to poll pane output'). It implies a long-running/async behavior distinguishing it from one-shot capture tools, though it does not explicitly name alternatives like tmux_tail_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 phrase 'Client can poll for incremental results' implies the usage scenario (when you need ongoing output over time), but there is no explicit guidance on when to choose this tool versus tmux_tail_pane or other task-based tools. No exclusions or alternatives 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?
With no annotations, the description must carry the full burden of behavioral disclosure. It does disclose a key behavior—creating a detached session—which implies the session runs in the background after the tool returns. However, it does not mention what happens if the session already exists, how the host default is used, or any side effects beyond session creation.
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 that is direct and free of filler. Every word contributes meaning ('detached', 'collaborate'), and it is appropriately sized for the tool's simplicity.
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 no output schema and only 3 parameters, the description is minimally adequate. It covers the core action and a key behavioral trait (detached), but lacks guidance on return values, error cases, and interaction with the host parameter. It is sufficient for the simplest use cases but leaves gaps for an agent needing deeper context.
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 100%, and the description adds no parameter-specific details beyond what the schema already documents. It does not explain how 'command' or 'host' are used in practice, so no extra semantics are provided.
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 creates a detached tmux session, using the specific verb 'create' and identifying the resource (session). The 'detached' qualifier distinguishes it from opening or attaching to an existing session, though it does not explicitly name sibling alternatives.
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 explicit guidance on when to use this tool versus alternatives like tmux_open_session or tmux_new_window. The 'collaborate in' phrase implies a collaborative use case, but there is no direct when-to-use or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of disclosing behavioral traits. It only states the operation without mentioning side effects, potential errors when the target window doesn't exist, or any permissions/requirements. For a mutation tool, this is insufficient.
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 concise sentence with zero fluff. It states the purpose clearly and effectively, earning its place without 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?
Given the simplicity of the operation, the description combined with the fully documented schema is adequate for basic usage. However, it lacks contextual guidance about when to use it, what happens if the target is invalid, or how it relates to session renaming. This leaves some gap for an AI 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 description coverage is 100%, and each parameter (host, name, target) already has a clear description. The tool description adds no additional meaning beyond what the schema provides, so the baseline of 3 is appropriate.
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 'Rename a tmux window' clearly states the verb (rename) and resource (tmux window), distinguishing it from sibling tools like tmux_rename_session or tmux_new_window. It is direct and unambiguous.
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 such as tmux_rename_session or tmux_select_window. There is no mention of prerequisites (e.g., running tmux server) or exclusions, leaving the agent without contextual 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 carries the full burden. It discloses that selection affects subsequent commands, which adds a small behavioral context beyond the title, but it does not mention side effects, state persistence, error behavior, or any other relevant traits. Minimal 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?
A single sentence that is direct and efficient, with no filler or repetition. It conveys the essential purpose and consequence without wasted words.
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 is simple with one required parameter, and the description is adequate for a basic selection action. However, it lacks explicit usage guidance and behavioral depth, leaving questions about context scope and side effects unanswered.
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 input schema already fully documents both parameters with descriptions (100% coverage), so the baseline is 3. The description adds no additional information about target formatting or host behavior beyond what the schema provides.
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 selects a window and that subsequent commands will target it, using a specific verb and resource. It does not explicitly contrast with tmux_select_pane, but the window vs pane distinction is evident from the name and title, so it falls short of fully differentiating from siblings.
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 before subsequent commands that should target the window ('so subsequent commands target it'), giving a clear context. However, it provides no explicit guidance about when to use this tool instead of alternatives like tmux_select_pane, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states 'apply' which implies mutation, but does not disclose whether it overwrites the current layout, what happens if the target doesn't exist, or any other side effects. 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 a single sentence, 9 words, front-loaded with the verb 'Apply'. It is concise with no wasted words or redundant information.
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 no annotations and no output schema, the description should provide more context about behavior, prerequisites, and return value. It only states the action, leaving the agent without guidance on side effects or success/failure conditions. This is inadequate for a mutation 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?
Schema description coverage is 100%, with useful details like 'Layout string obtained from tmux_capture_layout' and 'Window target (e.g., session:window or window id)'. The description adds only the phrase 'saved layout string', which largely repeats the schema. The baseline of 3 is appropriate.
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 'Apply a saved layout string to a target window' uses a specific verb (apply) and identifies the resource (layout string, target window). It clearly distinguishes from siblings like tmux_capture_layout (capture) and tmux_apply_layout_profile (profile-based).
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: you have a layout string from tmux_capture_layout and want to apply it to a window. It does not explicitly state when to use this over tmux_apply_layout_profile or mention any exclusions or alternatives.
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 carry full behavioral disclosure. It discloses two key behaviors (matching by index, pane count compatibility) but does not mention potential destructiveness, behavior for unmatched windows, or error conditions. This is moderate 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 purpose, and no wasted words. The critical constraints are stated efficiently.
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 essential matching behavior but omits what happens to unmatched windows, whether it creates new windows, the return format, or error handling. Given the tool's moderate complexity, it is minimally adequate but not fully 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?
Schema coverage is 100%, so the baseline is 3. The description does not add parameter-specific meaning beyond the schema; it only provides general behavioral context that applies to all 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 applies a saved layout profile to a session, using a specific verb and resource. It distinguishes from save_layout_profile, though it does not explicitly differentiate from restore_layout or other layout-related siblings.
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 constraints (windows matched by index, pane counts must be compatible) but does not explicitly say when to use this tool over alternatives like restore_layout. The context implies usage for saved profiles, but no exclusions or alternative guidance are given.
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 carries the full burden. 'Read' implies a non-destructive operation, but the description does not disclose potential side effects, limitations (e.g., scrollback buffer limits), or conditions like needing a target pane. Minimal behavioral detail.
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?
A single, front-loaded sentence that directly states the tool's purpose. No wasted words, ideal size.
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 read-only capture tool with four optional parameters and no output schema, the description provides the core purpose but lacks guidance on common use cases, parameter interactions, or return format. It is minimally sufficient but not rich.
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 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema, but the schema fully documents start, end, host, and target 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 reads a pane's scrollback to observe command results, using a specific verb and resource. It implicitly distinguishes from siblings like tmux_tail_pane (live tail) and tmux_capture_layout (layout capture).
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 phrase 'to observe command results' implies when to use it (after commands run), but no explicit alternatives or exclusions are mentioned. With many sibling tools, more explicit guidance would help.
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 carry the burden of behavioral disclosure. It only repeats what the input schema already documents (horizontal/vertical, optional command) and does not add details such as the effect on the target pane, whether a new pane is created, or any state changes. This is insufficient for a mutation-type 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 a single concise sentence that front-loads the core action and includes the key options. Every word is purposeful, and there is no redundant or filler content.
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 simple nature of the tool and complete parameter schema, the description is adequate but not rich. It lacks any mention of side effects, prerequisites, or return values, and with no annotations or output schema, a bit more context on what happens when a pane is split would improve 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?
The input schema has 100% description coverage for all parameters, so the schema already documents host, target, command, and orientation. The description adds no additional meaning beyond the schema, which meets the baseline but does not exceed it.
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 'split' with the resource 'pane' and explicitly mentions the two possible orientations (horizontally or vertically) plus the optional command. This is specific and easily distinguishes it from sibling tools like tmux_select_pane or tmux_new_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 implies the intended use (splitting a pane) but does not explicitly discuss when to use this tool over alternatives. There is no mention of exclusions or preferred contexts, leaving the agent to infer usage from the purpose alone.
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 provided, the description carries the full transparency burden. It does disclose the core polling behavior and completion conditions, which is valuable. However, it omits key behavioral details such as what happens when iterations are exhausted (error vs. graceful return), whether the tool returns matched output, and any side effects (or lack thereof). This is a moderate disclosure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core action and includes the key termination logic. Every word contributes meaning, with no redundancy or filler.
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 moderate complexity (7 parameters, 1 required) and the absence of both annotations and an output schema, the description is adequate but incomplete. It explains the basic polling loop but does not clarify the return value, error behavior, or relationship between intervalMs and iterations. The rich schema descriptions compensate only for parameter meaning, not for runtime behavior.
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 100%, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides—it merely restates the concept of 'regex pattern' and 'iterations' without explaining parameter interactions or format details.
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 identifies the action ('Poll a pane') and the goal ('for a regex pattern'), with a specific termination condition ('complete when matched or after iterations'). It is semantically distinct from sibling tools like tmux_capture_pane or tmux_tail_pane, but it does not explicitly name alternatives as the rubric's highest tier requires.
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 a usage scenario: use this when you need to wait for a regex pattern to appear in a pane. However, it provides no explicit guidance on when to prefer this over alternatives (e.g., tmux_tail_pane, tmux_watch_dir_task) nor any exclusions or prerequisites, leaving selection to the agent.
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 burden of behavioral disclosure. 'Enumerate' implies a read-only operation, and specifying the output contents adds some transparency, but it does not explicitly confirm no side effects, mention prerequisites, or describe the return structure beyond counts. The description adds modest value but lacks rich 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?
The description is a single sentence of 10 words, front-loaded with the verb 'Enumerate.' Every word contributes meaning, with no filler or redundancy.
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 tool with one optional parameter and no output schema, the description is mostly complete: it states what is listed and includes attachment counts and window totals. However, it does not explicitly describe the return format (e.g., list vs. table) or any usage context, leaving minor 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 input schema already provides full coverage of the single 'host' parameter, with a clear description. The tool description does not add any additional meaning to the parameter, so the baseline score of 3 is appropriate.
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 enumerates sessions and specifies exactly what information is provided (attachment counts, window totals). This uses a specific verb and resource, distinguishing it from sibling tools like tmux_list_windows and tmux_list_panes.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention when not to use it or provide any context such as 'use for an overview of all sessions.' No exclusions or alternative tool references are present.
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 provides two important behavioral traits: 'readonly' and 'parallel'. These add value, especially since no annotations are provided. However, it does not disclose potential caveats such as partial failure behavior, output format, or whether there are limits on concurrency. The readonly hint is strong, but the description remains thin on other execution characteristics.
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, concise sentence that front-loads the essential action and scope. It avoids unnecessary detail and is easy to parse, making it highly efficient for an agent.
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?
The tool has a moderately complex input schema (array of objects) and no output schema. The description does not explain the return format, how errors are handled, or any prerequisites. Given the batch nature and complexity, the description is insufficient for an agent to fully understand the tool's behavior without additional inference.
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 explain any parameters. While the schema includes some descriptions for nested properties and defaultLines, the top-level 'targets' parameter and 'defaultLines' are not described in the tool description. With schema description coverage at 50%, the description should compensate, but it adds no parameter guidance beyond the general idea of 'multiple panes'.
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: to capture scrollback from multiple panes in parallel. The verb 'capture' and specific resource 'scrollback from multiple panes' differentiate it from sibling tools like tmux_capture_pane (which captures a single pane) and tmux_tail_pane (which tails output). The addition of 'parallel' further clarifies its batch nature.
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 implies usage for capturing scrollback from multiple panes simultaneously, which gives clear context for when to use this tool. However, it does not explicitly name alternatives or state when not to use it. Since it says 'multiple panes', it is clear this is meant for batch scenarios, which is distinct from single-pane capture.
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 provided, the description carries the full burden of behavioral disclosure. It mentions heuristic command extraction but does not explicitly state that it is a safe read-only operation, what dependencies exist (e.g., tmux session required), or any potential side effects. This leaves significant 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 a single sentence that front-loads the core action and purpose, with no wasted words. Every phrase adds value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 optional parameters and no output schema, so the description should cover more ground. It explains the core function but omits details about default target selection, return format, or the nature of the heuristic extraction, leaving the agent with partial context.
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?
All 5 parameters have thorough descriptions in the schema (100% coverage), so the baseline is 3. The tool description itself adds no parameter-level meaning beyond what the schema already provides.
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 ('Capture recent scrollback from a pane or session') and its purpose ('infer context'), while the added 'also extracts recent commands heuristically' distinguishes it from similar capture tools like tmux_capture_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?
It provides a clear usage context ('to infer context'), indicating when the tool would be appropriate. However, it does not explicitly name alternatives or exclusions, so it stops short of a 5.
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 burden of behavior disclosure. It reveals a key behavioral trait — 'Omit fields you do not want to change' — indicating partial updates and persistence. However, it doesn't state return values, scope of persistence, or whether defaults are global or per-context, which weakens transparency.
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 short sentences, front-loaded with the core action. Every word earns its place; no filler or redundancy.
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 tool with four optional parameters, no output schema, and no nesting, the description covers the essential usage and behavior. The only gap is ambiguity about the exact scope of 'defaults' and how they apply, but this is minor given the tool's simplicity.
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 100%, giving the baseline of 3. The description adds collective parameter meaning beyond individual field descriptions: 'Omit fields you do not want to change' tells the agent that each omitted parameter remains untouched, which is a useful semantic that the schema alone does not convey.
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 purpose with the verb 'Persist' and the resource 'defaults'. It's distinct from sibling tools like tmux_get_default, though it doesn't explicitly name the four target fields (host/session/window/pane), which are only in the title and schema.
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 phrase 'for later tool calls' implies when this should be used, but the description does not explicitly contrast it with tmux_get_default or mention any exclusions. No alternatives are named, so guidance is implied rather than direct.
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 the polling loop and both exit conditions (new file or max iterations), which is useful. However, with no annotations, it does not specify what constitutes a 'new' file (e.g., based on mtime or creation), whether SSH requires credentials, or if the tool blocks. This is acceptable but not deep.
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 that is front-loaded with the primary action ('Poll a directory') and specifies the completion criteria without unnecessary words.
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 poll task, the description covers the core loop but leaves some behavioral details unspecified (e.g., recursive watching, return value). Given no output schema or annotations, this is minimally viable.
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 schema already provides 100% coverage and descriptions for all four parameters. The tool description adds no additional parameter semantics beyond the schema, so the baseline of 3 is appropriate.
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 polls a directory and completes when new files appear or after max iterations. This is a specific verb-resource pair with clear termination conditions, distinguishing it from sibling tasks like pattern matching or tailing.
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?
No explicit guidance on when to use this tool versus alternatives like tmux_wait_for_pattern_task. The usage is implied by the directory-polling behavior, but it does not state exclusions or preferred scenarios.
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. The word 'Returns' implies a read-only operation, but there is no explicit statement that it does not modify tmux state. It also fails to disclose potential caveats, such as what happens when no default session exists (though '(if any)' hints at it).
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, focused sentence that front-loads the primary action and output. Every word earns its place; there is no verbosity or redundancy.
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 zero-parameter tool, the description provides a reasonable overview of the return value. However, with no output schema, the exact structure of the 'quick layout snapshot' is left vague, which could leave an agent uncertain about how to parse the result.
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?
The tool has zero parameters, so per the rubric the baseline is 4. The description does not need to explain parameter meanings, and it does not introduce any confusion about inputs.
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 ('Returns') and its specific resource: the default session and a layout snapshot. This distinguishes it from sibling tools like tmux_get_default (which likely only gets the session) by adding the layout snapshot component.
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. It does not mention related tools like tmux_get_default or tmux_capture_layout, nor does it describe the intended use case.
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 the core effect (logs commands and outputs) and that it toggles, implying reversibility. However, it does not mention side effects such as persistence, performance impact, or required permissions, leaving some gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and purpose. Every word earns its place without repetition or fluff.
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 toggle with three parameters and no output schema, the description and schema together provide adequate context. It explains the action, scope, and what logging means. Minor improvement could be made by noting that the setting is per host/session, but the description already mentions this, making it largely 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?
Schema description coverage is 100%, as all three parameters have clear descriptions. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
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 enables or disables verbose audit logging for a host/session, and explains what that entails ('logs commands and outputs'). This specific verb+resource+scope distinguishes it from the many sibling tmux tools.
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 one needs to toggle audit logging, but it does not explicitly state when to prefer this tool over alternatives, nor does it mention any exclusions. Given similar setters like tmux_set_default and tmux_set_sync_panes exist as siblings, more guidance would help.
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. The verb 'Return' implies a read-only operation, but it does not explicitly state that the session is not modified, nor does it mention prerequisites like the session needing to exist. The purpose clause adds some context but leaves safety traits implicit.
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, focused sentence that clearly states the action and purpose. It is concise and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two optional parameters and no output schema. The description explains the purpose but does not describe the return format or how the captured layout connects to the restore tool. This leaves some gaps for the agent's decision-making.
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 input schema provides 100% parameter coverage with descriptions for both optional parameters. The tool description adds no further parameter-specific meaning, so the baseline score of 3 applies.
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 uses a specific verb ('Return') and names the resource ('window layouts for a session'), and it adds purpose ('so they can be restored later'), which distinguishes it from sibling tools like tmux_restore_layout or tmux_save_layout_profile.
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 implies a clear use case: capturing layouts before restoring them later. It provides context for when to use the tool, though it does not explicitly list exclusions or name alternative tools.
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 carry the transparency burden. It discloses the core fan-out behavior and optional capture, but it does not mention the tail/pattern modes, per-target delay overrides, or default capture line counts. These are meaningful behavioral traits not obvious from the schema alone, leaving the description somewhat thin.
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 that is immediately informative and free of filler. It front-loads the core action and scope, making it easy to scan alongside sibling tools and understand the tool's purpose at a glance.
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 an 11-parameter tool with no output schema, this description gives only the core action. It omits any mention of the three execution modes (send_capture, tail, pattern) that are central to the tool's range of behavior, so an agent could easily underestimate its capabilities despite the detailed schema. The schema covers parameters well, but the description alone is not fully complete for a tool this complex.
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 input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no parameter-level meaning beyond the phrase 'optionally capture results,' which simply echoes the capture flag. It does not clarify mode behavior, delay semantics, or target structure beyond what the schema already provides.
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 uses a specific verb ('Send') and clearly identifies the resource: the same keys sent to multiple targets across hosts, with optional capture. This distinguishes it from single-target tmux_send_keys and capture-only tools, and the phrase 'multiple targets (across hosts)' makes its scope unmistakable.
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 phrase 'Send the same keys to multiple targets (across hosts)' gives clear context for when to use this tool: whenever fan-out to multiple panes/hosts is needed. It does not explicitly name alternatives or exclusions, but the primary use case is unambiguous. The optional capture clause further clarifies when it should be chosen over a send-only tool.
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 provided, the description carries the full burden. It discloses core behaviors: 'ensure the remote tmux session exists (create if missing)' and 'set it as default.' However, it does not explain what 'set as default' entails, whether it attaches to the session (despite the title saying 'attach'), or any 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key inputs ('Given an ssh host alias and session name') and clearly states the two actions. It is concise with no unnecessary words.
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 no output schema and no annotations, so the description must compensate. It explains the core functionality and inputs but omits details such as return value, error behavior, or what happens if the session already exists. For a moderately complex remote operation, it is adequately descriptive but not fully 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?
Schema description coverage is 100%, so the baseline is 3. The description reiterates 'host alias' and 'session name' from the schema but does not add additional meaning beyond what the property descriptions already provide. The optional 'command' parameter is not elaborated upon 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 tool's action: 'ensure the remote tmux session exists (create if missing) and set it as default for subsequent commands.' This is a specific verb+resource (ensure/attach remote tmux session), and it distinguishes from siblings like tmux_new_session and tmux_set_default by combining remote host aliases with session creation and default-setting.
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: it is used when given an 'ssh host alias and session name' to ensure a remote tmux session exists and set it as default. It does not explicitly state when not to use it or mention alternatives, but the remote host alias makes the intended use case unambiguous.
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 provided, the description carries full responsibility for behavioral disclosure. It states that the tool returns a how-to, implying a read-only operation with no side effects, but does not explicitly confirm that it modifies no tmux state or require permissions. This is adequate for a simple help tool but not richly detailed.
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, front-loaded sentence that directly communicates the tool's function without any wasted words. It is appropriately concise for the simplicity of the tool.
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 tool with no parameters and no output schema, this description is complete. It tells the agent what the tool returns (a how-to) and its purpose (safe usage of tmux tools). The 'safely' qualifier adds useful context, and no additional details are necessary for such a straightforward meta-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?
The tool has zero parameters with an empty schema, so the baseline for parameter semantics is 4. The description adds no parameter information, but none is needed given the tool has no inputs.
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 returns a concise how-to for using tmux MCP tools safely, with a specific verb and resource. It distinguishes itself from sibling tmux commands by being a meta-tool for instructions rather than a direct tmux operation.
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 explicit guidance on when to use this tool versus alternatives. It does not mention usage context, prerequisites, or when not to use it. The agent must infer that it is for getting started, but the description itself lacks this direction.
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 present, so the description must convey behavioral traits. It discloses that arguments are passed 'raw' (no preprocessing) and warns that the user is responsible for correctness and safety, implying lack of built-in safety checks. However, it does not detail output behavior or specific side effects, which is a modest gap for a potentially dangerous arbitrary-execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. Front-loaded with the tool's core action, followed by usage guidance and a safety warning. Every word earns its place.
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 simple passthrough nature and full schema coverage, the description is largely complete: it states purpose, when to use it, and the user's responsibility. It could benefit from a brief example or note about return values, but these are not critical for a raw exec command.
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 schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds minimal extra meaning beyond the schema, mainly reinforcing that args are 'raw' (passed as-is). It does not elaborate on the 'confirm' or 'host' parameters, but the schema already documents them sufficiently.
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 executing any tmux subcommand with raw arguments, using the specific verb 'execute' and the resource 'any tmux subcommand'. This distinguishes it from the many focused sibling helpers, making its 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?
The description explicitly states 'Use this when helpers do not cover your use case', providing a clear context for when to choose this tool over specialized helpers. While it doesn't name specific alternatives, the general rule is clear and actionable.
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 carry the burden of disclosure. It states that the tool returns raw stdout/stderr, which is transparent about output format, but it does not mention that running a tmux command could have side effects or require specific privileges. The description frames it as a debug tool, which mitigates concerns, but it omits any note about command failure behavior or whether the command is executed in a read-only manner.
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, concise sentence that delivers the core information without waste: what it runs, what it returns, and the intended use case. It is front-loaded 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?
Given the tool's simplicity (2 params, no output schema), the description covers the essential aspects: purpose, input, and output semantics. It misses explicit error-handling or exit-code details, but for a debug utility that returns raw stdout/stderr, the description is sufficiently complete 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 input schema already has 100% coverage: 'args' is described as arguments to pass to tmux, and 'host' as an optional SSH host alias. The description does not add significant parameter-level detail beyond the schema; it merely ties the parameters to the raw output goal. Per the rubric, baseline 3 is appropriate when the schema covers all 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 runs a tmux command and returns raw stdout/stderr, with a specific purpose of debugging remote formatting/quoting issues. This distinguishes it from sibling tools like tmux_command, which likely present parsed/normalized output, and the specific verb 'Run' plus resource 'tmux command' makes the action 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 gives a clear usage context: use this when debugging remote formatting/quoting issues that might arise from shell quoting or output parsing. It implies that for normal usage one might use tmux_command, but it does not explicitly name alternatives or provide exclusions, so it falls short of a 5.
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. 'List' implies a read-only operation, but the description doesn't disclose output format or any safety guarantees. It adds minimal behavioral context beyond the name.
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 with the action verb front-loaded, using only ten words. Every word earns its place with no waste.
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 straightforward list tool with full parameter schema, the description is adequate for operational use. It doesn't include output details, but the lack of an output schema makes that less critical. The description covers the essential purpose and scope.
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 100% for both parameters, so baseline is 3. The description adds some meaning for 'target' (narrowing to a specific target) but not for 'host'. It doesn't significantly extend the schema descriptions.
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 uses the specific verb 'List' with resource 'panes' and scope 'across windows or inside a specific target', clearly distinguishing it from sibling tools like tmux_list_sessions 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'across windows or inside a specific target' clarifies when the target parameter is useful, but it does not explicitly mention alternatives or exclusions. Nevertheless, it provides clear context for the tool's intended use.
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 burden of behavioral disclosure. It adds context about the target omission behavior (lists all sessions), but it does not explicitly state read-only status, output format, or error behaviors. Since 'list' implies read-only, this is acceptable 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 a single sentence that is front-loaded with the verb and resource, and includes the key scope variation with 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?
This is a simple list operation with two optional parameters, no output schema, and no annotations. The description covers the core behavior and parameter nuance adequately. It could mention the return format or prerequisites (e.g., tmux server running), but the simplicity makes the current description mostly sufficient.
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 100% for both parameters ('host' and 'target'). The description does not add new semantic information beyond the schema; it only echoes the target behavior. With full schema coverage, a baseline of 3 is appropriate.
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 'List windows within a session (or all sessions if no target provided)' clearly states the action (list) and resource (windows), and distinguishes it from sibling tools like tmux_list_sessions and tmux_list_panes by specifying the scope (session or all sessions).
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: use with a target to list windows in that session, or omit target to list all windows across sessions. It does not explicitly name alternatives, but the scope makes the usage obvious relative to sibling 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?
With no annotations, the description discloses key behaviors: default && fail-fast semantics, fallback to ; with failFast=false, automatic paged output capture, and prompt cleaning before writes. This goes beyond a mere 'execute commands' statement, though it omits details like error handling or return format.
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 purpose, and each clause adds operational detail. 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?
The tool has 7 parameters and no output schema; the description gives a strong overview and mentions output capture, but leaves nuances (joinWith=newline, default captureLines) to the schema. It is reasonably complete given schema coverage.
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 provides 100% parameter coverage, so baseline is 3. The description adds context by explaining default join behavior and prompt cleaning, which relates to failFast and cleanPrompt, but does not significantly enhance understanding of host/target/captureLines beyond 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 tool executes multiple shell commands sequentially in one tmux pane and captures output, using specific verbs and scope. It distinguishes from single-command siblings like tmux_send_keys by emphasizing batch execution and output capture.
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 for running sequential commands with output capture, but does not explicitly compare to alternatives like tmux_multi_run or tmux_send_keys, nor state when not to use. No exclusions or alternative guidance is 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 must carry the behavioral disclosure. It states the selection effect but does not mention side effects, return values, or error scenarios. For a simple selection tool this is acceptable, but there is room for additional transparency.
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, concise sentence that is front-loaded and contains no filler. It effectively communicates the tool's function and purpose with zero waste.
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 low complexity of the tool, complete parameter descriptions in the schema, and no output schema, the description is adequately complete. It covers the essential function and context without over-explaining.
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 100%, so the baseline is 3. The description does not add any extra parameter semantics beyond what the schema already provides, but it does not need to since the schema is complete.
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 specifies the action ('select') and the resource ('a pane'), and explains the purpose ('so subsequent commands target it'). It distinguishes this tool from semantically related siblings like tmux_select_window by focusing on pane selection.
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 for when to use the tool: to make subsequent commands target a specific pane. It implies the use case but does not explicitly mention alternatives or exclusions, which keeps it at a 4 rather than a 5.
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 the full burden. It explicitly states 'readonly' and 'without modifying defaults', which are key behavioral disclosures. However, it does not mention potential side effects like network access or the semantics of 'recent capture', leaving some 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 a single sentence that front-loads the tool's purpose and key differentiator. It avoids redundancy and every word contributes to understanding the tool's function.
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 description lists what the tool retrieves, it does not explain the output format or define 'recent capture', which is important since there is no output schema. The parameter schema covers inputs, but the description could provide more context about expected return data or usage scenarios.
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 100% schema description coverage, the parameters are already well-documented. The description adds only a loose link to 'recent capture' (likely the captureLines parameter) but does not provide additional detail about how host, session, or captureLines interact beyond what the schema states.
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 states a specific verb ('retrieve') and resource ('sessions, windows, panes, and recent capture'), and explicitly distinguishes itself as a 'readonly variant of tmux_state'. This clearly sets it apart from the sibling tool tmux_state and other manipulation tools.
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 communicates when to use this tool: when a read-only snapshot is needed and defaults should not be modified. It names the alternative 'tmux_state' but does not provide explicit 'when-not' conditions or mention other alternatives like tmux_list_* or tmux_capture_pane.
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 provided, the description carries the full burden. It indicates a read-only action via 'Return' and implies a running server, but it does not explicitly state side-effect-free behavior or error conditions. This is minimal but acceptable for a simple info 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?
A single, well-structured sentence that directly conveys the tool's purpose and output. No redundant words or filler, making it concise and immediately scannable.
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 tool with no parameters, no output schema, and a simple read-only function, the description fully covers the necessary information: what the tool returns and its intended purpose. There is no missing context that would hinder an agent from using 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?
The tool has zero parameters, so the baseline is 4. The description does not add parameter details (since none exist), but it does clarify the output (version and package identifier), which is more than schema alone provides. No issues here.
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 specifies the tool's function: returning the running server version and package identifier. It distinguishes this from sibling tools by focusing on verification-oriented server metadata, a unique scope among the listed tools.
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 phrase 'for verification' provides an implied usage context, but there is no explicit guidance on when to choose this tool over alternatives such as tmux_health or tmux_state. No exclusions or alternative tools are mentioned, so it falls short of clear usage guidelines.
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/k8ika0s/mcp-tmux/badges/card.svg)](https://glama.ai/mcp/servers/k8ika0s/mcp-tmux)

Score Badge

Copy to your README.md:

[![mcp-tmux MCP server](https://glama.ai/mcp/servers/k8ika0s/mcp-tmux/badges/score.svg)](https://glama.ai/mcp/servers/k8ika0s/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/k8ika0s/mcp-tmux'

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