herdr-mcp

by aelaguiz

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct resource/action pairs (list_panes, list_agents, split_pane, close_pane, wait_agent, wait_for_output). The main ambiguity is among send_text, send_keys, run_command, and prompt_agent, since all deliver input to a pane; the descriptions largely clarify them, but an agent could still misselect send_text vs run_command or prompt_agent when composing an action.
Naming Consistency5/5
Almost every tool follows a clear verb_noun pattern: list_*, get_agent, prompt_agent, wait_agent, send_text, send_keys, run_command, split_pane, close_pane. The plural/singular list_* vs get_ is conventional and predictable, and there are no mixed casing or random names.
Tool Count5/5
14 tools is a well-scoped number for a terminal/agent-orchestration server. Each tool covers a meaningful operation without excessive redundancy or an overwhelming surface.
Completeness4/5
The surface covers orientation, reading output, sending input and keys, running commands, waiting for output/agent state, splitting panes, and closing panes—so core workflows are solid. The main gap is that there is no explicit way to create a new workspace or tab, only split an existing pane, which limits some session-management scenarios.
Average 4.3/5 across 14 of 14 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It does explicitly warn that the process running in the pane will also be closed, which is valuable for a destructive action. However, it does not mention that the pane is permanently removed, that unsaved process state may be lost, or what happens if the pane ID is invalid.
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 clauses with no filler: the action comes first, the side effect second, and the parameter format last. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool, the description is mostly sufficient to invoke it, and an output schema is present so return values need not be explained. However, the destructive permanence is not explicitly stated, and there is no guidance about verifying the pane before closing it. An agent could infer it, but the definition leaves that behavioral gap open.
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 only states that 'pane' is a required string with no description. The description compensates well by explaining the expected format with a concrete example: `w17:p1`. This is enough for an agent to construct a valid call, though it could say how to obtain the pane ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb ('close') and resource ('pane'), and even names the key side effect: 'any process running in it'. This clearly distinguishes it from sibling tools like read_pane, split_pane, and list_panes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose close_pane over alternatives, when not to use it, or what to do first, such as listing panes to get a valid pane ID. The agent must infer intended use from the name and the single sentence.
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 adds useful behavioral details: keys are sent in order, and `esc` represents Escape. It does not explain what happens on invalid pane ids, whether key presses are delivered to a focused session, or the success/failure behavior, but the core behavior is transparent enough for a simple input 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 short, focused, and front-loads the purpose while providing only the essential supplementary usage details. Every sentence earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two required parameters and an output schema already present, the description is mostly complete for calling the tool. It covers the main user needs: what it does, how to specify the target pane, and how to express keys. The main remaining gap is not mentioning how this differs from send_text or run_command beyond the explicit 'key presses' wording.
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 provides only names and types, so the description must compensate and does so well. It clarifies the expected pane format with `w17:p1`, provides key examples, and clarifies ordering and the representation of Escape. Missing details are the expansion of key syntax or possible key names, but the examples give sufficient grounding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and target: send key presses to a pane, with concrete examples such as ["enter"], ["esc"], ["ctrl-c"]. It is distinct from siblings like send_text or run_command because it specifically covers keyboard keys rather than text or command execution, though it does not explicitly name those alternatives.
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 includes practical guidance on how to specify pane ids and that keys are sent in order. However, it does not explicitly state when to prefer this tool over alternatives such as send_text or run_command, leaving the selection criteria implicit.
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?
There are no annotations, so the description carries the behavioral disclosure burden. It clearly conveys the non-mutating listing nature, the scope ('across the session'), and the tab id format (`a``w17:t1`), which helps agents reason about the return values. It does not hint at any side effects or require deeper behavioral warnings for such a simple read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two short sentences, with the primary purpose in the first sentence and a practical output detail in the second. There is no fluff, and every sentence serves a clear role in helping an agent understand the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool that also has an output schema available, the description is essentially complete. It tells the agent what action to perform, the scope to expect, and the shape of the returned tab identifiers. There is no missing information needed to 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 tool has zero parameters and the input schema is empty, so there are no parameters for the description to explain. The schema_description_coverage is vacuous 100%, which gives a baseline of 4; the description's tab id format is unrelated to input semantics but adds output 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 states the action clearly: 'List tabs across the session'. It identifies the exact resource (tabs) and a session scope, which helps distinguish this from sibling tools like list_panes and list_workspaces. However, it does not explicitly call out the alternative tools or the distinction, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used when you need the list of tabs in the current session, and the session scoping provides useful context. It gives no explicit when-to-use versus alternatives guidance and does not mention list_panes, list_workspaces, or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and it does disclose the return value and parameter semantics. However, it does not mention the mutating effect of splitting, potential side effects on the pane tree, or failure behavior, leaving part of the behavioral story untold.
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 main action and return type are front-loaded, followed by three compact parameter lines. Every sentence earns its place; there is no redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no nested objects and an output schema already present, the description is nearly complete. It covers the operation, return value, and all parameter semantics. Minor gaps include prerequisites and side effects, but the core knowledge needed to invoke it correctly is present.
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 0%, so the description fully compensates. It explains the pane id format, the allowed direction values ('right or down'), and the ratio meaning with a range ('fraction of the split given to the new pane, between 0 and 1'). This goes well beyond the schema's bare types and defaults.
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?
States a specific action and resource ('Split a pane') and the key outcome ('return the new pane's id'). This clearly distinguishes it from sibling tools like read_pane, close_pane, and list_panes without restating the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The operation itself makes the primary use case clear, but the description does not explicitly mention when to use this tool over alternatives or when not to use it. No exclusions or routing hints are provided relative to the sibling pane tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full semantic burden. 'show current state' makes it a read-only inspection and rules out mutation implicitly, but it does not describe behavior on missing/unknown targets or any guarantees about freshness. This is acceptable for a simple snapshot recipe, but not, not a rich behavioral contract.
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 padding: one states the opersion and second captures the only parameter's meaning and source. It is fully front-loaded and easy to process.
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 one required string parameter with an output schema available, this is largely complete: the description tells what the tool returns, what target looks like, and where to get targets. It does not mention error behavior for invalid/missing targets, but this is a minor gap given how simple the call is.
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 only says 'target' and is a string, with 0% schema coverage, so the description must compensate. It does that by giving an example format and by instructing the agent to use list_agents to obtain valid values. The exact syntax for agent names is not specified, but the user is pointed at the source.
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 journalist states a specific verb and object: 'show' one agent's 'current state', and scopes it to a single agent. This distinguishes it from list_agents (all agents) and from control tools like pitch_agent/wait_agent.
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?
Context is clear: an agent can be referenced by a pane id like w17:p1 or by agent name, and targets should be source from list_agents. It does not explicitly add 'when not to use this' against alternatives, but the pointed source makes the usage context obvious.
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 appropriately carries disclosure: it declares it returns a list of agent panes with agent kind and status, enumerates the status values, and explains how agents are addressed. It does not describe the exact output shape, but an output schema exists to cover that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, leading with the main purpose and then delivering status enumeration and addressing details. Every sentence adds useful information with no unnecessary 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 listing tool, the description covers the essential context: what is listed, what fields are returned, what status values may appear, and how agents can be identified. The output schema covers the return structure, so the definition is sufficient for an agent to select and use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters and schema description coverage is 100%, so no parameter-level compensation is necessary. The description usefully adds the addressing convention for agents (pane ID or agent name), which informs how results are referenced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb ('List') and the exact resource subset: panes running a detected coding agent. It also states the included detail fields (agent kind and status), fully distinguishing this from sibling tools like list_panes or list_tabs.
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 clear context about what the tool returns and the status values, so an agent knows the basic use case. However, it does not explicitly name alternatives or explain when to use get_agent versus list_agents versus list_panes, leaving some routing to inference.
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 indicates a read-only enumeration operation by using 'List every pane,' and it adds meaningful context about the id format that an agent must know. It does not discuss ordering or completeness guarantees, but for a simple listing tool this disclosure is solid.
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 tightly scoped sentences. The first states exactly what is returned, and the second adds the essential id format needed to use other pane tools. No filler or redundant wording.
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-argument listing tool with an output schema, the description is perfectly adequate. It tells the agent what to call, what it will get, and how to recognize pane ids for later calls. Nothing essential 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 tool accepts zero parameters, so schema describes everything. The description's enumeration of returned fields is useful context for the agent, but not required for parameter understanding. Baseline 4 for a zero-parameter tool is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('every pane') while enumerating the exact fields returned: id, workspace, tab, cwd, title, and agent status. This cleanly distinguishes list_panes from sibling tools like list_tabs and list_workspaces.
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 second sentence — 'Pane ids ... are the target of every pane tool' — implies that list_panes should be used to discover pane ids before targeting other pane-tools. However, it does not explicitly state when to use this tool versus alternatives, so the guidance remains 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?
With no annotations provided, the description carries the full behavioral burden. It discloses the key behavior — no Enter key is pressed — and clarifies that the text is sent literally. It doesn't mention output or side effects, but for a simple text-send operation these are less critical.
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 core function, then gives parameter guidance and an alternative. There is no irrelevant filler and all information 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 two-parameter tool, this description is largely complete. It gives the pane format, explains the behavior, and points to the main alternative. The only minor gap is that it doesn't explicitly differentiate from send_keys, but the term 'literal text' conveys which use case this tool serves.
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 provides an explicit format example for pane ('like `w17:p1`') and clarifies the text parameter as 'literal text'. This adds meaningful 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 states a specific action ('Send literal text to a pane') and explicitly distinguishes it from run_command by noting that it does not press Enter. This is immediately clear and separates it from its closest functional sibling.
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 usage direction: use send_text for literal text without Enter, and use run_command when a command and Enter are intended. It doesn't explicitly contrast with send_keys, but the distinction from run_command is enough to guide most calls.
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?
There are no annotations, so the description carries the full burden. It describes the waiting behavior, the default state set, and the critical timeout-failure behavior. It does not say whether it is polling, blocking, or what side effects it has, but for a wait primitive the disclosed behavior is reasonably complete.
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 three short bullet-style lines, and each line contributes critical parameter semantics. The core behavior is first, followed by the three parameters, making it easy for an agent to parse in one pass.
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 a simple wait primitive, an output schema exists, and the description covers all needed behavioral and state information: target identity, acceptable states, defaults, and timeout failure. Nothing required for correct invocation is missing, aside from forwarding to wait_for_output, which is handled more in usage guidance.
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?
The schema provides only parameter names, types, and defaults, with no descriptions, while schema description coverage is 0%. The description compensates fully by explaining target as-Id or agent name, the allowed until values with a default, and the meaning of timeout_ms. This adds substantial value 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 a specific verb ('Wait') and resource ('an agent reaches one of the requested states'), and distinguishes itself from wait_for_output because it targets agent state, not command output. Including a small state vocabulary makes the resource unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied through 'target' being an agent or agent pane and 'until' being an agent status, but there is no explicit statement of when to use this tool versus wait_for_output or another sibling. It is sufficient for an agent to infer the likely usage, yet it lacks explicit when-to-use/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?
Because no annotations are provided, the description itself must disclose how the tool behaves, and it does: the existing snapshot is searched first, then it polls until timeout. It also explains regex versus literal matching. It does not describe error behavior when timeout elapses or how recent-unwrapped differs from recent, which is a mild transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the main behavior, and each line adds a meaningful piece of information for a parameter or option. There is no redundant or filler 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?
For a polling/search tool with an output schema and five parameters, the description covers purpose, pattern semantics, source selection, search order, and timeout. The main residual gap is the meaning of recent-unwrapped and what happens when the wait times out, but nothing blocks a competent agent from selecting and invoking 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 input schema provides property names and defaults but no descriptions, so coverage is 0%. The description compensates by explaining pane id format, pattern semantics, regex behavior, source choices, and timeout usage. The timeout_ms explanation is thinner than the others, relying on the schema default for full meaning, so it is useful but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: wait for a pane's output to match a pattern. It clearly communicates the tool's synchronous, polling nature and distinguishes it from siblings like read_pane, which would only inspect the current snapshot, and wait_agent, which waits on an agent rather than 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 gives practical usage context, including the order of operations, expected pattern syntax, source options, and timeout behavior. It does not explicitly name alternatives like read_pane or wait_agent for contrast, so it stops short of full when-to-use/when-not-to-use guidance, but an agent can infer the right situation clearly.
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 states the operation is a read/list action, indicates the output includes aggregate status, and gives a concrete ID format expectation (`w17`). It does not mention pagination, but the presence of an output schema reduces the need for that detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two brief sentences with no fluff. The main listing semantics are front-loaded, and the structural ID convention is added in the second sentence.
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-argument, read-only listing tool with an output schema, the description is complete: it covers what the tool returns, the form of identifiers, and when to use it. Nothing needed to invoke it correctly 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 tool has zero parameters, so there are no input semantics to document. This is the baseline strong score for a no-argument tool; the description correctly focuses on the output and orientation value instead.
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 names the exact resource ('List Herdr workspaces') and the precise returned contents: ids, labels, and aggregate agent status. This cleanly separates it from sibling tools like list_tabs, list_panes, and list_agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Start here to orient in the session' gives an explicit when-to-call directive. It does not list alternatives or when-not-to-use conditions, but for an orientation-level listing tool that is a minor omission.
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 behavioral burden. It explains that the tool types and submits text, optionally waits for the agent to settle, and fails if nothing matches within the timeout. It does not cover side effects or preconditions like whether the agent pane needs focus, but the disclosed behavior 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?
The description is front-loaded with the core action, then uses a compact parameter-list format. Every sentence adds information and there is no repeated schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no annotations, and no schema descriptions, the description explains the key semantics and failure behavior well enough to invoke the tool correctly. Minor gaps remain around explicit differentiation from sibling tools and any requirements like active pane or agent ordering, but the core usage is complete.
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 0%, and the description compensates fully. It explains `target` with examples, `wait` with a concrete definition of settled states, and `timeout_ms` with its caveat that it is only used when `wait=True`. Even `text` is clarified as the prompt being submitted.
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 ('submit a prompt') and the resource ('an agent pane'), and clarifies the mechanism ('types the text and submits it'). This distinguishes it from sibling tools like send_text or send_keys, which only send keystrokes without submitting.
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 targeting context: pane IDs like `w17:p1` or agent names, and points to `list_agents` for discovery. It also explains when `wait` and `timeout_ms` matter. However, it does not explicitly say when to prefer this over siblings like `wait_agent` or `send_text`.
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 transparency burden. It does well by disclosing an important edge case: herdr may return an empty string for source=recent with lines on short-scrollback panes, and suggests a retry strategy. This is genuine behavioral context beyond what the schema could convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loads the core purpose, and each subsequent part covers one meaningful detail. There is no filler, and the edge-case note is worth the space.
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 moderate complexity, the definition is complete: it identifies the target, covers all parameters, defines the source variants, and explains failure behavior. The caveat about empty results is especially useful for an agent deciding how to invoke or retry the operation.
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 0%, but the description fully compensates by explaining all three parameters: pane format with example, lines meaning, and the semantics of every source value. This gives an agent everything needed to construct valid arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Read a pane's terminal output as plain text.' This clearly distinguishes read_pane from sibling tools like list_panes or get_agent, which serve different purposes.
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 contextual guidance, including how to identify a pane via list_panes/list_agents, when to use lines, and what each source value means. It does not explicitly say 'use this instead of X,' but the usage context is strong and no misleading exclusions are 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?
There are no annotations, so the description carries the burden of disclosing behavior. It does so well by noting the command is just sent as text plus Enter and that run_command does not wait for completion. It could add more on side effects, pane validity, or failure modes, but the no-wait disambiguation is the most important behavior and is present.
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 wording is compact and front-loaded: action, target, then parameter examples, then non-block behavior and follow-up. There is no filler or repeated schema information.
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 only two parameters and an output schema, the description covers invocation semantics, parameter formats, async behavior, and next steps. Any remaining return-value detail belongs to the output schema, so this is materially complete for agent call selection.
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 0%, so the description must compensate, and it does: pane is given a concrete id format such as w17:p1, and command is explained as argv-style words with the example ["git", "status"]. Both required parameters are covered with format and intent.
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 opening sentence clearly names the verb, resource, and semantics: 'Run a shell command in a pane (sends the command text and Enter).' It also distinguishes the tool from waiting/reading tools by explicitly stating that it does not wait and pointing to wait_for_output or read_pane as follow-ups.
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 tells the agent to use wait_for_output or read_pane afterwards, which is clear behavioral guidance. However, it never contrasts this tool with sibling tools send_text or send_keys, so it stops short of fully explaining when shell execution is preferable to raw text input.
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:

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

Score Badge

Copy to your README.md:

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

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