tmux-mcp-server

by manhnv198669

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action, with no true overlaps. The only near pair is get_pane_info vs read_pane, but one reports metadata and the other reads content, making them easy to distinguish.
Naming Consistency4/5
Nearly all tools follow a consistent verb_noun snake_case pattern (e.g., list_sessions, create_window, send_keys). The single exception is server_info, which uses a noun phrase instead of get_server_info, breaking the pattern slightly.
Tool Count4/5
With 22 tools, the set is on the heavier side, but the tmux domain is broad and the tools are organized into clear clusters (sessions, windows, panes, command execution, server info). The count feels justified rather than bloated.
Completeness4/5
The tool surface covers major tmux interactions comprehensively, but it lacks explicit destroy or rename operations for sessions, windows, and panes. Since run_command can execute arbitrary shell commands (including tmux kill/rename commands), these gaps are workable.
Average 3.5/5 across 22 of 22 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a mutating operation (readOnlyHint=false). The description adds minimal context about relative vs absolute dimensions but does not disclose side effects, failure modes, or how the pane size changes.
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 wasted words. It is front-loaded with the verb. However, it is under-specified, which limits the conciseness score slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with five undocumented parameters and no output schema description, this one-sentence description is highly incomplete. It lacks parameter explanations, usage context, and behavior details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for five parameters. The description only hints at two modes (relative/absolute) without explaining any parameter (width, height, target, direction, adjustment). This is insufficient.
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 resizes a pane and mentions two modes (relative or absolute). It distinguishes from sibling tools like split_pane or zoom_pane by focusing on resizing, though it doesn't explicitly name 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?
No guidance is provided on when to use this tool instead of alternatives or how to choose between relative and absolute resizing. The sentence simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only and not idempotent, so the description correctly aligns with that. It adds useful behavioral details like 'exact exit code' and 'pipe-pane output capture', but it omits potential side effects of executing arbitrary shell commands, blocking behavior indicated by the wait parameter, and interaction with tmux session state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and key features. It is concise and avoids unnecessary filler, though the term 'pipe-pane' may be unclear to an agent without additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that executes shell commands (potentially destructive), the description lacks essential context: when to use it, what setup is required, how it relates to sibling tools like get_command_result, and parameter semantics. The output schema likely covers return values, but the description does not address the tool's operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but it provides no explanations for the four parameters (wait, target, command, timeout). This is a significant gap because the meaning of 'target', the effect of 'wait', and the role of 'timeout' are left entirely to the schema's default values.
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 the specific verb 'Run' with resource 'shell command' and highlights unique features ('exact exit code', 'pipe-pane output capture') that distinguish it from siblings like send_keys and get_command_result. However, it does not explicitly name the tool's relationship to a tmux session or clarify the 'pipe-pane' jargon.
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. Siblings like send_keys and get_command_result suggest a division of labor (sending input vs. retrieving output), but the description does not indicate when run_command is the appropriate choice or when it should be avoided.
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?
Annotations already declare readOnlyHint=false and idempotentHint=false, but the description adds no extra behavioral context such as target selection, side effects on the session, or the meaning of repeat. It only repeats the action with examples, offering minimal transparency beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no redundant words. It front-loads the verb and provides useful examples without excessive 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 relatively simple, but the description leaves the 'target' parameter ambiguous and fails to differentiate from 'send_keys'. Given the output schema may cover returns, the description still lacks crucial operational context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and no parameter explanations in the description, the meaning of 'target' and 'repeat' is entirely unresolved. The examples in the description merely echo the 'key' enum and do not clarify parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send') and the resource ('special key shortcut') with concrete examples. It does not explicitly contrast with sibling 'send_keys', but the term 'special key' and examples differentiate the purpose enough for basic understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like send_keys, nor does it mention prerequisites. It only states what the tool does without any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=false and idempotentHint=false, and the description adds no behavioral context beyond the mutation implied by "split". It does not mention how size is interpreted, whether a new pane is created, or consequences for the existing layout.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler and is front-loaded with the action. However, it is minimal to the point of omitting almost all useful detail, so it does not earn 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?
With no required params and an output schema present, it need not explain return values, but it still leaves major ambiguities: what target refers to, default behavior when omitted, size units, and relationship to the current layout. The description is too thin for a tool with four optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no extra meaning for size, target, direction, or start_directory. The only hint ("horizontally or vertically") merely restates the direction enum.
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 and resource: "Split target pane horizontally or vertically". No sibling tool performs splitting, so it clearly distinguishes itself from the rest.
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 versus alternatives like resize_pane or zoom_pane, nor are there any prerequisites or exclusions. The action is obvious, but the description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and idempotent, covering the safety profile. The description adds the specific information returned (status, command, path, dimensions), which is useful but minimal; it does not mention potential edge cases or behavior regarding the target parameter.
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 directly states the tool's purpose without filler or redundancy. It is appropriately 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?
For a simple read-only tool with an output schema, the description is mostly adequate in stating what it returns. However, it omits any explanation of the target parameter and gives no comparison to sibling pane tools, leaving some ambiguity in how to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'target' with a default and no description. The tool description does not explain what 'target' refers to or how to use it. With 0% schema description coverage, the description should compensate but does not.
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 ('Get') and resource (pane info), and names concrete fields it returns (status, command, path, dimensions). It is clear, but it does not explicitly differentiate from sibling tools like read_pane or list_panes, so it does not merit the maximum 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?
The description provides no guidance on when to use this tool versus alternatives such as list_panes or read_pane. It only states what it does, offering no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and idempotentHint=false, covering the safety profile. The description adds the valuable detail that the session is created 'detached', but it does not disclose behaviors like name conflict handling or side effects beyond creation. The description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It is appropriately sized for the simple operation it describes, earning its place without wasted words.
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 having annotations and an output schema, the description is too sparse for a mutation tool with 4 parameters and no parameter descriptions. It omits any contextual details about how the session is created, what 'detached' implies, or what the response contains, making it incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the parameters (name, width, height, start_directory) or their meanings. The agent cannot infer parameter semantics from the description, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new detached tmux session' uses a specific verb ('Create') and resource ('tmux session'), clearly distinguishing it from sibling tools like create_window. It also specifies an important attribute ('detached') that sets expectations for what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 list_sessions or get_session, nor any prerequisites (e.g., server availability) or exclusions. The purpose is clear, but the description does not help the agent decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the annotations. It states that the window becomes active, which implies a state change, but it does not disclose potential side effects, required context (e.g., session), or return behavior. With readOnlyHint=false and idempotentHint=false, the description should elaborate but does not.
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 zero waste. It directly communicates the core action and result, earning the highest score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no schema descriptions, the description is too minimal to be actionable. It fails to specify how to fill the 'target' parameter or what the tool returns, despite an output schema existing. The description does not adequately cover the tool's usage complexity.
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 schema has 0% description coverage, so the description must compensate for the 'target' parameter. It only repeats 'target window' without explaining the expected format (e.g., window index, name, or session:window syntax), leaving the agent guessing.
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: selecting a target window to make it active. It uses a specific verb ('select') and resource ('target window'), and the outcome ('become active') distinguishes it from related tools like select_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?
No guidance is provided on when to use this tool versus alternatives such as select_pane or send_keys. The description implies usage based on its purpose, but there is no explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description's 'Read' is consistent, so no contradiction. However, the description adds no additional behavioral context beyond what annotations provide, such as output formatting, pane selection behavior, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the key verb and resource, and contains no unnecessary words. It is efficient and well-structured.
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 6 parameters, no description coverage, and no usage guidance, the tool is under-described for its complexity. The output schema exists, but the description still needs to cover parameter behavior and selection logic, which it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 6 parameters. It vaguely hints at scrollback vs visible text, but fails to clarify start/end/lines/target/include_colors or their defaults, leaving the agent to infer without sufficient info.
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 ('Read') and the resource ('pane') with specific scope ('visible text and scrollback history'), distinguishing it from sibling tools like get_pane_info (metadata) and search_pane (searching). It is a specific and unambiguous statement.
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 search_pane or list_panes. The description does not mention prerequisites, exclusions, or situations where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. It adds the concept of 'tracked command execution' and the two modes ('poll status' vs 'fetch result'), which is useful context. However, it does not disclose details like whether incomplete commands return partial output or what errors occur for unknown command_ids. With annotations covering the safety profile, this is minimally adequate.
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 tool's action ('Poll status or fetch result') and object ('a tracked command execution'). Every word earns its place and there is no redundancy or filler.
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 parameter, annotations, and an output schema (presumably describing return values), the description covers the core purpose well. It lacks usage guidelines and explicit parameter semantics, but these gaps are minor given the low complexity. The presence of an output schema reduces the need to describe return values. Overall, the description is reasonably complete but not fully satisfying.
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 a single parameter (command_id) with no description, and schema description coverage is 0%. The tool description mentions 'tracked command execution' but does not explicitly explain that command_id is the identifier returned from run_command. The parameter name is self-explanatory, but the description does not compensate for the missing schema details, so it only partially clarifies the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Poll status', 'fetch result') and identifies the resource ('a tracked command execution'). It is clear that this tool is for retrieving command execution results, distinguishing it from run_command (start) and wait_command (blocking wait). However, it does not explicitly name sibling alternatives, so it falls slightly short of 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 offers no explicit guidance on when to use this tool versus alternatives such as wait_command or list_commands. It implies polling/fetching is appropriate after a command has been run, but does not state this or mention cases where a different tool should be chosen. The absence of any contextual usage direction makes this a weak point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the key behavioral context that the operation is a toggle, which aligns with annotations readOnlyHint=false and idempotentHint=false. However, it does not disclose any additional side effects (e.g., what happens if the pane is already zoomed, or if the target is invalid), relying on the agent's tmux knowledge.
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 purpose with no unnecessary words. It is appropriately sized for a simple toggle operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema, the description covers the core behavior but omits details about expected inputs and error conditions. Given the tool's simplicity, this is acceptable but not thorough; a note about target syntax or default behavior would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate, but it only mentions 'target pane' without specifying the expected format (e.g., pane ID, index, or session:window.pane syntax). The schema only provides a default value with no additional explanation, so the description adds minimal value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Toggle zoom state (maximize/restore) for target pane' clearly states the action (toggle), the resource (pane), and the specific behavior (maximize/restore). It distinguishes this from sibling tools like resize_pane (which changes size) and select_pane (which changes focus).
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. It does not mention any exclusions, prerequisites, or alternative tools to consider, leaving the agent to infer usage purely from the verb and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and idempotentHint=false, indicating a mutating, non-idempotent operation. The description adds the target session scoping constraint, which is useful context. However, it doesn't disclose side effects such as the new window being selected by default (select parameter defaults to true), so it doesn't fully go beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is concise and well-structured, containing only the essential information (action, object, scope).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 optional parameters and an output schema, the description is too sparse. It doesn't inform the agent about implications of 'select' (defaulting to true, meaning the new window becomes active) or 'start_directory'. This is a significant gap for a tool that can affect session state, making the description incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only clarifies the 'target' parameter via 'in target session'. It does not explain 'name', 'select', or 'start_directory' meanings, leaving most parameters semantically under-specified.
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 ('create') and resource ('new window') with a target scope ('in target session'), clearly distinguishing it from sibling tools like list_windows or create_session. It explains what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a window in an existing session, but it does not explicitly mention when not to use it or provide alternatives. Sibling tool names like create_session and split_pane exist, but no exclusion or comparison is given, leaving guidance at an implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutating, non-idempotent operation, and the description adds context that input is literal text and targets a pane. However, it does not disclose side effects such as key interpretation, cursor behavior, or the impact of the 'enter' parameter, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant information. It is front-loaded and concise, making every word contribute to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema present, the description omits critical operational details: whether 'target' is required, how pane targets are specified, and the function of the 'enter' flag. The tool has three parameters with no schema descriptions and no default behavior explained, leaving the agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 0% of the parameters, so the description must compensate. It only hints at 'keys' (the literal string) and 'target' (the pane), but does not explain the 'enter' boolean or the expected format for 'target'. Significant parameter semantics remain undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends literal string text to a target pane, using a specific verb and resource. It distinguishes itself from the sibling 'send_special_key' by emphasizing 'literal string text', which conveys the scope and purpose effectively.
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?
Usage guidance is implied through the qualifier 'literal', suggesting contrast with special-key sending, but the description does not explicitly state when to use this tool versus alternatives like 'send_special_key' or 'run_command'. There is no direct mention of 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds only the 'active' filter and 'details' output, but does not disclose behavior such as whether all sessions are returned, ordering, or the meaning of 'active'. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 action and resource. Every word is necessary, and no filler exists. It is as concise as appropriate for a simple list tool.
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 output schema covers return value structure, and annotations cover the read-only nature. However, the description fails to explain the 'target' parameter or clarify what 'active' means, leaving uncertainty about filtering behavior. For a simple tool this is borderline complete, but the parameter omission detracts.
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 single optional parameter 'target' has zero schema description coverage, and the description provides no explanation of its purpose. The agent cannot infer how to use 'target' from the description or schema, forcing reliance on prior knowledge. This is a significant gap for a parameterized tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource 'tmux sessions' with scope 'active' and output detail 'with details', clearly distinguishing it from sibling tools like get_session (single session) and list_windows (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like get_session or list_windows. It implies usage for listing sessions but lacks any exclusions or alternative references. Given the simplicity of the tool, this is adequate but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly and idempotency. The description adds that the search uses regex and targets scrollback history, which complements the annotations. However, it does not disclose behavior like match limits or target requirements, 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 with no 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?
Given the tool's simplicity and existing annotations/output schema, the description covers the core purpose but lacks parameter semantics and usage context. It is minimally adequate but has clear gaps for a 3-param tool with 0% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description must compensate. It clarifies 'pattern' as a regex but leaves 'target' and 'max_results' unexplained. This is partial compensation, warranting a 2.
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 specific verb 'Search' with resource 'pane scrollback history' and method 'regex pattern', clearly distinguishing it from sibling tools like read_pane or 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when/when-not guidance is provided, but the description implies the use case of searching scrollback. It does not mention alternatives or exclusions, scoring a 3.
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?
Annotations already declare readOnlyHint and idempotentHint, but the description adds no behavioral context beyond the action itself. It does not describe return format, ordering, or any edge cases, so it provides no additional transparency value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. It contains no waste 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, read-only list operation with no parameters and an expected output schema, the description is sufficient. It could mention whether 'connected' includes the current client, but overall it is complete for the tool's complexity.
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 schema coverage is trivially 100%. The description does not need to add parameter semantics, and the zero-parameter baseline of 4 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 clearly states the action ('List') and the resource ('connected tmux clients'), distinguishing it from sibling tools like list_sessions and list_windows. The verb+resource pattern is specific 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance, alternatives, or exclusions are provided. The intended use is implied by the action and resource, but the description does not clarify when to prefer this tool over list_sessions or server_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and repeatability. The description adds the key behavioral trait of blocking until completion, which goes beyond the annotations. It does not disclose what happens on timeout or if the command is already finished, but the core behavior is clearly stated.
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. Every word contributes to the meaning, making it highly efficient.
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?
This is a simple tool with good annotations and an output schema, so the description does not need to explain return values. However, it lacks important context about timeout semantics (e.g., what happens when timeout expires) and how the command_id parameter relates to commands started via run_command. These gaps make it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It does not mention either 'command_id' or 'timeout' at all. While the parameter names are somewhat self-explanatory, the description provides no information about how they are used, units for timeout, or whether they are required.
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 ('wait') and clearly identifies the resource ('a running command execution'). It distinguishes itself from siblings like run_command (starts execution) and get_command_result (fetches results) by focusing on the blocking wait behavior.
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: use when a command is already running and you need to wait for it to complete. However, it does not explicitly state when to use this tool over alternatives like polling get_command_result, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, covering the safety profile. The description adds the behavioral context that it lists 'tracked' executions and is scoped to the 'current session', which is useful beyond the annotations. No contradictions detected.
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 of 8 words, immediately stating the core action and scope. No redundant or irrelevant information is included.
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 optional parameter, and annotations plus an output schema exist. The description adequately conveys the basic purpose, but the lack of parameter detail leaves a gap in completeness. For a list tool, this is acceptable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the parameter 'target' has no description in the schema. The description mentions 'current session' but does not explicitly explain that the 'target' parameter refers to the session or how to use it. This provides only a weak hint about the parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List tracked command executions in current session' clearly identifies the verb (List), the resource (tracked command executions), and the scope (current session). It distinguishes from siblings like list_sessions and list_windows by focusing on command executions.
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 'in current session' gives context about when this tool is appropriate, implying it is for the current session scope. However, it does not explicitly discuss alternatives or when not to use it, leaving some room for ambiguity relative to tools like get_command_result or wait_command.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds scope information but doesn't reveal additional behavioral details (e.g., default behavior when target is empty), which is acceptable given the output schema.
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 sentence that directly states action and scope 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?
For a simple 2-param read-only tool with an output schema, the description provides sufficient context for invocation, though it lacks explicit parameter mapping and edge case 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 0%, and the description only tangentially maps parameters: 'target' is implied by 'target window/session', and 'all_panes' is implied by 'all sessions'. It does not explicitly explain how each parameter behaves, but the two-parameter tool's purpose is reasonably conveyed.
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 ('List') and resource ('tmux panes') with scope ('target window/session or all sessions'), clearly distinguishing it from sibling tools like list_windows or get_pane_info.
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 clear context on when to use the tool (listing panes, optionally scoped to a target or all sessions), but does not explicitly name alternatives or exclusions relative to other tmux 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?
Annotations already declare the tool is not read-only and not idempotent, which covers its mutating nature. The description adds that it changes the active pane, but it does not disclose potential side effects, error behavior, or what happens if both target and direction are provided. This is acceptable given the annotation coverage 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 with no redundancy. Every word contributes to understanding the tool's purpose and parameter semantics.
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 an output schema and annotations that cover return values and mutability. The description gives the essential action and parameter semantics. It is complete enough for a simple selection tool, though it leaves ambiguity about combined or invalid inputs.
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?
With 0% schema description coverage, the description compensates by mapping target to an ID and direction to L/R/U/D. This adds meaning beyond the bare schema names. However, it does not explain the ID format, whether parameters are mutually exclusive, or the default behavior when neither is provided.
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 ('Select'), the target resource ('active pane'), and the two methods ('by ID or direction'). It explicitly lists the direction values (L, R, U, D), making it easy to distinguish from sibling tools like list_panes or select_window.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to change the active pane, but it does not provide explicit when-to-use guidance or mention alternatives. The 'by ID or direction' phrase suggests two modes but does not clarify when to prefer one over the other or when to use a different 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?
Annotations already declare readOnlyHint and idempotentHint, so the description need not repeat safety. It adds that the target can be ID or name, but does not disclose error behavior or edge cases, which is acceptable given the simple read-only nature.
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: 'Get detailed info for a specific session by ID or name.' Every word earns its place, with no redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema present, the description adequately covers the core purpose and target semantics. Return format is handled by the output schema, and the tool's low complexity means little else is needed.
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 schema has a single 'target' parameter with no description (0% coverage). The description adds crucial meaning by specifying the target can be either a session ID or name, which is not derivable from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('detailed info for a specific session'), and it distinguishes this tool from siblings like list_sessions and create_session by focusing on a single session queried by ID or name.
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 retrieving details of one session but does not explicitly contrast it with list_sessions or provide when-not-to-use guidance. It lacks explicit alternative recommendations, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint, so the agent knows this is a safe read operation. The description adds behavioral context by specifying the two modes (session-specific or all sessions), which goes beyond the annotations and clarifies the tool's scope.
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, direct sentence that front-loads the action ('List') and the resource. Every word is purposeful, with no redundancy or filler, 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.
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 (two optional parameters, output schema present, and read-only annotations), the description covers its core purpose and operational modes. However, it omits details about default behavior and target format, which are minor but notable gaps for an agent that needs to invoke it correctly without external knowledge.
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 has no descriptions for its two parameters (target and all_sessions), and the description partially compensates by explaining the 'for a session or across all sessions' behavior. However, it does not clarify the format of target (e.g., session name) or what happens when both parameters are at their defaults, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists tmux windows, with a specific scope (for a session or across all sessions). This distinguishes it from sibling tools like list_sessions and list_panes by explicitly naming the resource (windows) and the two operating modes.
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 clear context that this tool can be used for a specific session or across all sessions, which implies when to use it. However, it does not explicitly mention alternatives or exclusion criteria, so it falls short of a 5 but is still useful and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds value beyond annotations by specifying exactly what data is retrieved (version, socket info, counts), which is helpful for the agent. It does not add extra behavioral details, but none are particularly needed for a simple read-only 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?
The description is a single, front-loaded sentence with no filler words. It efficiently conveys the essential purposes without redundancy, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, read-only, output schema present), the description is fully adequate. It tells the agent what the tool does, and the output schema will handle return value details. There are no gaps in context for an agent to successfully invoke this 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, so the schema is fully described and no parameter documentation is needed. The baseline for 0 parameters is 4, and the description correctly omits any parameter details because none exist.
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 'get' and clearly identifies the resource ('tmux server version, socket info, and counts'). It distinguishes this tool from siblings like list_sessions and get_pane_info by focusing on server-level metadata rather than session or pane data.
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 usage guidance or alternative tools are mentioned. However, the description's clarity provides an implied usage: when an agent needs server-wide information like version or socket details. It does not state when not to use it, but the context of a no-parameter, read-only info tool makes its purpose fairly obvious.
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:

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

Score Badge

Copy to your README.md:

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

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/manhnv198669/tmux-mcp-server'

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