cmuxlayer

by EtanHey

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but some overlap exists between 'kill' and 'stop_agent' (both stop agents) and 'interact' and 'send_to_agent' (both send messages to agents). The descriptions help clarify differences, but an agent might occasionally misselect between these pairs.
Naming Consistency4/5
Tool names follow a consistent snake_case pattern throughout, with clear verb_noun structures (e.g., 'list_agents', 'spawn_agent', 'send_input'). Minor deviations include 'browser_surface' (noun_noun) and 'get_agent_state' (verb_noun_noun), but overall naming is highly predictable and readable.
Tool Count4/5
With 20 tools, the count is on the higher side but reasonable for managing agents, surfaces, and interactions in a complex environment like cmuxlayer. It feels slightly heavy but not excessive, as each tool appears to serve a specific role in the workflow.
Completeness5/5
The toolset provides comprehensive coverage for agent and surface management, including lifecycle operations (spawn, list, interact, stop, kill), surface control (create, read, rename, close), and utility functions (wait, progress, status). No obvious gaps are present for the stated domain.
Average 3.4/5 across 20 of 20 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 5 community issues answered or closed in the last 6 months
- 506 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.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 provided, the description carries the full burden of behavioral disclosure. While it lists action types, it doesn't explain what 'surface' and 'workspace' refs are, whether actions are synchronous/asynchronous, error handling, or performance characteristics. For a complex 8-parameter tool with multiple action types, this is insufficient 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 extremely concise - a single sentence that efficiently lists all available actions. It's front-loaded with the core purpose and wastes no words. Every element earns its place in this compact format.
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 complex tool with 8 parameters, multiple action types, no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error conditions, or the relationships between parameters for different actions. The agent would struggle to use this tool correctly without significant trial and error.
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 schema already documents all parameters thoroughly. The description adds minimal value by listing action names that correspond to the 'action' enum values, but doesn't provide additional semantic context beyond what's in the schema. Baseline 3 is appropriate when 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 tool's purpose with a specific verb ('Interact') and resource ('browser surface'), and lists the available actions. However, it doesn't explicitly differentiate this tool from sibling tools like 'send_input', 'send_key', or 'read_screen' which might have overlapping browser interaction capabilities.
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. With multiple sibling tools that might handle browser interactions (send_input, send_key, read_screen, wait_for), there's no indication of when this multi-action browser tool is preferred over more specialized tools or vice versa.
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 action ('Close') but doesn't disclose behavioral traits such as whether this requires specific permissions, if the closure is reversible, what happens to unsaved data, or any side effects. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource. It uses minimal words ('Close a surface') with a clarifying parenthetical ('terminal or browser pane'), making it zero waste and easy to parse quickly.
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 performs a mutation (closing a surface) with no annotations and no output schema, the description is incomplete. It lacks information on prerequisites, effects, error conditions, or return values. For a tool that modifies state, more context is needed to guide safe and effective usage.
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 schema already documents both parameters ('surface' and 'workspace') with descriptions. The description does not add any meaning beyond what the schema provides, such as explaining what a 'surface ref' entails or when 'workspace' is required. Baseline 3 is appropriate as the schema handles the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Close') and the resource ('a surface'), specifying it can be a terminal or browser pane. It distinguishes the tool's purpose from siblings like 'list_surfaces' or 'new_split', but doesn't explicitly differentiate from 'kill' which might also terminate something, though 'close' implies a less destructive action on UI elements.
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. For example, it doesn't specify if 'close_surface' should be used instead of 'kill' for surfaces, or under what conditions (e.g., after completing a task). The description only states what it does, not when or why 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?
No annotations are provided, so the description carries full burden. It states it 'List all surfaces' but doesn't disclose behavioral traits such as whether this is a read-only operation, potential rate limits, authentication needs, or how results are returned (e.g., pagination, format). For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core purpose ('List all surfaces') and adds clarifying details in parentheses and a phrase. Every word earns its place, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with three parameters and potential complexity. It doesn't explain return values, error conditions, or behavioral context, leaving the agent under-informed. For a list operation with filtering options, more completeness is needed to guide effective use.
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 schema fully documents the three parameters. The description adds no additional meaning beyond implying filtering by workspace and preview options, which are already covered in the schema. This meets the baseline score of 3, as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'surfaces (terminal/browser panes) across workspaces', making the purpose unambiguous. It distinguishes the scope as 'across workspaces', which is helpful. However, it doesn't explicitly differentiate from sibling tools like 'read_screen' or 'browser_surface', which might handle specific surface interactions, so it misses the top 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. It doesn't mention prerequisites, exclusions, or compare to siblings like 'list_agents' or 'read_screen' for related data. This leaves the agent without context for tool selection, relying solely on the name and purpose.
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 but only states the basic action without disclosing behavioral traits. It doesn't mention permissions needed, side effects (e.g., if it modifies layout or requires active workspace), error conditions, or what happens on success (e.g., returns a pane ref). This leaves significant 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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of an 8-parameter mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral context, usage scenarios, and expected outcomes, which are crucial for an agent to invoke this tool correctly in a multi-tool environment.
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 schema fully documents parameters. The description adds no additional meaning beyond implying 'type' can be 'terminal' or 'browser', which is already in the schema. Baseline 3 is appropriate as 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') and the resource ('new split pane'), specifying it can be either a terminal or browser type. It distinguishes from siblings like 'browser_surface' by focusing on splitting rather than creating standalone surfaces, though it doesn't explicitly contrast with all 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 versus alternatives like 'browser_surface' or 'spawn_agent'. The description lacks context about prerequisites, such as needing an existing pane to split from, or exclusions for when splitting is not applicable.
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 reading screen content but doesn't specify permissions needed, whether this is a read-only operation, potential rate limits, or what format the output returns. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose and doesn't waste space on 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?
For a tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the output looks like (text format, structure), doesn't mention error conditions, and provides minimal behavioral context. Given the complexity of terminal screen reading, more completeness is needed.
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 all parameters are documented in the schema. The description doesn't add any additional semantic context about parameters beyond what's in the schema (e.g., explaining what a 'surface ref' represents or when to use scrollback). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 resource ('current screen content of a terminal surface'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'read_agent_output' or 'browser_surface', which might have overlapping reading functionality in different contexts.
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 'read_agent_output' or 'browser_surface'. The description only states what it does, not when it's appropriate or what prerequisites might be needed for accessing terminal surfaces.
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 for behavioral disclosure. 'Rename a surface tab' implies a mutation operation but doesn't specify permissions needed, whether the change is reversible, error conditions, or what happens to the surface state during renaming. For a mutation tool with zero annotation coverage, this is inadequate.
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 zero wasted words. It's front-loaded with the core action and immediately communicates the tool's purpose without unnecessary elaboration.
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 mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'rename' entails operationally, what happens on success/failure, or how this interacts with other surface operations. The 100% schema coverage helps with parameters, but the behavioral context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Rename') and target resource ('a surface tab'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'browser_surface' or 'close_surface', but the verb 'rename' is specific enough to distinguish it from other surface-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when renaming is appropriate, or what happens if the tab doesn't exist. With multiple surface-related tools available, this lack of contextual guidance is a significant gap.
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 full burden but only states what the tool does functionally. It doesn't disclose whether this is a UI-only change, if it persists across sessions, what permissions are needed, or how it affects user experience. For a mutation tool with zero annotation coverage, 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?
Extremely concise single sentence with zero wasted words. The description is front-loaded with the core functionality and includes essential numeric constraints in parentheses.
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 mutation tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after setting the progress indicator, whether changes are visible immediately, what error conditions might occur, or how this integrates with the broader UI system.
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 schema fully documents all 4 parameters. The description adds minimal value by mentioning the 0.0-1.0 range for the 'value' parameter, but doesn't provide additional context about parameter interactions or semantics beyond what's already in 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 clearly states the action ('Set') and the target resource ('sidebar progress indicator'), with specific numeric range context. It doesn't explicitly distinguish from sibling tools like 'set_status', but the resource specificity makes the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'set_status' or other UI manipulation tools. The description provides only functional information without context about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the tool sets a key-value pair but doesn't explain what happens (e.g., whether it overwrites existing keys, requires specific permissions, or has side effects like UI updates). This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and target, making it easy to parse quickly without unnecessary elaboration.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral aspects like effects, error conditions, or return values, leaving significant gaps in understanding how to use the tool effectively in context with its siblings.
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 schema fully documents all six parameters. The description adds no additional meaning beyond implying 'sidebar status' as the context for the key-value pair, but it doesn't clarify parameter interactions or usage examples. Baseline 3 is appropriate when the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the target ('a sidebar status key-value pair'), making the purpose understandable. It doesn't explicitly distinguish from siblings like 'set_progress', but the specific mention of 'sidebar status' provides some differentiation. No tautology or misleading elements are present.
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 'set_progress' or other sibling tools. It lacks context about prerequisites, such as whether a sidebar or workspace must be active, and offers no explicit when-not-to-use scenarios or comparisons.
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 of behavioral disclosure. It states the tool retrieves state information, implying a read-only operation, but doesn't clarify permissions, rate limits, or what 'full state' entails beyond cli_session_id. For a tool with no annotations, this leaves significant gaps in understanding its behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get the full state of an agent') and adds a specific detail ('including cli_session_id for resume'). There is no wasted text, and it's structured to convey essential information concisely.
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 one parameter with full schema coverage and no output schema, the description is minimally adequate. It specifies what the tool does and a key inclusion (cli_session_id), but lacks details on return values, error handling, or behavioral traits. For a simple read operation, it's functional but could be more informative to compensate for the absence of annotations and 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?
The schema description coverage is 100%, with the parameter 'agent_id' clearly documented in the schema. The description adds no additional meaning beyond what the schema provides, such as format examples or context for the agent_id. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't detract either.
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 verb 'Get' and the resource 'full state of an agent', specifying it includes 'cli_session_id for resume'. This distinguishes it from siblings like 'list_agents' (which lists agents) or 'read_agent_output' (which reads output). However, it doesn't explicitly differentiate from all siblings, such as 'set_status' or 'stop_agent', which are clearly different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing agent), exclusions, or comparisons to siblings like 'list_agents' for basic info or 'read_agent_output' for specific data. Usage is implied only by the action described.
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 full burden but offers minimal behavioral insight. It doesn't mention whether this is a read-only operation, if it requires authentication, potential rate limits, pagination behavior, or what format the returned list takes. 'List all agents' implies a read operation but lacks crucial details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality and filtering options without any wasted words. It's appropriately sized for this straightforward list 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 list operation with no annotations and no output schema, the description is minimally adequate but leaves significant gaps. It doesn't explain what information is returned about each agent, whether results are paginated, or any authentication requirements. The 100% schema coverage helps, but more behavioral context would be beneficial.
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 schema already documents all three parameters with their types and the state enum values. The description adds marginal value by mentioning the three filter types but doesn't provide additional semantic context beyond what's in 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 clearly states the verb ('List') and resource ('all agents'), and specifies optional filtering capabilities. However, it doesn't explicitly differentiate from sibling tools like 'get_agent_state' or 'spawn_agent', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'get_agent_state' for single-agent queries or 'spawn_agent' for creation. The description only states what the tool does, not when it's 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 provided, the description carries the full burden of behavioral disclosure. It mentions the agent state requirement, which is useful context, but doesn't address other important behavioral aspects like whether this is a read-only or destructive operation, what permissions are needed, what happens if the agent isn't in the required state, or what the response/outcome looks like. For a tool that interacts with agents, 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 extremely concise - just two short sentences that communicate the core purpose and a key constraint. Every word earns its place, and the most important information (what the tool does) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a tool that sends input to agents (potentially a mutation operation), the lack of annotations and output schema means the description should do more heavy lifting. While it mentions the agent state requirement, it doesn't explain what happens after sending the text, what kind of response to expect, or any error conditions. For a tool with no structured behavioral hints, this is incomplete.
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%, meaning all parameters are documented in the schema itself. The description doesn't add any additional parameter semantics beyond what's already in the schema (agent_id, text, press_enter). This meets the baseline expectation when 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 ('Send text input') and target ('to an agent'), providing a specific verb and resource. However, it doesn't distinguish this tool from similar sibling tools like 'send_input' or 'interact', which likely have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an important precondition ('Agent must be in ready or idle state'), which gives some context for when to use this tool. However, it doesn't explain when to choose this tool over alternatives like 'send_input' or 'interact', nor does it provide explicit exclusions or comparisons with sibling 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?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the tool can fail with an error if the agent isn't found, and it requires the agent to be 'alive' for direct sending. However, it doesn't cover other important aspects like authentication needs, rate limits, side effects of different actions, or what 'alive' means operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: two sentences that efficiently cover purpose, conditions, and error handling. Every word earns its place with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, multiple action types) and no annotations or output schema, the description is adequate but incomplete. It covers the basic workflow and error case, but lacks details on action-specific behaviors, return values, or interaction patterns with sibling tools like 'send_to_agent'. For a multi-action tool with no structured output documentation, more context would be helpful.
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 schema already documents all 6 parameters thoroughly. The description adds minimal value beyond the schema—it mentions 'text' for 'send' and 'model' for 'model' actions implicitly, but doesn't provide additional semantic context or usage examples. Baseline 3 is appropriate when 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 tool's purpose: 'Send a message to an agent, or perform an agent action (interrupt, model switch, resume, skill, usage).' It specifies the verb ('send' or 'perform') and resource ('agent'), but doesn't explicitly differentiate from sibling tools like 'send_to_agent' or 'stop_agent' beyond mentioning 'spawn_agent' for error cases.
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: 'If the agent is alive, sends directly. If not found, returns an error — use spawn_agent first.' This gives explicit guidance on prerequisites and error conditions, though it doesn't compare alternatives like 'send_to_agent' or explain when to choose specific actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it spawns an agent, returns immediately (non-blocking), and suggests using 'wait_for' for readiness. However, it doesn't cover aspects like error handling, resource consumption, or permissions needed, which are gaps for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, with two sentences that directly state the purpose and a key behavioral note. Every sentence earns its place by providing essential information without waste.
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 no annotations and no output schema, the description is moderately complete: it covers the basic action and a critical behavioral trait (non-blocking return). However, for a tool that spawns agents, it lacks details on what the spawned agent does, potential side effects, or error conditions, leaving gaps in 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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond the schema, such as explaining interactions between parameters or usage examples. Baseline 3 is appropriate as 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 ('Spawn an AI agent') and the location ('in a new terminal surface'), which is specific. However, it doesn't explicitly differentiate from sibling tools like 'browser_surface' or 'new_split', which might also create surfaces, leaving some ambiguity about uniqueness.
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 by mentioning 'Returns immediately — use wait_for to block until ready', suggesting when to use 'wait_for' as an alternative for blocking. But it lacks explicit guidance on when to choose this tool over other surface-related siblings like 'browser_surface' or 'new_split', leaving context somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the action ('Stop') and target flexibility, but doesn't mention side effects (e.g., agent termination consequences), permissions needed, or error handling. It adds basic context but lacks rich behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with core action, zero waste. Every word earns its place by specifying target options concisely.
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 no annotations and no output schema, the description is minimal but adequate for a destructive tool with good schema coverage. It covers the what but lacks details on outcomes, errors, or prerequisites, leaving gaps in 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?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., no extra syntax or format details). Baseline 3 is appropriate when schema does 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 clearly states the verb ('Stop') and resource ('one or more agents'), distinguishing it from siblings like 'stop_agent' by specifying it can handle multiple targets including 'all'. It's 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying target types (single ID, array, or 'all'), but doesn't explicitly state when to use this vs. 'stop_agent' or other alternatives. It provides clear context but lacks explicit exclusions or comparisons.
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 of behavioral disclosure. It describes the extraction behavior and return value (content between markers or null if not found), but doesn't mention error conditions, performance characteristics, or what happens if markers are malformed. It provides basic operational context but lacks depth.
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 perfectly concise - a single sentence that states the purpose, mechanism, and return behavior with zero wasted words. It's front-loaded with the core functionality and efficiently communicates essential 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?
For a tool with 4 parameters, 100% schema coverage, but no annotations or output schema, the description provides adequate basic context about what the tool does and its return behavior. However, it lacks information about error handling, performance considerations, or detailed behavioral traits that would be helpful 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%, so the schema already fully documents all parameters. The description mentions delimiter markers and the null return case, but doesn't add significant semantic context beyond what the schema provides about parameters like 'surface', 'tag', 'lines', or 'workspace'.
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 ('extract structured output'), target resource ('from an agent's terminal'), and mechanism ('between delimiter markers'). It distinguishes from siblings like 'read_screen' (general screen reading) and 'get_agent_state' (state monitoring) by focusing on delimited content extraction.
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 this tool (when needing to extract content between specific delimiter markers in an agent's terminal). However, it doesn't explicitly mention when NOT to use it or name specific alternative tools for different extraction 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 provided, the description carries the full burden of behavioral disclosure. It describes the two stopping methods (graceful Ctrl+C and forceful kill), which adds useful context about how the tool behaves. However, it doesn't cover other important aspects like permissions needed, side effects, or what happens after stopping (e.g., cleanup, state changes), leaving 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 extremely concise (one sentence) and front-loaded with the core purpose. Every word earns its place by specifying the action, resource, and key behavioral options without any fluff or redundancy, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is somewhat complete but has gaps. It covers the basic action and parameter semantics, but lacks details on outcomes, error conditions, or integration with sibling tools. For a tool that stops agents, more context about effects would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds value by explaining the semantics of the 'force' parameter ('Force kill instead of graceful Ctrl+C'), which clarifies the tool's behavior beyond the schema's technical details. This compensates well, though it doesn't add information for 'agent_id'.
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 ('Stop an agent') and distinguishes between two modes ('gracefully (Ctrl+C) or forcefully (kill process)'). It uses precise verbs and resource references, making the purpose immediately understandable and distinct from sibling tools like 'kill' or 'get_agent_state'.
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 by mentioning two stopping methods (graceful vs. forceful), but it doesn't explicitly state when to use this tool versus alternatives like 'kill' or provide context about prerequisites. It offers some guidance through the parameter explanation but lacks explicit when/when-not instructions or named 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 provided, the description carries the full burden. It discloses key behavioral traits: it's a blocking operation, it checks retroactively first (implying it might return immediately if the agent is already in the target state), and it waits for state transitions. However, it doesn't mention error handling, what happens on timeout, or the return format (e.g., success/failure indicators).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Block until an agent reaches a target state') and adds a key behavioral detail ('Checks retroactively first'). Every word earns its place with zero waste.
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 no annotations and no output schema, the description is adequate but has gaps. It covers the purpose and a key behavior, but doesn't explain what the tool returns (e.g., success/failure, timeout handling) or error conditions. For a blocking tool with state dependencies, more context on outcomes would be helpful.
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 schema fully documents all parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain the implications of 'checks retroactively first' on parameters). Baseline 3 is appropriate when the schema does 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 clearly states the tool's purpose with specific verbs ('block until', 'checks retroactively') and identifies the resource ('agent') and target ('target state'). It distinguishes from siblings like get_agent_state (which checks current state without waiting) and wait_for_all (which waits for multiple agents).
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 context by mentioning 'agent reaches a target state' and 'checks retroactively first', suggesting it's for monitoring agent state transitions. However, it doesn't explicitly state when to use this versus alternatives like get_agent_state (for immediate checks) or wait_for_all (for multiple agents), nor does it mention prerequisites like needing a spawned agent first.
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 of behavioral disclosure. It mentions the tool's purpose for 'reliably submit commands' which implies it handles key press simulation, but doesn't disclose potential side effects, error conditions, or what happens if the surface doesn't exist. It provides some context about when to use it but lacks details about behavioral constraints or limitations.
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 perfectly concise with two sentences that each earn their place. The first sentence states the core functionality, and the second provides crucial usage guidance. There's zero wasted language, and the most important information (what it does) comes first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 100% schema coverage, and no output schema, the description provides good contextual completeness. It explains the tool's purpose, when to use it, and how it relates to other tools. However, without annotations or output schema, it could benefit from more details about what constitutes success/failure or typical response patterns.
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 schema already documents all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions the general purpose but provides no additional details about parameter usage, constraints, or examples beyond the schema's basic 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 clearly states the specific action ('send a key press') and target ('to a terminal surface'), distinguishing it from sibling tools like send_input (which sends text) or interact (which may handle broader interactions). It provides a concrete verb+resource combination that leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Use this after send_input to reliably submit commands') and provides a specific use case ('especially when targeting interactive programs like Claude sessions'). It clearly differentiates from send_input by explaining the sequential relationship and specialized purpose for command submission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and effectively discloses key behavioral traits: it blocks execution, waits for all agents to reach a target state, implements fail-fast on any error, and returns partial results on failure. However, it does not mention permissions, rate limits, or detailed error handling.
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, dense sentence with zero waste—every word contributes essential information about blocking behavior, conditions (all agents reach state or any errors), and fail-fast with partial results. It is front-loaded and efficiently 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 complexity (coordinating multiple agents) and no annotations or output schema, the description is mostly complete but could enhance clarity on error types or result format. It covers core behavior adequately but leaves some operational details implicit.
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 schema fully documents parameters. The description adds no additional meaning beyond what the schema provides (e.g., no clarification on 'agent_ids' format or 'target_state' implications). Baseline 3 is appropriate as the schema handles parameter documentation.
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 ('Block until') and target ('ALL agents reach target state OR any agent errors'), distinguishing it from sibling 'wait_for' which likely handles different conditions. It precisely defines the verb (block/wait), resource (agents), and scope (all vs. any error).
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 monitoring multiple agents' states with fail-fast behavior, but does not explicitly state when to use this tool versus alternatives like 'get_agent_state' or 'wait_for'. It provides clear context (waiting for state changes) but lacks explicit exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively explains a critical reliability consideration (press_enter unreliability) and provides a recommended workaround. However, it doesn't cover other behavioral aspects like error conditions, performance characteristics, or what happens when sending input to non-existent surfaces.
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 perfectly front-loaded with the core purpose, followed immediately by critical usage guidance. Both sentences earn their place by providing essential information without redundancy. The structure moves from general purpose to specific reliability consideration efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 100% schema coverage, and no output schema, the description provides excellent contextual completeness. It addresses the most critical behavioral consideration (press_enter reliability) that wouldn't be apparent from the schema alone. The only minor gap is lack of information about return values or error conditions.
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 schema already documents all 5 parameters thoroughly. The description adds context about the press_enter parameter's reliability issues and recommended usage pattern, which provides valuable semantic context beyond the schema's technical documentation.
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 ('Send text input') and target resource ('to a terminal surface'), distinguishing it from sibling tools like send_key (which sends individual keys) or send_to_agent (which targets agents). It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives, specifically warning that 'press_enter can be unreliable — for critical inputs, use send_input without press_enter, then call send_key with key 'return' separately.' This directly addresses a reliability concern and offers a clear alternative workflow.
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:

[![cmuxlayer MCP server](https://glama.ai/mcp/servers/EtanHey/cmuxlayer/badges/card.svg)](https://glama.ai/mcp/servers/EtanHey/cmuxlayer)

Score Badge

Copy to your README.md:

[![cmuxlayer MCP server](https://glama.ai/mcp/servers/EtanHey/cmuxlayer/badges/score.svg)](https://glama.ai/mcp/servers/EtanHey/cmuxlayer)

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/EtanHey/cmuxlayer'

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