Onda MCP

Server Quality Checklist

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

Latest release: v0.3.2
Disambiguation4/5
Most tools target distinct resources (panes, terminals, workspaces, windows, tabs) and actions, with clear descriptions. Some overlap exists between terminal_run, terminal_send, terminal_send_keys, and terminal_spawn, but their purposes are differentiated enough (newline, raw text, key sequences, exec). Overall, an agent can reliably select the right tool with careful reading.
Naming Consistency3/5
The dominant pattern is domain_verb (e.g., onda_terminal_run, onda_workspace_focus, onda_pane_split), which is consistent. However, a few tools break the pattern: onda_context, onda_status, onda_app_info, onda_ping are nouns without a domain prefix, and onda_launch_session is a verb_noun with no domain. This mixed convention makes the set slightly harder to predict.
Tool Count2/5
At 39 tools, this is well above the 25+ threshold for 'too many' per the calibration guide. While the domain is broad (panes, terminals, workspaces, windows, tabs, session), the count feels heavy and could overwhelm an agent. Several tools could potentially be merged (e.g., workspace_locate and workspace_list, window_focus and window_mount_workspace are distinct but related).
Completeness4/5
The tool set covers the full lifecycle of terminals, panes, workspaces, tabs, and windows: list, create, close, focus, read, subscribe, poll, kill, mount/unmount, and layout inspection. It even includes a high-level launch_session macro for complex workflows. Minor gaps exist (e.g., no explicit pane resize or terminal resize tool), but agents can work around them via window layout and tile tools.
Average 4.1/5 across 39 of 39 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- 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?
No annotations are present, so the description carries the full burden. It states the high-level effect but does not disclose any behavioral details such as side effects, whether it rearranges existing panes, or any prerequisites. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short sentences and no redundant wording. It is well-structured, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with a small schema, the description covers the basic purpose but lacks context about what happens when 'workspaceId' is omitted and does not address the potential overlap with the sibling 'onda_workspace_layout'. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with clear descriptions for both parameters, including the enum values for 'layout'. The description does not add any parameter-level meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set the workspace-level tiling layout') and the resource, but does not differentiate from the sibling tool 'onda_workspace_layout', which may be a similar or alternative operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'onda_workspace_layout'. The description implies a use case (setting tiling layout) but offers no explicit context, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states 'Switch to a workspace by ID' but does not disclose any side effects, such as changing the active workspace context for subsequent tool operations, or what happens if the ID is invalid. This is a significant gap for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded with the action and resource, making it highly scannable.
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?
While the tool is simple with only one parameter, the description lacks essential behavioral context. It does not explain the impact of switching focus, prerequisites (e.g., an existing workspace), or any interaction with the broader terminal/session context. For a state-changing tool, 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?
The input schema already provides 100% coverage for the single 'id' parameter with a description ('Workspace ID to switch to.'). The tool description's 'by ID' adds no new meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Switch to') and the resource ('a workspace') with a specific method ('by ID'). It distinguishes the tool from sibling workspace tools like list, create, or layout, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 that this should be used to change the active workspace or how it differs from workspace_focus-like operations in other domains. No exclusions or alternative tools are referenced.
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 indicates a destructive action via "kill" but provides no additional context about irreversibility, side effects on panes/windows, or whether the process is terminated gracefully. This is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words. It front-loads the action and target, making it easy to scan.
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 extremely simple (one parameter, no annotations, no output schema). The description provides the core action but omits any mention of return values, errors, or side effects. It is minimally viable but leaves behavioral questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the only parameter 'id' documented as 'Terminal ID to kill.' The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ("kill") and resource ("terminal process"), clearly distinguishing it from sibling tools like close, unsubscribe, or run. It is unambiguous and immediately conveys the function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. There is no mention of when killing is appropriate, prerequisites, or distinctions from similar operations like pane_close or terminal_unsubscribe.
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 for behavioral disclosure. It indicates the tool creates a workspace, but it does not disclose side effects, permissions required, behavior if the workspace already exists, or whether rootPath must exist beforehand. This is a significant gap for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that efficiently state the action and purpose. There is no wasteful or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse given the lack of annotations and output schema. It does not explain what the tool returns after creation, any prerequisites like directory existence, or error scenarios. While the schema covers parameters, the overall behavioral context is incomplete for an agent to invoke the tool safely and correctly.
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 each parameter already has a description. The tool description adds minimal value beyond that, only contextualizing workspaces as groupings of tabs by project. It does not elaborate on parameter syntax or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Create a new workspace.' It also adds context ('Workspaces group tabs by project') that distinguishes this from sibling tools like workspace_list or workspace_focus, which perform different operations.
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 context by explaining the purpose of workspaces, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. Sibling tools like workspace_list or workspace_focus are not referenced.
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 disclosing behavior. It clearly states this is a status-read operation, but it does not explicitly say it is non-destructive or describe any side effects (or lack thereof). It also omits details about return structure or edge cases (e.g., when no session is active).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and immediately followed by a practical usage hint. Every sentence earns its place with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description covers the main purpose and enumerates the key data areas (workspace, tab, pane). However, it leaves 'their details' vague and does not mention potential failure modes or what happens if no session is active, which would make it more complete for an agent.
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, and the schema is empty. The description correctly implies that no parameters are needed by focusing on the current state. A baseline score of 4 is appropriate because the description fully aligns with the parameterless nature of the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the resource ('current Onda session state') as well as the specific components returned (active workspace, tab, pane, and their details). It is clear and likely differentiates from most sibling tools, though it does not explicitly distinguish itself from the similarly named 'onda_context'.
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 a direct usage hint: 'Use this to understand the current context before taking actions.' This gives clear context for when to call the tool, though it does not mention when not to use it or explicitly point to alternative 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, the description carries the full burden of behavioral disclosure. It states the core action (focus/activate) but does not provide additional context such as prerequisites, side effects on other panes, or error behavior for invalid IDs.
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, 'Focus (activate) a specific pane by its ID.' It is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is adequate but not complete. It does not mention how to obtain the pane ID or any state changes beyond focusing. A short note referring to onda_pane_list would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the 'id' parameter with the description 'Pane ID to focus.' The description's 'by its ID' adds no new meaning, so the baseline of 3 is appropriate since schema coverage is 100%.
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 focuses (activates) a specific pane by its ID. It uses a specific verb and resource, distinguishing it from other focus tools like onda_workspace_focus and onda_tab_focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to focus a pane), but it does not explicitly mention alternatives or exclusions. No guidance is provided on the relationship with sibling tools such as onda_pane_list or onda_pane_split.
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 implies a read-only, non-destructive operation, but does not disclose what the tool returns (e.g., success/failure, latency) or any side effects. The lack of explicit safety or output behavior is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of nine words, front-loaded with 'Health check' and devoid of filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no annotations, no output schema), so the description covers the basic purpose but misses return value expectations and selection criteria. It is minimally viable but leaves gaps that an agent must infer.
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 input schema has zero parameters, and the description correctly implies no arguments are needed. Baseline for 0 parameters is 4, and the description adds no unnecessary parameter details.
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 function as a 'Health check' and specifies the resource 'Onda', making it distinct from sibling tools that perform operational actions. The verb 'verify' and noun 'running and responsive' precisely convey the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Health check' implies using this tool to confirm Onda's status, but no explicit when-to-use guidance or alternatives are mentioned. With many sibling tools like `onda_status` and `onda_context`, the description leaves selection to inference rather than providing direct differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action ('switch to/focus') but does not disclose side effects, such as whether the tab must already exist, what happens if the ID is invalid, whether focusing is asynchronous, or if it is idempotent. For a state-changing tool, this is a significant gap.
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 states the action and resource. Every word is useful, with no wasted verbosity or structural issues.
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 one-parameter tool with no output schema, the description covers the core purpose. However, it lacks context about expected behavior on failure (e.g., invalid ID), return value, or any side effects. While the tool is simple, the absence of annotations means the description should have provided at least minimal behavioral context, leaving a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the 'id' parameter is described as 'Tab ID to focus.' The description adds 'by ID' which is redundant. As baseline for high coverage is 3, and the description provides no additional semantic value beyond the schema, this score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Switch to (focus) a specific tab by ID.' clearly states the action (switch/focus) and the resource (a tab), with the method (by ID). This succinctly distinguishes it from sibling focus tools for panes, windows, and workspaces, providing strong purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys when to use the tool: when a user wants to focus a specific tab by its ID. It clearly separates this from tab list/new/close operations. However, it does not explicitly mention alternatives or exclusions (e.g., 'use onda_pane_focus for panes'), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosing side effects. It only mentions that tabs have layouts of panes, but does not explain whether the new tab becomes focused, whether it is attached to a specific workspace, or what happens if cwd or shell are omitted. This is a significant gap 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 two sentences long, front-loaded with the core action, and adds relevant context about tabs and use cases. Every sentence earns its place without unnecessary verbosity.
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 relatively simple with two optional parameters and no output schema. The description conveys the purpose and usage, but lacks details about default behavior (e.g., default shell/working directory, initial pane layout) and what the return value indicates. Given the absence of an output schema, some return information 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?
The input schema covers 100% of parameters with descriptions ('Working directory for the new tab' and 'Shell to use'). The tool description adds no additional parameter information beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Create a new tab in Onda.' It also distinguishes tabs from related concepts by noting each tab has its own layout of panes, which helps differentiate it from pane-level or workspace-level operations.
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 a clear use case: 'Use this to isolate different workstreams.' This gives context for when to invoke the tool, though it does not explicitly mention exclusions or alternatives such as workspace creation, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the key behavioral trait of falling back to the active pane when no ID is given. However, it does not mention side effects (e.g., terminating associated terminal sessions) or error handling for invalid IDs, which would improve 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 two short sentences with no filler. The primary action is stated first, and the optional behavior is clearly and concisely explained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter mutation tool with no output schema, the description covers the core action and the optional parameter behavior. It lacks details about return values, failure modes, or side effects, but these are less critical given the low complexity. It is reasonably complete for its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the 'id' parameter with 100% coverage, including the note to omit it to close the active pane. The description essentially repeats this schema information without adding new meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('close') and a specific resource ('pane by ID'), and clearly explains the fallback to closing the active pane. This distinguishes it from sibling tools like pane_split or pane_focus, which have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context for when to use the tool (closing a specific pane or the active pane) but does not explicitly discuss alternatives or exclusions. Since sibling tools like tab_close and terminal_kill exist, some guidance on choosing this over those would strengthen it, but the behavior is understandable.
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 the 'sends command + newline' behavior, which is useful, but it does not explain whether the command runs asynchronously, whether output is returned directly, or how errors are surfaced. This is a significant gap for a command execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, starts with the core purpose, and includes a brief elaboration of use cases. Every sentence adds value, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema) and the description covers the basics. However, it does not mention what the tool returns after running a command or direct users to complementary tools like onda_terminal_read for output retrieval. Given the lack of annotations and output schema, this additional context would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for both 'id' and 'command' (100% coverage). The description adds only the 'sends command + newline' detail, which applies to the command parameter but does not add substantial meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run a command'), the resource ('in a specific terminal'), and a key behavioral detail ('sends command + newline'). It also provides concrete use cases (execute shell commands, launch processes, start other AI agents), which helps distinguish it from sibling tools like onda_terminal_send_keys.
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 'Use this to execute shell commands, launch processes, or start other AI agents in separate terminals' gives clear contextual guidance. However, it does not explicitly mention when not to use this tool or compare it to alternatives like onda_terminal_send or onda_terminal_spawn, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Get' implies a read-only operation with no side effects, but it does not explicitly state safety guarantees, authentication requirements, or the exact return format. For a simple info tool, this is adequate but minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, highly efficient sentence that front-loads the action and resource, then specifies the exact fields returned. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema info tool, the description is complete enough: it names the tool's purpose and the two pieces of information returned. Slight room to mention that the return is a structured object, but this is not a significant gap.
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 accepts no parameters, so schema coverage is trivially 100%. The description adds no parameter-specific info, but none is needed. Baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get Onda app info' with a specific verb and resource, and explicitly lists the returned fields (version, process ID). This distinguishes it from sibling tools focused on panes, terminals, workspaces, and windows.
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 app-level information, but does not explicitly state when to use this tool versus alternatives like onda_status, onda_context, or onda_ping. No exclusions or contextual guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the important default behavior of closing the active tab when no ID is given. However, it does not mention the destructive/irreversible nature beyond the word 'Close', nor what happens if the ID is invalid or if the tab has unsaved content.
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 immediately states the action and the key conditional behavior. Every word earns its place, with 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 optional parameter and no output schema, this description is sufficient for an agent to invoke it correctly in the common cases. It could be more complete by noting the destructive nature or error behavior, but the core usage context is fully covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single optional parameter fully with the description 'Tab ID to close. Omit to close active tab.' The tool description essentially mirrors this, adding no new semantic detail beyond what the schema provides. Baseline 3 is appropriate given 100% schema coverage.
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 ('Close'), names the resource ('a tab'), and specifies identifier-based targeting with a fallback to the active tab. This clearly distinguishes it from sibling tab operations like onda_tab_new, onda_tab_list, and onda_tab_focus.
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 for use: provide an ID to close a specific tab, or omit the ID to close the active tab. However, it does not explicitly mention when NOT to use it or suggest alternatives (e.g., use onda_pane_close for panes), so it stops short of full guidance.
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 burden of behavioral disclosure. It reveals that the tool is a read-only listing operation and specifies the output fields, which is useful. However, it does not explicitly state that the operation is non-destructive or note any scope limitations (e.g., across all workspaces or current workspace), leaving minor ambiguity.
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 states the action and the expected output. There is no redundant phrasing or unnecessary detail, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description adequately covers what the tool does and what fields will be returned. The only slight gap is that 'all tabs' could be ambiguous regarding scope (e.g., all tabs in the current workspace vs. all globally), but the tool name and context likely resolve this. Overall, the description is sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is trivially 100%. The description does not need to explain parameters, and the baseline of 4 for no-parameter tools applies. It adds no parameter-specific details, but none 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 states the specific action ('List all tabs') and the resource ('tabs'), immediately distinguishing it from sibling tools like onda_pane_list or onda_tab_focus. It also enumerates the returned fields (IDs, titles, active state, workspace), leaving no doubt about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to enumerate all tabs and their attributes), but it does not explicitly mention alternatives or situations to avoid. Since the purpose is clear and there are no side effects, the lack of explicit exclusions is acceptable 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?
With no annotations, the description carries the full burden. It correctly implies a read-only operation ('List') and discloses the return fields (name + sessionId + timestamps), but it does not mention behaviors like empty-result handling, ordering, or whether this is a live snapshot. This is adequate for a simple list tool 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 two sentences, front-loaded with the core action, then essential details about return values and intended use. Every word earns its place with no 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?
This is a straightforward single-parameter introspection tool with no output schema. The description informs the user of the return shape and the use case, which is complete for its complexity. It could mention failure conditions, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single 'id' parameter with 'Terminal ID to inspect.', so the description does not need to add much. The description does not go beyond the schema, but the schema is sufficient, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact action ('List currently attached listeners') and the resource ('for a terminal'), clearly distinguishing this from sibling tools like onda_terminal_list (which lists terminals) and onda_terminal_subscribe/unsubscribe. It also specifies the returned data (name + sessionId + timestamps), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Used to inspect who is observing a terminal (introspection / debugging)', giving clear context for when this tool is appropriate. It does not mention exclusions or alternative tools, but the purpose is specific enough that a user can decide correctly.
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 transparently states the core effect: "Creates a new terminal beside or below the current one," which implies the original pane remains unchanged. It doesn't disclose minor details like focus behavior, but for a simple split operation this is 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?
Three short, front-loaded sentences that state the purpose, effect, and use case without any waste. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 optional parameters and no output schema, the description is complete enough: it explains what it does, when to use it, and how the panes are arranged. Slight gaps around focus behavior and defaults are covered by the schema, so this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra parameter semantics beyond the schema; 'beside or below' loosely maps to the direction enum, but cwd and shell are only covered by the schema itself.
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 function with a specific verb and resource: "Split the active pane in Onda terminal." It differentiates from sibling tools (pane_close, pane_focus, terminal_spawn) by focusing on pane creation via splitting, and mentions the direction options (beside or below) which maps to the direction parameter.
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 a clear use case: "Use this to set up parallel workspaces for multi-agent workflows." This gives context for when to use the tool, but it doesn't mention explicit alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 critical behavior: 'The process replaces the shell in the tab's PTY: argv is passed to execve() as-is, so embedded newlines, quotes, and dollar signs are preserved verbatim.' This goes beyond the schema by explaining the mechanics and guarantees of passing arguments.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the primary purpose. The second sentence adds essential behavioral detail without redundancy. Every sentence serves a distinct role: one for purpose/usage, one for behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of an output schema, the description covers the key aspects: what it does, when to use it, and how arguments are handled. It does not mention post-spawn behavior (e.g., interaction, process exit), but that is generally covered by sibling tools. The description is sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema for individual parameters; it reiterates the verbatim argument behavior that the schema's args description already mentions. No additional parameter-specific context 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: 'Open a new tab and spawn a process directly with exact argv (bypasses shell parsing).' It uses a specific verb (spawn) and resource (process in new tab), and explicitly contrasts with siblings by highlighting the bypass of shell parsing and exact argv handling.
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 an explicit use case: 'Use this when you need to pass multi-line strings or special characters as a single argument — e.g. launching `claude` with a structured preamble.' It gives clear context for when to choose this tool, though it does not name alternative tools or specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool returns active terminals with specific metadata fields and that filtering is optional, which goes beyond the tool name. It lacks details on edge cases like empty results or ordering, but the primary behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, starting with 'List active terminals.' It then delivers the return structure and use case in a few short sentences, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list-with-filters tool, the description covers purpose, return format, and usage context. The lack of an output schema is mitigated by explicit field enumeration, and the optional parameters are already detailed in the 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 already fully describes both parameters ('Filter: only terminals in this window.' and '...workspace.') with 100% coverage. The description's mention of 'optional filters' adds no new semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('List') and resource ('active terminals'), and enumerates the exact fields returned, making its function unambiguous. It differentiates from sibling terminal tools by being the listing operation and references a distinct use case.
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?
States 'Use the optional filters to scope the list' and highlights when it is 'Essential to disambiguate which terminal belongs to which workspace/window when many are alive.' This provides clear context but does not explicitly compare with alternative tools (none exist for listing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It clearly discloses the no-newline behavior and 'raw text' handling, which are the most important behavioral traits for a terminal-send tool. It doesn't cover side effects, but for this tool's scope, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with the core action and key behavior in the first sentence. Every word earns its place; no repetition of schema content.
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 simple tool is well-served by the description given full schema coverage and no output schema. It explains purpose and use cases, though it doesn't explicitly disambiguate from onda_terminal_send_keys, leaving a minor gap.
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?
Input schema covers both parameters with clear descriptions (100% coverage). The tool description adds 'raw text' and use-case context but doesn't add any syntax or format details beyond what the schema already provides. Baseline 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Send raw text to a terminal' – a specific verb+resource combo. The key qualifier 'without appending a newline' clearly differentiates it from siblings like onda_terminal_run, which likely appends a newline.
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 second sentence explicitly states when to use the tool ('interactive input, partial commands, or key sequences'). It does not name alternative tools for other cases, but the context is clear enough for an agent to choose it appropriately.
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 and does well: it reveals the long-lived nature, the sessionId return, the current buffer snapshot, the concurrency cap of 4, and the UI presence indicator. It omits error behavior when the cap is exceeded or explicit termination steps, but these are minor 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?
Three sentences, each earning its place. The first states the core action, the second describes the return values and their purpose, and the third adds critical constraints. No redundant phrases or unnecessary elaboration.
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 no output schema and no annotations, the description covers the main return values (sessionId and buffer snapshot) and the usage flow (attach listener, poll later). It lacks details on error handling or lifecycle after subscription, but for the tool's complexity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already described in the schema. The description adds a small extra detail about the listener name as a presence indicator, but this mostly overlaps with the schema's description. Thus the baseline of 3 is appropriate—no significant additional semantics are 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 opens with a specific verb-resource pair: 'Attach a long-lived listener to a terminal's output stream.' This clearly distinguishes it from sibling tools like onda_terminal_read or onda_terminal_poll, and the mention of returning a sessionId for use with onda_terminal_poll solidifies its unique role.
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 explicitly states this returns a sessionId for use with onda_terminal_poll, implying a subscribe-then-poll workflow. The sibling list further clarifies its role, but it does not explicitly state when to prefer this over one-shot reads or exclude alternatives, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the effect (restore/raise/focus), the parameter behavior (omit for primary), and the return shape. It doesn't mention potential side effects, but focusing a window is inherently non-destructive, so 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each with distinct value: action, parameter behavior, return value, and usage context. No wordiness.
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 1-optional-param tool with no output schema, the description covers purpose, usage context, return value, and parameter behavior. Minor ambiguity about 'main window' and lack of error handling details keep it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with windowId already described as 'Target window id. Omit to focus the primary window.' The description restates this and adds 'main window' context, but adds little beyond the schema, so baseline 3 is correct.
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: 'Bring a specific main window to the foreground' with specific behaviors (restore, raise, focus). It distinguishes from sibling tools that focus panes, tabs, or workspaces by specifying window-level focus.
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 explicit use cases: 'Use after mounting a workspace remotely, or to wake Onda from a background CLI subagent.' It doesn't name alternative tools for exclusion, but the context is clear for window-focus scenarios, earning a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It reveals the return format but does not explicitly state that the operation is read-only, has no side effects, or mention any error conditions. For a list tool, 'List' implies read-only, but it could still be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first is a clear, front-loaded purpose statement, and the second adds a concrete usage scenario and return structure. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with no output schema and no annotations, the description is quite complete: it states the purpose, return format, and a use case. It doesn't cover edge cases like empty windows or session prerequisites, but those are not critical for this simple operation.
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 provides no constraints to clarify. The description adds value by documenting the output structure, which is the primary semantic content. Baseline for 0 params is 4, and the description meets it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List all Onda main windows,' which is a specific verb and resource, clearly distinguishing it from sibling tools like onda_workspace_list. It also provides a return shape, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this before placing a new workspace/terminal' to understand window/workspace mapping. It lacks explicit alternatives or when-not-to-use, but the scenario is clearly stated, which is sufficient guidance for this simple list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals idempotency and the side effect of freeing the ring buffer, including the 'drops back to idle size after the last subscriber leaves' detail. It does not mention error handling or return values, but for a simple detach tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with zero filler. The first sentence states the primary action, and the second adds essential resource-management context. Every word earns its place.
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 no annotations and no output schema, the description is complete. It covers purpose, idempotency, when to call, and the resource effect. No critical information is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with 'Session ID to detach.' The description adds minimal extra meaning beyond naming it a 'listener session,' which aligns with the tool's purpose. The baseline of 3 is appropriate because the schema adequately documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Detach a listener session.' It names a specific verb (detach) and resource (listener session), and the idempotency note further clarifies behavior. It is distinct from sibling tools like onda_terminal_kill (which would terminate the terminal) and onda_terminal_subscribe (which creates the session).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Always call this when done to free the ring buffer,' providing clear usage context. It does not mention alternative tools or when not to use it, but the guidance is unambiguous for the resource-cleanup scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does exceptionally well: it discloses blocking behavior, timeout default, immediate return, and cursor advancement. These are critical behavioral traits that an agent must know to use the tool safely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each adding unique value: purpose, blocking/timeout, cursor behavior, and usage loop. It is front-loaded and free of 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?
The description covers the essential behavior and a usage pattern, which is sufficient for a simple polling tool. However, it does not clarify what happens on timeout (e.g., whether an empty response is returned) or how invalid session IDs are handled, leaving a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage, so the description adds little beyond reinforcing the default timeout. The baseline of 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Long-poll a subscribed terminal session for new output,' clearly stating the verb, resource, and purpose. It distinguishes from siblings by emphasizing 'subscribed' and the polling mechanism, and the cursor advancement detail reinforces its unique role.
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 an explicit usage loop ('subscribe -> poll -> poll -> ... -> unsubscribe') and explains the immediate-return behavior when data is pending. However, it does not explicitly discuss alternatives (e.g., 'use read for one-shot') or when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 and does well by disclosing the mechanism (writing `exec` into the PTY), the preservation of argv elements, and the selection rule for workspaceId. It adds meaningful context beyond the schema. It could go further by noting the destructive nature of exec (replacing the current process), but the term 'exec' implies this, and the description is otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and directly front-loads the core action and mechanism. Each sentence earns its place: the first explains what the tool does, the second explains when to use it and how the parameters are disambiguated. No fluff 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?
Given the moderate complexity (4 params, no output schema, no annotations), the description covers the essential aspects: action, mechanism, use case, and parameter selection. It could be slightly more complete by mentioning potential error states or post-spawn behavior, but the provided context is sufficient for an agent to correctly invoke the 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?
Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying the optionality of paneId vs workspaceId and the behavior when only workspaceId is given ('the first terminal pane in that workspace is used'). This extra detail about parameter interactions boosts the score above baseline.
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: 'Spawn a binary inside an EXISTING pane by writing `exec bin args...` into its PTY.' It uses a specific verb (spawn) and resource (pane), and distinguishes from sibling tools by focusing on executing a binary vs. sending input or listing terminals. The mention of launching 'claude' further clarifies its intended niche.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to launch claude (or any agent) with a structured prompt inside a workspace pane created via onda_workspace_add_terminal,' providing a clear use case. It also explains the paneId/workspaceId fallback logic. However, it does not explicitly mention when not to use it or name alternative tools, so it stops short of full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses blocking behavior, timeout, regex engine, default flags, and the return object shape. It does not mention edge-case behavior on timeout, but the return type covers the expected outcome.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: the first states the core function, the second gives a practical use case, and the third clarifies regex specifics and return type. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is quite complete for a wait tool: it covers purpose, usage pattern, parameter details (flags), and return shape. It lacks explicit mention of timeout failure behavior, but that is implied by the return object and the phrase 'or timeout'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. The description adds value by clarifying that 'pattern' is a JavaScript regex string, explaining the default flags ('m'), and describing the return object, which is especially useful since no output schema exists.
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 (block) and resource (terminal output), clearly distinguishing it from sibling tools like terminal_read, terminal_poll, and terminal_run. It states the exact behavior: wait for regex match or timeout.
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 explicit use-case guidance: 'Useful to synchronize scripted command sequences: run command -> wait for prompt -> run next command.' This implies when to use it over alternatives, though it doesn't explicitly name excluded tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action (open a fresh empty main window) and the return value ({ windowId }). It also adds the context that this avoids contaminating existing windows, which is useful. It does not mention potential side effects like focus changes, but the description is reasonably transparent for a creation 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 two sentences long and front-loaded. The first sentence states exactly what the tool does, and the second provides usage context. Every word earns its place; there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple tool with no parameters and no output schema. It explains the purpose, the return value, and the ideal use case. Given the context of sibling tools, the concept of a 'window' is clear. Minor details like failure conditions are not addressed, but they are not essential for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (since no properties are defined). The baseline for 0 params is 4, and the description does not attempt to add parameter information because there is none. The description's mention of the return value is a bonus.
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 opens a fresh empty main window, using a specific verb and resource. It also draws an analogy to File > New Window, making the purpose unmistakable. This distinguishes it from sibling tools like onda_window_list and onda_window_focus.
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 guidance on when to use the tool: 'when an agent needs to host a workspace in a brand new window without contaminating existing ones.' It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to decide.
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 details the return shape and the meaning of 'mountedIn', including the null case. It does not explicitly state read-only behavior, but the absence of side effects is implied. Minor gaps like error handling or multiple matches prevent a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, and every sentence adds value. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with no output schema, the description covers the purpose, parameter semantics, return shape, and field meaning. It lacks details on edge cases (e.g., multiple matches, error handling), but given the simplicity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning by clarifying that id, name, and rootPath are alternative lookup keys, and explains what the return value looks like for each. This exceeds the baseline.
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 'Find' and the resource 'workspace', specifying lookup by name, id, or rootPath. It distinguishes itself from the sibling 'onda_workspace_list' by explicitly noting 'without listing them all'.
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 'without listing them all' indicates a targeted lookup use case, providing clear context for when to use this tool over a listing tool. However, it does not explicitly mention alternatives or exclusion criteria, so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the behavioral disclosure burden. 'List' implies a read-only operation, and the added context about discovering terminals before sending commands helps the agent understand its role. However, it does not explicitly state safety characteristics like 'no side effects' or permission requirements, which would earn a 5.
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 exactly two sentences, front-loaded with the core function, and every word adds value. No redundancy or fluff.
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 zero parameters, no annotations, and no output schema, the description is fully complete for a simple list tool. It states what the tool does, what it returns, and when to use it, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema is empty (100% coverage). Per the guidelines, a baseline of 4 is appropriate since there is nothing to explain about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all panes in the active tab' with specific verb and resource. It also specifies return values (pane IDs, terminal IDs, content types), which distinguishes it from sibling pane operations like split, close, and focus.
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 usage context: 'Use this to discover available terminals before sending commands.' This tells the agent when the tool is appropriate, though it does not explicitly mention alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels: it discloses buffer size (200 KB / 1 MB with listener), return contents (buffer + byte total + timestamps), and the lazy passive tap with no impact on the terminal. This is thorough and honest.
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 compact, front-loaded with the primary action, and every sentence adds value: return contents, use case, and side-effect behavior. No redundant or filler text.
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?
The description fully covers what the tool does, what it returns (buffer content, timestamps, byte total), and its side effects, which is especially important given there is no output schema. It's complete for a simple read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters (id, lines) already have clear schema descriptions. The tool description does not add parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Read recent output of a terminal', clearly stating the verb and resource. It distinguishes itself from sibling tools like subscribe by noting 'without subscribing to a live stream' and describing the passive tap behavior.
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 explicitly says 'Use to see what a terminal has printed without subscribing to a live stream', giving a clear use case. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 transparently explains the semantics of `mountedIn`, including the null case, which is essential behavioral information. It also implies a read-only operation, though it doesn't explicitly state the absence of side effects. The output format is fully specified, adding value beyond the 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?
The description is remarkably concise: a one-sentence purpose, a succinct output schema, and a one-sentence usage tip. Every phrase earns its place, with no fluff or repetition. The most important action ('List all workspaces') is front-loaded, and the format details are efficiently packed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully documents the return structure and field meaning. It also provides a practical cross-reference to another tool, making the API context clear. For a simple list operation with zero params, this is complete and actionable.
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 and the schema is empty, so the baseline is 4. The description adds no parameter details because none exist, but it does clarify the output fields, which is more relevant here. Thus it meets the baseline for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List all workspaces,' a specific verb and resource. It also details the output structure (id, name, rootPath, mountedIn), making the tool's purpose and scope unmistakable. This clearly distinguishes it from sibling tools like onda_workspace_create or onda_workspace_focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly suggests a complementary use with onda_window_list: 'Use this with onda_window_list to map workspaces ↔ windows.' This gives concrete context for when to call this tool. It does not mention exclusions or when not to use it, but for a listing tool that's straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It thoroughly discloses side effects: drops from tiled mosaic, releases mount registry slot, workspace remains in global list, and return object includes 'alreadyUnmounted'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every sentence earns its place. It has no redundant fluff while covering purpose, side effects, and return value.
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 a single parameter, no annotations, and no output schema, the description is complete: it specifies the return shape explicitly and details the operational behavior. Sibling tools are numerous but the description is self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter described as 'Workspace to unmount.' The description does not add significant semantics beyond this; it reinforces that the parameter identifies the workspace but offers no new details. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Remove a workspace from whichever window currently hosts it.' It specifies the scope (hosting window, tiled mosaic, mount registry) and distinguishes it from siblings by explaining what it does not do (workspace continues to exist globally).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is used to unmount a workspace from its current window. It implies when to use but does not explicitly name alternatives or state when not to use, so it lacks the explicit 'when-not' guidance for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the sequential operations, atomicity from the agent's perspective, the ask-user non-proceeding behavior, and the success return shape. This goes beyond the schema and gives the agent a clear model of what will happen.
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 organized into a first-sentence workflow, placement modes, ask-user detail, and success return. It is slightly long due to the ask-user explanation, but every sentence contributes and the structure is front-loaded.
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 complex macro with 6 parameters, a nested workspace object, and no output schema, the description covers workflow, placement semantics, the interactive path, and return shape. It does not detail error handling or the addTerminalIfNeeded=false behavior, but the schema covers the latter; overall it is complete for agent use.
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 already covers 100% of parameters, but the description adds the default placement ('auto'), clarifies that prompt is passed as a single argv and is ignored if args is set, and explains the ask-user return contract. These are meaningful semantic additions beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'High-level macro: ensure workspace exists → mount it in target window → add a terminal pane → spawn bin with args...' which names a specific verb chain and resource. This clearly distinguishes the tool from lower-level sibling tools by emphasizing its macro and atomic scope.
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 identifies itself as a high-level macro and describes placement modes, including the interactive ask-user flow with re-invocation instructions. It does not explicitly name alternative tools or state when not to use it, but the context is clear enough and no exclusions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states idempotency, the atomic transfer via the unmount-request flow, the return object, and how `direction` affects tile splicing. This is rich, transparent detail that goes far beyond a simple action statement.
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, dense paragraph that front-loads the primary action and then covers edge cases, return values, and parameter behavior. There is minimal redundancy and every sentence carries meaningful content, though the length could be slightly trimmed for even better scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description manually discloses the return shape `{ success, workspaceId, windowId, transferred }`. It covers all significant behaviors: idempotency, transfer across windows, direction defaults, and anchor behavior. For a tool with 4 parameters and complex side effects, this is thoroughly complete.
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 already provides 100% coverage for all four parameters, including defaults for `direction` and `anchorWorkspaceId`. The description adds valuable semantic context by explaining the real-world meaning of `direction` (mirrors Cmd+P picker) and the return fields, but it does not need to explain the already-documented parameters extensively.
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 opens with a specific verb and resource: 'Mount a workspace in a specific window.' It clearly distinguishes the action from siblings like unmount, list, and focus by focusing on the mount operation and its unique transfer flow. The mention of idempotency and atomic transfer further pinpoints the exact behavior.
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 establishes when to use the tool: whenever a workspace needs to be mounted in a window. It also covers edge cases (already present, mounted elsewhere) and explains the transfer behavior. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It explains the return modes (dataUrl vs tempfile), the return object shape (dataUrl|path, width, height, windowId, capturedAt), and defaults (focused window, PNG, dataUrl=true). It omits error conditions or side effects, but for a read-only capture operation these are minor 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 three sentences, each earning its place: what it does, when to use it, and what it returns. It is front-loaded with the core purpose and contains no fluff or repetition.
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 all-optional parameters and no output schema, the description covers essential context: return shape, defaults, and use cases. It doesn't address error handling or capture timing, but overall it is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of the 4 parameters, setting a baseline of 3. The description adds value by summarizing defaults and providing practical guidance for when to set dataUrl=false ('useful for large captures'), which assists parameter selection beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Capture') and resource ('Onda main window'), clearly indicating the tool's function. It also states the intent 'for visual debugging' and distinguishes itself from all sibling tools, none of which capture screenshots.
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 when you (the agent) need to SEE what the user sees' and lists concrete scenarios (verifying layout, confirming rendering, investigating UI glitches). Since no sibling tool offers screenshots, no alternative or exclusion is needed.
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 bears the full burden of behavior disclosure. The verb 'Read' implies non-mutating behavior, and it discloses the null-return edge case for unknown workspace ids. It does not explicitly state 'no side effects', but the read framing plus the return contract is sufficient for a read-only 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?
Three sentences, each serving a distinct purpose: output contents, usage guidance, and edge-case behavior. It is front-loaded and every sentence earns its place, with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description enumerates the return fields and provides a concrete use case. It could be more detailed about the mosaic tree structure, but the essentials are covered, and the tool's purpose is simple enough that this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional workspaceId parameter, so baseline is 3. The description adds value by clarifying the null-return behavior for unknown ids and reinforcing that omitting the parameter uses the active workspace, which goes beyond the schema's simple description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Read the current layout of a workspace', clearly specifying a read verb and the resource (workspace layout). It enumerates the returned data (mosaic tree, pane IDs, active pane, viewport dimensions, per-pane cwd), making it distinct from sibling tools like pane_split or workspace_focus.
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?
It explicitly states when to use: 'Use this BEFORE spawning a new terminal to decide where to place it (right/down/replace) and whether the viewport has room.' It also gives guidance on workspaceId omission and the null return for unknown ids, offering clear contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the read-only nature via 'Get' and enumerates the return values. However, it does not explicitly state the absence of side effects or mention any prerequisites/errors, though these are largely implied for a context getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states purpose and output, the second gives explicit usage guidance. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool, the description fully covers what it returns and when to use it. The output fields are listed, and the sibling tools are distinct, so no additional elaboration 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 tool has zero parameters, so the baseline is 4. The description adds no parameter information because none exists, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the current Onda terminal context, naming the specific resource and the returned fields (paneId, tabId, workspaceId). This distinguishes it from sibling tools that operate on panes, tabs, or workspaces.
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 instructs to 'Use this FIRST' to know the current pane/tab before splitting or sending commands, providing clear when-to-use guidance and implicitly contrasting with alternative operations.
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 that each key entry is mapped to stdin bytes, supports a wide range of special keys, and falls back to raw literal text. This sufficiently conveys the tool's behavior for a non-destructive input operation, though it does not mention any potential side effects or blocking behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, followed by supported keys and an explicit alternative. Every sentence earns its place, and the structure is highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a key-sending tool with two well-documented parameters and no output schema, the description provides sufficient context: what it does, what keys it supports, and when to use it instead of the sibling tool. 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?
Schema coverage is 100%, so baseline is 3. The description adds semantic value by explaining that 'Each entry in `keys` is mapped to the appropriate stdin bytes' and listing supported key categories, which complements the schema's example-based parameter 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 tool's function with a specific verb and resource: 'Send semantic key sequences to a terminal.' It also distinguishes itself from the sibling tool onda_terminal_send by specifying 'Use this for tmux-like control instead of onda_terminal_send when you need to type special keys.'
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?
Explicit usage guidance is provided, including when to use this tool over the alternative: 'Use this for tmux-like control instead of onda_terminal_send when you need to type special keys.' The description also enumerates supported key types, making the scope clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so richly. It discloses the PTY readiness wait, the exact return fields, the default react-mosaic split behavior, the 'splitPane' routing for deterministic placement, and the effect of waitForReady=false. This exceeds what a bare 'add terminal' description would provide and gives the agent accurate expectations.
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 well-structured: a one-sentence purpose with return fields, a placement paragraph that explains default and deterministic behavior, and an actionable prerequisite callout. No filler or redundancy; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no annotations and no output schema, the description fully covers the tool's behavior, return value, parameter nuances, and prerequisite workflow. It is complete for a tool of this complexity and provides clear next steps for placement decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already covers 100% of parameters, the description adds substantial extra meaning. It clarifies the practical effect of direction (top/bottom vs left/right pairs), how relativeToPaneId defaults to the active pane, and what waitForReady implies for return timing. This goes well beyond the schema's property 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 opens with a specific verb+resource: 'Add a new terminal pane to a workspace' and states the wait-for-ready behavior. It clearly differentiates from sibling tools by explicitly describing the workspace-level pane creation and mentioning deterministic placement via splitPane, which distinguishes it from generic terminal spawn or pane split tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it explains when to use the default append behavior versus deterministic placement, and explicitly instructs calling onda_workspace_layout first when placement matters. It does not explicitly name alternatives such as onda_terminal_spawn or when not to use this tool, but the guidance is sufficient for most selection scenarios.
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:

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

Score Badge

Copy to your README.md:

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

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/mindfullabai/onda-mcp'

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