hyperpanes-mcp

by Eyalm321

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.13
Disambiguation4/5
Most tools are clearly distinct, but there is some potential overlap between messaging/input tools like send_message, queue_prompt, prompt_pane, and send_input, which all involve sending text to a pane. Descriptions are detailed enough to separate them, but the boundaries are not perfectly obvious at a glance.
Naming Consistency4/5
The naming convention is predominantly verb_noun in snake_case (e.g., launch_workspace, lock_pane, enqueue_task), which is consistent. Minor deviations like whoami and send_to_parent break the pattern slightly, but overall the convention is predictable and readable.
Tool Count2/5
With 47 tools, this server is far above the typical well-scoped range of 3-15. While the tool count reflects a broad feature set (panes, workspaces, queues, messaging, projects, speech), it exceeds the threshold where usability suffers, making it feel bloated and harder to navigate.
Completeness4/5
The tool set covers the domain comprehensively: pane lifecycle, workspace management, queue operations, project management, messaging, and app control. Minor gaps exist (e.g., no explicit window/tab listing tool, no move/resize pane), but agents can work around them using existing tools, so the surface is largely complete.
Average 4.3/5 across 47 of 47 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 commits in the last 12 weeks
- Last stable release on July 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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 action without revealing side effects such as whether it changes keyboard focus, brings the window to the foreground, requires the pane to be visible, or is idempotent. This is a significant gap for a UI mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that gets directly to the point. It avoids unnecessary detail, which is appropriate for a simple tool, though it could benefit from a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and one undocumented parameter, the description is too sparse. It explains what the tool does but omits crucial context about side effects, parameter semantics, and usage scenarios. The availability of many sibling tools further reduces the agent's ability to choose correctly based on this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema declares a single required string parameter 'paneId' with no description, and the tool description does not mention it at all. The agent is left to infer what paneId refers to and how to obtain it. With schema coverage at 0%, the description fails to compensate for the missing parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'focus' and the resource 'pane', and adds that it affects the associated tab/window. This distinguishes it from sibling tools like list_panes, open_pane, and close_pane. However, it does not specify what 'focus' means in this context (e.g., bringing to front vs. setting keyboard focus), leaving slight ambiguity.
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 or how it compares to alternatives. There is no mention of typical scenarios, prerequisites, or exclusions. Given the large set of sibling tools, the agent receives no help in selecting this one over others.
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 does clarify the lock is 'advisory' and 'write' and that you must hold it, which is useful. However, it omits critical behavior such as what happens if you don't own the lock, whether the operation is idempotent, and the meaning of 'agent-orchestration H', which remains opaque.
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 12-word sentence that is front-loaded with the action and resource. Every word contributes meaning, and there is no filler or redundancy. This is an example of efficient, well-structured prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and sparse parameter information, the description is the only source of context. It covers the basic action but omits important situational details (usage timing, failure modes, ownership semantics) that would be needed for an agent to invoke it confidently. The description is too minimal to be considered complete for safe autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explicitly map parameters to their meanings. It hints that 'paneId' refers to the pane and 'owner' to the lock holder, but these connections are not stated. With only two string parameters, the description should have clearly linked them to pane and owner, which it only does indirectly.
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 'Release' with a clear resource: 'an advisory write lock you hold on a pane'. This precisely states the action and distinguishes it from siblings like lock_pane and other pane operations. The parenthetical '(agent-orchestration H)' is cryptic but does not undermine the core 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies you should use it when you want to release a lock you hold, but it gives no explicit guidance on when to use versus alternatives, no prerequisites (e.g., must be the owner), and no mention of failure conditions. Sibling tools like lock_pane are not referenced, leaving the usage context largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the important behavioral trait that closing a pane terminates its shell, implying irreversibility. However, with no annotations, it does not mention other potential side effects such as affecting child processes, whether confirmation is required, or whether the action is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It immediately states the action and consequence, earning its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is too brief. It lacks information about consequences on the shell process, reversibility, and any conditions for closing, making it incomplete for an agent to fully understand the tool's impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the paneId parameter. It only says 'a pane' without specifying that paneId is the identifier or how to obtain it, so no meaning is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Close'), the resource ('pane'), and a key effect ('terminating its shell'). This distinguishes it from sibling tools like read_pane, lock_pane, and restart_pane, which have different operational purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as restart_pane or lock_pane. There is no context about prerequisites, exclusions, or scenarios where closing is appropriate, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the recipient selection logic (meta.parent chain), the default root, and the return value (list of recipients). This provides meaningful behavioral context beyond the schema, though it does not mention potential side effects or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and includes a clear parenthetical clarification. Every word earns its place with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, recipient selection, default root, and return value, but lacks parameter details for body/from and does not address usage alternatives or limitations. Given no output schema and no annotations, the description is adequate but leaves notable gaps in a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, and the tool description only clarifies the 'root' parameter (default value), which is already in the schema. 'body' and 'from' are not explained in either the schema or the description. The description fails to compensate for the low schema coverage, leaving the semantics of these parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Send a message to every pane in an org subtree') with a precise resource definition (panes whose meta.parent chain leads back to root). It distinguishes from siblings like send_message and send_to_parent by specifying the broadcast scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when broadcasting to a subtree) and gives a default root, but does not explicitly mention alternatives or when not to use. No comparison with sibling messaging tools is provided, so usage guidance is implied rather than explicit.
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 full burden. It discloses 'applied live' and acceptance of any CSS color string, which are useful behavioral traits. However, it does not mention error handling, permissions, reversibility, or side effects, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just two concise, front-loaded sentences. It states the action and the key input format without any waste. The example adds practical value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two required parameters, the description covers the main action, target, and color format. It lacks details on error behavior or prerequisites, but for a straightforward live-recolor operation, it is reasonably complete. No output schema exists, so return value explanation is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'color' with a concrete example and format, but 'paneId' is only implied through the phrase 'a pane's frame color' rather than explicitly described. This partially compensates but leaves a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Change a pane's frame color') with a distinct resource ('pane's frame color'), and the 'applied live' detail adds specificity. This differentiates it from sibling tools like recolor_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description (to change a pane's frame color), but there is no explicit guidance on when to use this tool versus alternatives like recolor_project, nor any exclusions or prerequisites. The context is clear but lacks explicit 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?
With no annotations, the description carries the full burden and covers important behaviors: durability ('survives every process involved'), deliver-once semantics, and the fact that it types into the owning pane. It could mention failure modes or queue limits, but the key behavioral traits are well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact two-sentence block that front-loads the core purpose and then adds essential behavioral details without unnecessary fluff. Every clause contributes to understanding what the tool does and when it applies.
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 two well-defined parameters and no output schema, the description covers delivery timing, durability, and lifecycle clearly. It does not discuss error handling or return values, but those are less critical for a queue action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides clear descriptions for both parameters (sessionId and text) with 100% coverage. The description adds minimal extra meaning beyond contextualizing that the message is typed into the session's pane, so it meets the baseline but doesn't exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Durably queue a message for a Claude conversation' and explains the delivery mechanism ('typed into the owning pane the next time that session is ready'). It distinguishes from sibling tools like send_message by emphasizing durability and deferred delivery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a session is not ready or when message persistence is needed, citing survival across restarts and reboots. However, it does not explicitly compare with alternatives like send_message or prompt_pane, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses one meaningful side effect ('The new name shows in the sidebar rail') but does not mention other behavioral aspects like error cases, persistence, or authorization. This is adequate but not rich for a mutating 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 two sentences long, front-loaded with the action, and every clause adds value: the resource, the id-finding tip, and the visible effect. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 simple params, no output schema), the description is nearly complete: purpose, prerequisite, and effect. It lacks explicit mention of return values or failure modes, but these are less critical for a straightforward rename operation with available sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must add meaning. It clarifies that 'id' is the project identifier obtained from list_projects and 'name' is the new display name. However, it does not provide details on id format or name constraints beyond the schema, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Rename a remembered project by id') and uniquely identifies the resource and method, distinguishing it from sibling tools like recolor_project. The phrase 'find ids with list_projects' adds valuable context for how to use the tool correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use the tool (renaming a project) and points to list_projects for finding ids, which is a correct alternative for a prerequisite step. It does not explicitly exclude using other rename tools, but the project-specific wording makes the intended use unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses key behavioral traits: durable inbox, at-least-once delivery, and sender identification semantics for 'from'. These go beyond a basic description, though it does not address failure modes or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the primary action and delivery guarantee. Each sentence adds valuable information without filler, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and only 3 parameters, the description adequately covers what the tool does, how delivery works, and how the target reads messages. However, it does not address when to use this vs sibling tools like send_to_parent or broadcast_subtree, and does not mention prerequisites or error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% with descriptions for 'to' and 'from', but 'body' lacks description. The description adds meaning for 'from' (sender should be paneId or orchestrator label) but does not clarify the 'body' parameter despite calling it 'structured'. It partially compensates for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enqueues a structured message to a pane's durable inbox with at-least-once delivery, using the specific verb 'Enqueue' and resource 'pane's durable inbox'. It distinguishes itself from siblings by noting the target reads via read_messages or its messages resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that the target reads via read_messages or its messages resource, implying send vs receive. However, it does not explicitly state when to use send_message versus alternatives like send_to_parent or broadcast_subtree, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: default re-queue until maxAttempts, then dead; delayMs for backoff; requeue:false for immediate failure; and the need for a fencing token. Since there are no annotations, these details are essential and are provided. It does not mention authentication or return values, but the core 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?
Three sentences, front-loaded with the purpose. Each sentence adds necessary information: the action, the default behavior, and the key parameter effects. No redundant 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 involves claim tokens and retry semantics, and the description covers the main behavior. However, without an output schema, it does not explain what the tool returns or what error conditions might occur (e.g., invalid fencing token). The dead queue concept is mentioned but not elaborated, leaving some gaps for a complex task queue 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?
The input schema describes 3 of 5 parameters (error, delayMs, requeue). The description adds meaning for fencingToken by stating it must carry the claim, and clarifies delayMs and requeue semantics, though it does not describe taskId or error explicitly. Overall, it partially compensates for the undocumented schema 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 opens with 'Report a claimed task as failed,' which is a specific verb+resource statement. It clarifies the retry/fail behavior and the requirement of a fencing token, distinguishing it from sibling tools like ack_task and enqueue_task. The title 'Nack (fail/retry)' also aligns.
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 gives clear context for when to use this tool: to fail a claimed task, with a fencing token. It explains the default re-queue behavior and the requeue:false option, but does not explicitly contrast with ack_task or other sibling tools. No exclusions are stated, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does so effectively by revealing the separate Enter submission, the turn-aware wait logic (won't return on pre-prompt screen), and the triple gate (app toggle, HYPERPANES_ALLOW_INPUT=1, confirm=true). While it omits edge-case behaviors like timeout handling, the core operational nuances are well covered.
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 dense, three-sentence paragraph that front-loads the primary action, then explains wait behavior, then composition and requirements. Every sentence earns its place with no fluff, though a structured breakdown (e.g., bullets) could improve scannability. It's appropriately sized for the complexity.
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 composite tool with no output schema and no annotations, the description covers the essential aspects: purpose, relationship to sibling tools, wait semantics, and confirmation requirements. It lacks a detailed return format description, but that's not necessary given no output schema. The core functional contract is adequately conveyed.
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 high (86%), so the baseline is 3. The description adds semantic value for the `text` parameter (clean submission) and the `confirm` parameter (must be true as part of the triple gate), but it does not elaborate on parameters like `tail`, `owner`, `settleMs`, or `timeoutMs` beyond what the schema already specifies. It adds modest context without needing to fully compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Drive one full turn of a TUI agent ... with ONE call' and enumerates the exact sequence (type, submit, wait, return transcript and awaiting state). It also distinguishes this tool from siblings by explicitly naming its composition of send_input(submit) + read_pane(waitForIdle, mode:'screen'), making its unique role clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage context by explaining it composes send_input and read_pane, implying it should be used when a full send-and-read cycle is needed in one call. It gives an example use case (live `claude`) and notes the triple gate requirement, but it does not explicitly contrast with other sibling tools like send_message or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of transparency. It explicitly discloses which tasks are dropped (done/failed/dead), which are kept (queued/claimed), and that a count of removed tasks is returned. This is clear but does not note whether the action is irreversible or if any permissions are needed.
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 the primary action in the first sentence and the return value in the second. There is no extraneous information or repetition, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description is quite complete: it covers the scope of tasks affected, the retention of in-flight tasks, and the return value. It lacks details about error conditions or prerequisites, but given the low complexity, it adequately answers the key questions an agent would have.
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 provides only a 'queue' string with no description (0% coverage). The description mentions 'from a queue', which clarifies that the parameter identifies the target queue, but it does not specify whether it is a name, ID, or the expected format. This is minimal compensation for the lack of schema detail.
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 ('Drop') and the resource ('TERMINAL tasks from a queue') while specifying which task states are affected (done/failed/dead). It distinguishes itself from sibling tools by focusing on cleanup rather than enqueueing, claiming, or listing tasks.
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 'for retention/cleanup' indicates when to use the tool, and the statement that in-flight tasks are kept helps set expectations. However, it does not explicitly mention alternatives like 'use list_queues to see queues first' or when not to use it, so it falls 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 full burden. It explains the data source (HYPERPANES_PANE_ID) and the kind of information returned, but does not explicitly state whether the operation is read-only, if any permissions are needed, or what happens if the paneId is invalid. It implies non-destructive behavior but lacks explicit 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 concise: two sentences, front-loaded with the primary action, and every phrase contributes (mechanism, reported fields, use case, optional parameter). No 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?
Given no output schema and no annotations, the description compensates by listing the reported metadata fields and explaining the main use case. It does not describe error behavior or return format in detail, but for a simple read-only introspection tool it provides sufficient context for an agent to invoke it appropriately.
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 only parameter (paneId) is described as optional and for 'a specific pane instead', which adds meaning beyond the bare schema. However, it does not detail format, validation, or default behavior beyond 'instead', so it is clear but not exhaustive.
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 ('Identify') and resource ('the pane this MCP bridge is running inside'), and clearly states what it reports (org metadata + window/tab context). It also provides a practical use case as 'the recursion enabler', distinguishing it from sibling tools like list_panes or read_pane.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear scenario for when to use it: 'a manager-agent-in-a-pane calls this to learn who it is before driving its sub-workers.' It also explains the optional paneId usage ('describe a specific pane instead'). It does not explicitly mention when not to use it or list alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclose important behavior: it returns the task's state, payload, attempts, lease, and timestamps, and returns task:null if the task does not exist. It does not mention authentication or side effects, but for a simple fetch this is sufficient behavioral 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 only two sentences, front-loaded with the core action, and every clause adds value. It avoids unnecessary words and clearly states both the input and the return behavior.
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 getter with no output schema, the description is complete: it identifies what is returned, names the key data fields, and explicitly handles the not-found case. This gives an agent enough information to invoke the tool and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and one required parameter, taskId. The description's 'by id' adds a little semantic meaning by linking the parameter to the task being fetched, but it does not provide format details, examples, or constraints beyond what the parameter name already implies. The schema is self-explanatory enough that this is adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Fetch one task by id') and clearly names the resource and scope, which distinguishes it from sibling tools like list_tasks or claim_task. It also lists the returned data fields and the null return for missing tasks, 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 makes it clear that this tool is for retrieving a single task when you have its id, implying the appropriate scenario. It does not explicitly mention alternatives or when not to use it, but the context is clear enough given the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the immediate action ('kill any in-flight utterance') and the clearing of backlog, plus the global one-shot nature. This provides meaningful behavioral insight beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is direct and front-loaded, with no wasted words. Every segment adds 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?
The tool is simple with no parameters and no output schema. The description fully explains what the tool does and the scope ('global one-shot'), making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly focuses on behavior since there are no parameters to explain.
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') with clear resources ('in-flight speech utterance' and 'speech backlog'). It clearly distinguishes from siblings like set_speech by focusing on stopping rather than setting speech.
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 context about being 'global one-shot', implying it affects all speech, but it does not explicitly state when to use it versus alternatives or mention any exclusions. Usage is implied rather than spelled out.
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 critical behavioral requirement of lease fencing via fencingToken, which is essential for correctness. It also notes that `result` is optional and stored. It does not describe failure modes or side effects, but for a simple ack operation, the key behavioral trait is well covered.
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 primary purpose. Every sentence adds value: the first states the action, the second gives the essential requirement and optional parameter. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, no output schema), the description covers the essential behavior and the critical fencing requirement. It is sufficient for an agent to invoke it correctly, especially within the sibling set of task operations. It doesn't detail return values or edge cases, but these are not necessary for the tool's basic 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?
Schema description coverage is only 33% (only fencingToken has a schema description). The description compensates by clarifying the meaning and origin of `fencingToken` ('from the claim (lease fencing)') and by explaining the optional `result` parameter ('optional stored outcome string'). `taskId` is implicit in the context of a task operation, so the description adds sufficient meaning beyond the bare 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 states the action clearly: 'Mark a claimed task done.' This is a specific verb and resource, distinguishing ack_task from siblings like nack_task or extend_task. The title reinforces it as 'Ack (complete) a task', so the purpose is 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 provides a clear prerequisite: the tool must carry the fencingToken from the claim, implying it is used only after a task has been claimed. While it doesn't explicitly name alternatives, the context of sibling tools and the phrase 'claimed task done' makes the intended usage clear. There is no exclusionary guidance, but the core when-to-use is present.
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. It discloses the return content (canonical JSON, CLI command, JSON-only fields) and the optional write side effect. It does not mention overwrite behavior or error cases, but the core 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?
Two sentences, each packed with necessary details and no fluff. The main action is front-loaded, and the optional write and CLI-command return are clearly appended.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the tool's purpose, output, and side effects sufficiently. It lacks error/return-value details but is complete enough for an AI to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes path but not spec (50% coverage). The description compensates by explaining spec as the workspace spec to validate/canonicalize and path as the optional .json write target, adding meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates a workspace spec, returns canonical JSON, optionally writes to a path, and returns a CLI command when possible. This specific verb-action combination distinguishes it from sibling validate_workspace and launch_workspace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when canonical JSON or file writing is needed, and the presence of validate_workspace as a sibling suggests an alternative. However, it does not explicitly state when to prefer this over validate_workspace or other workspace tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the effect (extends lease by extraMs, prevents reaping) and the critical requirement of carrying the fencingToken. It does not mention failure modes, but this is acceptable for a simple heartbeat 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?
Two sentences, no wasted words. Front-loaded with the verb 'Heartbeat', immediately conveying the tool's purpose. Every part 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 simple lease-extension tool with no output schema and no annotations, the description is sufficiently complete. It explains the action, the reason, and the necessary parameter semantics. Could add error conditions, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (extraMs only). The description adds meaning to fencingToken ('must carry the claim') and re-emphasizes the role of extraMs. taskId is implicit by context but not detailed; however, it is self-explanatory.
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 ('extend') and resource ('task lease'), clearly distinguishing it from sibling tools like claim_task, ack_task, and nack_task. The phrase 'Heartbeat a long-running task' adds concrete operational 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?
It states when to use: for long-running tasks needing lease extension to avoid being reaped. It does not explicitly list alternatives, but the context strongly implies this is for already-claimed tasks, distinct from claiming or acknowledging.
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 takes on the burden of disclosure. It reveals important behavioral traits: the launcher must be supplied or set via HYPERPANES_BIN, the default mode writes a temp file, and cli mode drops JSON-only fields. It does not mention return values or blocking behavior, but the disclosed details are substantive.
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 pack a wealth of actionable detail: purpose, input alternatives, launcher requirement, environment variable, default mode, and tradeoffs. No word is wasted, and the most critical information 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?
Given the tool has no output schema or annotations, the description covers the essential inputs, launcher setup, and mode semantics well. It lacks explicit post-launch behavior or error cases, but for a tool of this complexity the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers path, mode, and launcher, but the spec parameter is empty. The description compensates by explaining spec is a workspace object, and it adds meaning to mode by describing default behavior and data loss implications. This exceeds the schema-only 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 launches hyperpanes with a workspace, using a specific verb and resource. It distinguishes itself from siblings like build_workspace and validate_workspace by focusing on the launch action and detailing the input options (path or spec).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on how to use the tool: provide a path or spec, and require a launcher via parameter or environment variable. It also explains the two modes and their tradeoffs, though it does not explicitly name alternative tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 clearly states that the tool lists layouts with descriptions and enumerates the exact values, so the agent knows what to expect. The verb 'List' conveys a read-only behavior, and the description provides all necessary behavioral information for this simple 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, each earning its place. The first sentence states the purpose and enumerates the supported layouts, while the second explains the practical use case. No wasted words 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 zero-parameter list tool with no output schema, the description provides the full set of supported values and their intended use. It lacks an explicit mention of the return format, but the enumeration and 'with descriptions' phrase give the agent enough context to 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?
The tool has zero parameters, so the schema coverage is vacuous and the baseline is 4. The description adds nothing about parameters because none exist, and it doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and a specific resource 'tab layouts', with a concrete enumeration of supported values. It clearly distinguishes from sibling tools like set_layout (which sets layouts) and list_panes (which lists panes).
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 tells the agent to use the returned ids for a group/tab `layout`, connecting this tool to set_layout. While it doesn't explicitly name alternatives or exclusions, the usage context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses advisory semantics, renewal by re-acquiring as the same owner, and the need to use the same owner in send_input. It does not describe behavior when the lock is already held by another owner, but covers the key ownership and lifecycle aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: purpose, advisory caveat, and renewal/ownership guidance. It is front-loaded with the core action and scannable.
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 annotations, no output schema, and three parameters, the description is fairly complete for invocation. It covers the lock lifecycle, ownership, and relationship with send_input. Missing details like contention behavior or return values could be useful but aren't essential for basic usage.
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 67% (paneId and owner are described, albeit paneId minimally). The description adds significant meaning to 'owner' by defining it as the lock identity and explaining its use with send_input. This goes beyond the schema and helps correct parameter usage.
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 takes an advisory write lock on a pane, with a specific purpose (restricting send_input to the owner) and duration (until expiry or release). This distinguishes it from siblings like unlock_pane and send_input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the lock (to gain exclusive write access to send_input), clarifies that an unlocked pane is writable by anyone, and instructs to pass the same owner to send_input. It doesn't explicitly mention alternatives or when not to use it, but the advisory context implies appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It reveals scope restriction (only named windows/tabs/panes), no escalation, hidden master token, and optional expiry. Omitted details include the behavior when no IDs are provided (empty scope) and the exact return format of the token, which would be valuable.
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 serving a purpose: defining the token and its scope, showing integration with open_pane, and noting the optional expiry. It is front-loaded with the core purpose and contains 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 four optional parameters, no output schema, and no annotations, the description provides a solid overview covering purpose, security boundaries, child usage, and expiration. It is complete enough for an agent to decide when to use the tool, though it could improve by describing the returned token structure and behavior with no scopes specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining all four parameters: 'named windows/tabs/panes' maps to tabIds, paneIds, and windowIds, while 'Optional ttlMs expires it' covers ttlMs. This adds meaning beyond the raw schema, although it stops short of describing defaults or edge-case behaviors.
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+resource structure: 'Mint a subtree-scoped control token.' This clearly distinguishes mint_token from sibling tools, which focus on messaging, layout, or workspace management. It also explains the token's role in child orchestration, 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 states how to use it: hand the token to a child via open_pane env with specific environment variables. It also clarifies that the child should receive the scoped token rather than the master token. However, it does not explicitly mention when NOT to use it or compare to alternative delegation methods, though no sibling tool provides a similar minting capability.
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 reveals that `command` alone runs through the shell while `args` executes directly with exact argv, warns about shell mangling, describes `meta` reserved keys, and explains project recency bumping and precedence. This goes beyond the schema and provides meaningful behavioral context, though some side effects of other parameters remain implicit.
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 long but densely packed with necessary information. It is front-loaded with the core function, then dives into parameter nuances. Every sentence earns its place, though the parenthetical asides make it slightly harder to skim.
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 10 parameters, no annotations, and no output schema, the description is quite complete. It covers return value, default window, parameter behavior, and failure cases for project. Some interactions (e.g., env merging, label limits) are not mentioned, but overall it addresses the complexity well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, but the description compensates richly. It explains the critical command/args relationship, the reserved keys for meta, and the project parameter's effects (cwd, color, recency, precedence, failure on unknown handle). This adds substantial meaning to parameters that the schema leaves opaque.
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 new pane in the active tab of a window, defaults to the first window, and returns the new paneId. This specific verb+resource and its distinction from sibling tools like open_tab and focus_pane make 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 provides explicit guidance on when to use `command` alone versus `args` (when arguments contain spaces or quotes) and references related tools list_projects/add_project for project handling. It does not explicitly contrast with open_tab or other pane operations, but the parameter-level usage conditions are clearly stated.
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 burden. It discloses a key behavioral trait: the change is 'applied live to the pane header.' It also explains the exact semantics of clearing or omitting the subtitle. This goes beyond the schema, though it does not mention reversibility or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence that front-loads the primary purpose and then adds essential usage nuances. No wasted words; every clause contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple rename tool with no annotations and no output schema, the description covers the action, the live behavior, and the subtitle edge cases. It lacks explicit error/prerequisite info, but given the low complexity, this is nearly complete. Minor gap: no mention of what happens if pane does not exist.
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 only 33%, so the description must compensate. It clarifies that label is the pane 'title' and explains the subtitle behavior in detail. paneId remains self-explanatory but is not given extra context. Overall, the description adds meaningful semantics beyond the schema for two of the three 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 begins with a specific verb ('Change') and clearly identifies the resource ('a pane's label (title)') plus the optional subtitle. It distinguishes from sibling pane tools (e.g., recolor_pane, lock_pane) by focusing on the naming aspect and the live header update.
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 parameter-level instructions ('Pass subtitle:"" to clear it; omit subtitle to leave it unchanged') and implies the tool is for changing pane labels. However, it does not explicitly compare with alternatives or state when not to use it, so it misses the 'explicit when/when-not' bar.
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 discloses the destructive kill/respawn action, the optional resume behavior, and the prompt queueing mechanism (including the 'requires resume:true' prerequisite). It could add more about side effects like unsaved state, but it covers the essential behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action, then elaborates on optional behaviors. Every sentence adds value without fluff. It is appropriately sized for the tool's complexity.
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 primary use case and all optional features (resume, prompt), including a key prerequisite. No output schema exists, but return values are not critical for a state-changing tool. It could mention failure scenarios or prerequisites like pane existence, but the core behavior is sufficiently documented.
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 describes prompt and resume, and the description adds meaning to prompt ('queues a message typed into the resumed claude... speak-first') and clarifies that resume:true is required for prompt. The required paneId parameter is not described in schema or text, but its name and context (target pane) are self-explanatory, so the gap is minor.
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 'Kill and respawn a pane's shell', a specific verb and resource that clearly distinguishes this from sibling tools like close_pane (which closes) and restart_app (which restarts an app). It also adds the unique capability of resuming a Claude conversation, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a concrete use case: 'an agent may target its OWN pane to restart itself.' It also explains when to use the resume and prompt options. It does not explicitly name alternatives or exclusions, but the context makes it clear this is the tool for restarting a pane's shell rather than sending input or managing panes.
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 behavioral transparency burden. It discloses that tabId defaults to the active tab of the first window, which is important runtime behavior. It does not cover side effects or permissions, but for a layout setter this is acceptable.
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-loads the main verb and object, and includes necessary context without 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 two-parameter tool with no output schema, the description covers the essential aspects: what, where (tabId default), and where to get valid values. It does not explain return values, but that is not critical for a setter.
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 no descriptions, leaving 0% coverage. The description compensates by defining the tabId default and directing the agent to list_layouts for valid layout IDs, which adds semantic meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the target ('the tiling layout of a tab'). The phrase 'tiling layout' distinguishes this from sibling tools like set_speech or set_talk, which target different resources.
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 concrete usage pointer: 'Use list_layouts for valid ids.' This tells the agent where to find valid layout values, but it does not explicitly state exclusion criteria or alternative setting approaches, so it stops short of full when/when-not 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?
No annotations are provided, so the description carries the full burden of disclosure. It clearly describes what the tool checks (API reachability, input allowed) and what it reports (pid/version, send_input gate, control.json path), effectively conveying that this is a read-only informational operation. It could optionally state explicitly that it has no side effects, but the verb 'Check' and the listed reports make this sufficiently clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences. The first sentence states the core purpose, and the second provides a specific usage directive. No redundant words or filler, perfectly front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status check with no output schema, the description is complete: it covers what the tool does, what it reports, and when to call it. It gives enough detail for an agent to invoke it and understand the result without needing additional context.
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 score of 4 applies. The description adds no parameter information, but none is needed since the schema already covers an empty object fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and identifies the resource ('hyperpanes control API') along with the two key questions: reachability and input-allowed status. It also lists the specific outputs (pid/version, send_input gate, control.json path), making the tool's purpose unmistakable and distinct from action-oriented siblings like send_input.
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 'Call this first if other control tools fail,' which is clear, actionable guidance for when to use this tool. It does not state when not to use it, but for a diagnostic status check, this single directive is sufficient to guide selection.
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 transparency burden. It discloses the heuristic nature of the liveness indicator ('busy/idle/exited liveness heuristic') and notes that org metadata is optional ('any org metadata'), setting accurate expectations for data quality. However, it does not explicitly state that the operation is read-only and side-effect-free, though 'List' strongly implies it. The inclusion of streaming URIs is a valuable behavioral clue for downstream usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence that front-loads the core action ('List all panes') and then efficiently lists the included data categories. There is no fluff, and every clause adds useful information about scope or return fields. It is appropriately sized for a simple list tool with no parameters.
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 that there is no output schema, the description thoroughly covers what the tool returns: status, activity (with heuristic caveat), org metadata, tab/window context, and resource URI. This is sufficient for an agent to understand the tool's output without needing an output schema. The absence of params and the simple list nature mean no additional context (e.g., pagination, sorting) is critical, but the return field enumeration is complete enough.
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, so there is nothing for the description to clarify. The baseline for 0 parameters is 4. The description omits parameter details because none exist, and instead focuses on output fields, which is appropriate. No deduction needed since the schema coverage is trivially 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 a specific action ('List all panes') and the resource scope ('across all windows/tabs of the running hyperpanes instance'). It also enumerates the returned fields (status, activity, org metadata, tab/window context, resource URI), which distinguishes it from sibling tools like read_pane (which reads a single pane) or focus_pane (which changes focus). This is a model of 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 provides strong context for when to use this tool: when you need a complete inventory of panes with their current state and streaming URIs. It does not explicitly mention alternatives or exclusions, but the scope ('all') and the data fields make it clear this is the enumeration tool, and sibling names like read_pane imply single-pane access. Lacks an explicit 'use X instead' statement, so not 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 of behavioral disclosure. It discloses the sort order (newest-opened first), the exact fields each project has, and the scope (running hyperpanes instance). While it doesn't explicitly state there are no side effects, the 'list' verb and the detailed output description give strong confidence, making this above average.
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: the first states the core purpose and ordering, the second details the output fields, and the third guides usage with related tools. It is concise, front-loaded with the main purpose, and free of filler.
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 zero-parameter list tool, the description is highly complete. It covers the output fields, ordering, scope, and even cross-references sibling tools for next steps. No additional context is needed to use this tool effectively.
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 is an empty object with zero parameters, so the baseline for parameter semantics is 4. The description adds value beyond the schema by explaining how to use the output values (id/name) in other tools, though it doesn't need to explain parameters since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists projects (remembered directories) tracked by the hyperpanes instance, with specifics like ordering (newest-opened first) and fields (id, path, name, frame color, lastOpenedAt). It distinguishes itself from sibling tools like add_project, rename_project, etc., by focusing on the read-only listing aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to see the sidebar rail of projects) and even gives guidance on how to use the returned ids/names with other tools like rename_project, recolor_project, remove_project, and open_pane. It does not explicitly state when not to use it, but the primary use case is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the output includes depth counts and that results are scoped to the token. The description also explains the queue's durable nature. It lacks explicit 'read-only' confirmation, but 'list' strongly implies it, and no side effects are relevant.
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 with no waste. The first sentence states the action and result; the second adds useful context about the queue's role. 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?
Given zero parameters and no output schema, the description fully covers what the tool does, its scope, and its intended use case. It is complete for a simple list 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, and the schema coverage is 100%. The description appropriately omits parameter details. Baseline for no params 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 the tool's function: 'List every work queue and its depth (pending/claimed/etc. counts).' It uses a specific verb (list) and resource (work queues), and distinguishes from siblings like list_tasks by focusing on queues and their depths.
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 context on when to use the tool: 'use it to fan work out to competing workers.' It also mentions scope-filtering via the token, implying usage constraints. It does not explicitly name alternatives, but the guidance is clear enough.
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 and reveals key behaviors: defaults to the first window, returns new tab ids (or pane ids in pane mode), and clarifies that each group becomes one tab. It could go further on permissions or error conditions, but the core effects are transparent.
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 dense but efficient, front-loading the core purpose and then adding mode-specific details in a structured way. It's slightly long, but every clause adds meaningful guidance—no 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 complex tool with nested objects, enums, and two modes, the description covers the essential invocation decisions: window default, group-to-tab mapping, the 'as' behavior, and return types. It doesn't cover every schema field or potential errors, but the schema fills those gaps, making this sufficiently complete for an agent to select and invoke 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?
Though schema coverage is 0%, the description compensates by explaining the meaning of 'as' (merging vs. tab creation), the grouping semantics ('Each group is one tab'), and the concept of a default window. It names several nested pane fields in the shorthand, but omits some (e.g., fontSize, sizes) and the exact windowId parameter name, so a 4 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: 'Attach one or more new tabs to an existing window' with fresh shells. It explicitly differentiates from the sibling tool open_pane by saying 'Use this (not open_pane) to add a whole tab, or several tabs, in one call.'
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: 'Use this (not open_pane) to add a whole tab, or several tabs, in one call.' It also explains an alternative mode 'Pass as:"panes"' for merging panes into the active tab, giving clear conditional 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 provided, so the description carries full responsibility. It discloses that the operation also retints open panes within the project, which is a notable side effect beyond the schema. It also qualifies the project as 'remembered', implying only stored projects are eligible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that front-load the action, include necessary context (id lookup and side effect), and contain no wasteful words.
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 two-parameter mutation with no output schema, the description covers all necessary aspects: target, input format, id acquisition, and side effect. It is sufficient 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?
The description adds meaning to the id parameter by explaining how to obtain it via list_projects, and provides a concrete hex color example. The schema only describes color as a hex string, so the description enriches both params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (set color), the target (remembered project's frame/dot color), and the required input (hex color). It also distinguishes from recolor_pane by operating on projects, and the side effect of retinting panes is noted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a direct pointer to list_projects for finding ids, and specifies the color format. It implies the tool is for project-level recoloring as opposed to pane-level (recolor_pane exists as a sibling), but does not explicitly contrast alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses the parent-resolution mechanism, environment variable requirement, override parameter, and error condition. It doesn't cover delivery semantics or return value, but for a simple send operation this is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, and the rest specifies constraints; no filler or redundant repetition.
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 2-param tool with no annotations/output schema, the description covers purpose, parent resolution, required environment variable, defaults, and error handling. Remaining gaps (return value, delivery) are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers only `from` fully; `body` lacks description. The description clarifies `body` as the message content and `from` as an override/default tie-in, adding value 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 states a specific action—'Message this pane's org parent'—and differentiates from generic send_message by specifying resolution via meta.parent and requiring a pane context. The scope and resource are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It identifies the use case (inside a pane with a parent) and prerequisites (HYPERPANES_PANE_ID or explicit from), and notes the error if no parent exists. It doesn't explicitly name alternative tools, but the context is sufficient to infer when this is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the effect of each parameter in plain terms (muted mutes/unmutes all speech; focusedOnly restricts to focused pane) and adds a behavioral constraint ('Provide at least one of the two'). It does not discuss persistence or side effects, but for a simple setter 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?
The description is two sentences, front-loaded with the main purpose, and includes only essential details. Every sentence 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?
The tool is simple with only two boolean parameters fully described in the schema. The description explains the tool's purpose, parameter semantics, and a usage constraint. No output schema is needed. It is complete 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 explaining the combined effect of the two booleans and the requirement to provide at least one. This goes beyond the schema's individual 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 sets global speech (TTS) settings, using a specific verb ('set') and resource ('global speech settings'). It distinguishes itself from sibling tools like stop_speech and set_talk by focusing on global configuration rather than per-pane or stop actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for adjusting global TTS settings. It includes a usage constraint ('Provide at least one of the two'), but does not explicitly mention when to use this tool instead of alternatives like set_talk or stop_speech, 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?
Since no annotations are provided, the description carries the full burden. It discloses the return value ('resolved talk state and TTS backend'), default state ('off by default'), and warning behavior on backend issues. It does not mention potential permissions or side effects, but the tool is a simple toggle.
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 concise sentences with no fluff: purpose, default, and return behavior. Each sentence earns its place and the key action is front-loaded.
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 toggle with two parameters and no output schema, the description is complete. It covers what the tool does, when it applies, its default state, and what it returns, including edge-case warnings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so by explaining that 'enabled' toggles talk on/off and 'per-pane' implies that paneId targets a specific pane. This adds meaningful context beyond the bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it 'turn per-pane talk on/off' with a specific verb and resource. It explains the behavior 'speaks NEW Claude assistant replies aloud via local TTS' and differentiates from sibling tools like set_speech by emphasizing 'per-pane'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it operates on a per-pane basis, affects only NEW replies, and is off by default. It does not explicitly mention alternatives or exclusions, but for a simple toggle this context is sufficient.
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 burden. It discloses the tool does not launch anything, returns a {valid, errors?, summary} object with summary semantics, and accepts both nested and legacy spec shapes — meaningful behavioral context. It stops short of explicitly stating it never mutates state, but validation is clearly non-mutating.
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: action+side-effect, return shape, accepted input variants. Front-loaded and free of filler.
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 one-parameter validation tool with no output schema and no annotations, the description covers the essential runtime behavior, return format, and input variations. Nothing critical is missing.
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 provides only an untyped 'spec' with no description (0% coverage), so the description must compensate. It explains the parameter is a workspace spec conforming to the hyperpanes schema and enumerates the two accepted shapes (nested windows[]->groups[]->panes[] vs legacy panes[]/groups[]). This adds useful meaning, though it doesn't document all sub-fields.
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?
Specific verb 'validate' with resource 'workspace spec' and clear scope ('against hyperpanes schema'). Distinguishes from sibling launch_workspace/build_workspace by explicitly noting 'without launching anything'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: validation is a pre-launch safety step and does not launch. Though it doesn't name alternative tools or state exclusions, the contrast with launching and mention of accepted input shapes implies when 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 of behavioral disclosure. It explains paging via `after`, default and max limits, and that the response includes per-state counts. This gives a good sense of the operation's behavior, though it doesn't explicitly state read-only or discuss edge cases.
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, each earning its place: the first states the core function and enumerates parameters, the second clarifies the paging cursor and return value. No fluff or repetition.
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 moderate-complexity tool with 4 parameters and no output schema, the description covers the purpose, optional filters, paging, default limits, and return shape (tasks plus counts). This is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only `after` has a brief description). The description compensates by explaining the `state` filter values, the paging mechanism for `after`, and the default/max for `limit`, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List/inspect tasks in a queue' with a specific verb and resource, and it distinguishes from sibling tools like list_queues (lists queues) and get_task (retrieves a single task). It also enumerates the optional filters, which further clarifies 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?
The description implies usage for inspecting tasks in a queue and provides context on how to page through results with the `after` cursor. It doesn't explicitly mention alternatives or when not to use it, but the purpose is clear enough that an agent can infer when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 side effect (removes from sidebar rail) and the important non-effect (does not delete directory). It could mention idempotency or behavior for unknown ids, but the core behavior is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and every clause adds value. The parenthetical usage hint and the explicit non-destructive clarification are essential and concise.
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 one-parameter tool with no output schema, the description covers purpose, how to obtain the id, the effect, and a key non-effect. It could add a sentence about reversibility or errors, but the current content is arguably sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there is only one 'id' field with no description, so the tool description must explain it. It does: the id refers to a remembered project and can be found via list_projects. While it doesn't elaborate on format beyond the schema's string type, it provides the needed context.
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 'Forget' and names the exact resource ('a remembered project by id'). It distinguishes itself from siblings by clarifying it removes from the sidebar rail and does NOT delete the directory on disk.
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 points to list_projects for finding ids, and clarifies the tool is not for deleting the directory on disk. This gives a clear when-to-use/when-not-to-use distinction.
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 exist, so the description fully discloses critical behavioral traits: it executes arbitrary input in a real terminal, is dangerous, and requires triple gating (app toggle, environment variable, and confirm=true). It also explains the subtle Enter-vs-newline behavior. This is exemplary 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?
While the description is longer than average, every sentence carries essential information—usage, safety, and configuration. It is front-loaded with the core action and then layers critical details efficiently. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, dangerous tool with 6 params, no annotations, and no output schema, the description covers the key behavioral aspects thoroughly: safety gates, submit semantics, and shell interaction. It could mention the owner param, but overall it is contextually complete for safe and effective 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?
Schema coverage is high (83%), providing descriptions for most params. The description adds crucial semantics beyond the schema: the meaning of submit (separate bare Enter), the newline issue, and the mandatory confirm flag. It doesn't cover owner, but the added value for core params justifies a 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 opens with a clear verb+resource: 'Type text into a live shell.' It specifies the tool's role precisely and distinguishes it from siblings by focusing on sending input to a shell, with special handling for TUI agents. The purpose is unambiguous and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use submit:true vs. without submit, including the bracketed-paste pitfall and the need for a trailing newline. It doesn't explicitly name alternative tools like send_keys, but the usage scenarios are well defined, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses the no-op behavior with added:false, the requirement that the path exists and is a directory, that git is not required, and the return value structure. This is thorough and non-obvious 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 primary action, then covers constraints and return behavior. Every sentence adds value with no redundancy or filler.
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 tool with one parameter and no output schema, the description fully explains when to use it, constraints, edge-case behavior (no-op), and return format. It is comprehensive and leaves no 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?
Schema coverage is 100%, providing a baseline of 3. The description adds meaningful semantics beyond the schema by clarifying that the path must be a directory (not a file), that a git repo is NOT required, and explaining the no-op behavior for already-known directories, which enriches the 'dir' parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remember' and the resource 'a directory as a project', explicitly comparing to the sidebar 'PROJECTS ＋' button. It distinguishes from sibling tools by specifying the creation action and what is returned (id/path/name/color).
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 for when to use the tool (equivalent to sidebar button, add a directory) and states constraints (path must exist and be a directory, no git repo needed). It does not explicitly list alternatives or exclusions, but the context is sufficient for a simple creation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: empty queue returns {tasks:[]} not an error, returned tasks include fencingToken and visibilityDeadline, token required for ack/nack/extend, and tasks return to queue if not acked/extended before deadline. This 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (three sentences) and front-loads the main action. Each sentence adds a distinct piece of information without redundancy, covering behavior, return values, and parameter semantics efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description sufficiently explains the return shape (empty array or tasks with fencingToken/visibilityDeadline) and the lease mechanism. It covers the important edge case of an empty queue and the lifecycle dependency on ack/extend, making it complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents worker, count, and leaseMs (but not queue). The description adds meaning beyond the schema: count prefetches several tasks, leaseMs overrides the task default lease, and worker is the claimant appearing as claimedBy. This adds value for the ambiguous 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 uses a specific verb 'Claim' with a specific resource 'task(s) off a queue' and clearly differentiates from sibling tools like enqueue_task, ack_task, and list_tasks by emphasizing the competing-consumer semantics. It tells exactly what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the competing-consumer pattern ('each task goes to exactly one claimer') and provides guidance on when to use count and leaseMs. It does not explicitly exclude alternatives like get_task or list_tasks, but the context makes the intended use 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, the description carries full burden and excels: it discloses queue auto-creation, auto re-queue up to N on nack/lease-expiry, dedupe via dedupeKey, DAG gating via dependsOn, scheduling via delayMs, and the return of id + seq. These are meaningful behavioral traits beyond merely 'enqueue a task.'
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 sentence but each clause earns its place, covering core behavior, payload, all optional params, and return value. It could be split into multiple sentences for readability, but it's not bloated.
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 11 parameters and no output schema, the description covers the core behavior, all optional parameter meanings, the goals-system semantics (goalId, dependsOn DAG gate), and explicitly states the return value (id + seq). It is complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 91%, the description adds value by explaining the semantics of each optional parameter in context: 'priority (higher runs sooner)', 'maxAttempts (auto re-queue up to N on nack/lease-expiry)', 'dedupeKey (collapse duplicate enqueues)', and 'dependsOn (task ids that must all reach done... a DAG gate)'. These enrich the schema's terse 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 begins with a specific verb and resource: 'Append a task to a work queue (created on first use).' This clearly distinguishes enqueue_task from sibling tools like claim_task, ack_task, and nack_task by focusing on the write-side operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (appending a task to a queue) and explains the purpose of optional parameters (triage, scheduling, dedupe, DAG dependencies). However, it does not explicitly name alternatives or state when-not-to-use scenarios, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and excels. It discloses that gui keeps panes alive, full flushes a snapshot and kills everything, the daemon exits, and conversations auto-resume. It also explains the speak-first pre-queue behavior, giving a complete picture of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph with zero fluff. Every sentence delivers critical information: auth requirement, scope behavior, survival semantics, snapshot flush, auto-resume, and optional parameters with an illustrative example. It is front-loaded and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive full restart, auth restriction, optional params) and no annotations or output schema, the description provides all essential context: behavior, side effects, prerequisites, and parameter usage. It is complete enough for an agent to invoke correctly and anticipate consequences.
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, but the description adds substantial meaning beyond the schema: it explains the implications of each scope value (surviving panes vs full death/restore), and clarifies that sessionId+prompt work together to pre-queue a message. It stops short of describing edge cases like missing sessionId or prompt-only usage, so not a 5.
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 restarts the hyperpanes app itself, distinguishing it from sibling restart_pane by specifying 'root token only' and the two scopes. The verb 'restart' plus the resource 'hyperpanes app' is specific, and the scope details prevent ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains the two scopes and their behavioral outcomes, providing clear guidance on when to choose 'gui' vs 'full'. It mentions the root-token requirement and optional sessionId+prompt usage, but does not explicitly name an alternative like 'use restart_pane for individual panes', though the contrast is implied.
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 of behavioral transparency. It thoroughly discloses critical behaviors: merge semantics (string values overwrite, null deletes, untouched keys kept), reserved key names (role/parent/agentType/task), and the fact that the return value is the true merged metadata read back from the app, not the raw input. This is comprehensive for a metadata update 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 appropriately sized and front-loaded. The first sentence states the core action, followed by compact yet essential details on behavior, return value, and intended usage. Every sentence adds value without 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 the tool's complexity (two parameters, nested objects) and the absence of an output schema, the description is complete. It explains merge behavior, return value, and reserved keys, leaving no significant ambiguity about what the tool does or what to expect as a result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the meta parameter with a clear description of key-value behavior, giving 50% coverage. The description adds meaning beyond the schema by listing reserved keys and clarifying the merge behavior. However, the paneId parameter remains minimally described, though its purpose is self-evident.
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 action ("Attach or update free-form metadata on a pane") with a well-defined resource (pane) and unique scope (free-form metadata). This distinguishes it from sibling tools like set_speech or lock_pane, which target different aspects of a pane.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool, including a concrete use case ("This is how an orchestrator records the org chart as data") and the merge semantics that define its behavior. It does not explicitly name alternative tools or state when not to use it, but the context is sufficiently clear for selection.
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 excels. It discloses ack/nack semantics (exit 0 ack, non-zero nack), pane exit after queue drain, worktree auto-removal, the necessity of `base` for worktree isolation, loud failure for single-pane account rotation, and the env var merge order (accounts wins over env, caller meta wins over defaults).
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 long, but every clause carries dense, relevant information for a 17-parameter tool. It is front-loaded with the core runner behavior and then proceeds through parameters in a logical order, using emphasis (caps, backticks) to highlight constraints. It could be slightly more scannable with bullet points, but it is not padded with 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?
The description covers the tool's purpose, execution model, lifecycle (queue drains → pane exits), return value (pane ids), configuration interactions, failure modes, and even defaults. With 17 parameters and no output schema, this description provides everything an agent needs to invoke the tool correctly and anticipate edge cases.
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?
Even with 88% schema coverage, the description adds extensive meaning beyond the schema: environment variables available in the command, the exact behavior of `count`, `layout`, `isolation`, `stream`, `logDir`, `lingerSecs`, and the nuanced merge order for `env`/`accounts`/`meta`. This goes well beyond the property descriptions and provides actionable invocation guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Spawn a pool of queue workers in one call (#6).' which is a specific verb+resource statement that clearly distinguishes it from sibling queue tools like enqueue_task or claim_task. It further specifies the runner behavior, bound queue, and the commands executed, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly describes the function of spawning workers and provides context on configuration choices (layout, isolation, stream, lingerSecs) and failure conditions (explicit 'the call fails' statements). It doesn't explicitly name alternative tools, but the context is strong enough that an agent knows when to use it: whenever a pool of queue workers is 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 provided, the description fully covers behavioral traits: it discloses the durable inbox nature, per-pane eviction cap, the meaning of 'dropped', and cursor-based incremental reading. This goes well beyond the basic 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?
Three tightly written sentences, each earning its place: purpose, cursor semantics, and the alternative to polling. 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?
Given the tool's simplicity and lack of output schema, the description covers essential concepts: durable inbox, cursor, dropped count, cap, and the live delivery alternative. It lacks an explicit statement of the response shape (e.g., array of messages), but this is reasonably implied. Overall, very complete for a read 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?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains 'after' as a cursor and the need to pass the highest seen seq. paneId is self-evident from its name and context. Minor gap: it doesn't explicitly state the default behavior without 'after', but the schema already marks it optional.
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 this tool reads a pane's durable message inbox, with specific mention of cursor semantics and dropped message counts. It distinguishes itself from polling/live delivery by explicitly contrasting with subscribing to the messages resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use guidance: use for durable reads with cursor-based pagination, but for live delivery, subscribe to the pane's messages resource instead of polling. This is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure and does so thoroughly. It reveals that transcript mode reads from disk (not screen), screen mode avoids overdraw/spinner spam, waitForIdle blocks with configurable timeouts, since acts as a byte cursor, and every read returns the current cursor. No contradictions with annotations exist.
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 of roughly 180 words. It is front-loaded with the primary purpose, and every sentence adds operational value for a 9-parameter tool with three modes. It is somewhat lengthy, but the complexity justifies the detail; no waste is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no output schema, and only 67% schema parameter coverage, the description covers all significant behavioral facets: mode semantics, cursor-based incremental reads, blocking waitForIdle behavior, defaults for settleMs/timeoutMs, and an explicit streaming alternative. It is complete enough 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 coverage is 67%, leaving tail, strip, and paneId without schema descriptions. The description compensates by explaining tail ('limits to the last N lines'), strip ('removes ANSI escape codes'), and adding rich context for mode, since, and waitForIdle. However, messages and paneId are not addressed in the description, though schema covers messages and paneId is self-evident.
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 the specific action 'Read a pane's terminal output' and then details three distinct modes (raw, screen, transcript), clarifying what each returns. It explicitly contrasts with the raw pty stream and screen scraping, and the sibling set includes read_messages, so the purpose is clearly distinguished from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: mode:"transcript" is called 'the reliable way to read a claude pane', waitForIdle is 'the way to read a reply without polling/sleeping', and it directs users to 'subscribe to the pane's output resource instead' for continuous streaming. This clearly states when to use this tool and when to use an alternative.
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 fully carries the transparency burden. It discloses the gating mechanism ('app toggle + HYPERPANES_ALLOW_INPUT=1 + confirm=true'), specifies that it sends 'the right terminal bytes', and emphasizes it is input (same as send_input). This goes well beyond the schema and provides critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the purpose, scope, use cases, and gating requirements without redundancy. Information is front-loaded and every clause serves a function. No wasted words.
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, the description is complete: it defines the input, behavior, use scenarios, and prerequisites. There is no output schema to explain, and the description covers the essential context an agent needs to select and invoke this 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?
The description adds a comprehensive enumeration of accepted key names, enriching the 'keys' parameter beyond the schema's examples. However, it does not clarify 'paneId' (which lacks a schema description) or add meaning to 'owner', leaving a modest gap. Since schema coverage is 75% and the description partially compensates, a score of 4 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 verb ('Send') and resource ('a sequence of named keys to a live pane'), and enumerates the supported keys. It explicitly differentiates from send_input by noting it handles 'things a text string can't express', making the tool's unique purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete use cases: 'For menus, y/n and trust prompts, and cancelling'. It also references send_input and the 'triple gate', implying when this tool is appropriate and that it shares input restrictions with send_input. This gives clear contextual guidance.
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:

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

Score Badge

Copy to your README.md:

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

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