zeros-mcp

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 purposes: set_ commands target different parameters, get_ commands retrieve different information, and playback controls are separated by action (pause, release, view, level). The only potential overlap is between fire_cue and go_cue, but the descriptions clarify that one runs a specific cue while the other advances to the next cue.
Naming Consistency4/5
Tool names follow a consistent verb_noun pattern with useful prefixes (set_, get_, fire_). Minor deviations exist, such as go_cue versus fire_cue and pause_playback/release_playback/view_playback, but the overall naming is predictable and readable.
Tool Count5/5
With 12 tools, the server is well-scoped for controlling a lighting console. It covers cue firing, playback management, levels, blackout, macros, and diagnostics without unnecessary bloat.
Completeness4/5
The set covers the essential live-control operations (cues, playbacks, grand master, blackout, macros) plus useful diagnostics. The main gap is the inability to read console state—only command history is available—but this is a documented protocol limitation, so it's an acceptable minor gap.
Average 4.2/5 across 12 of 12 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the basic effect, without disclosing error behavior, idempotency, or side effects on playback status. For a mutation-like control tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with zero wasted words. It is front-loaded with the action and effectively communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema present), the description is adequate for the core function but lacks edge-case context (e.g., what happens if no fade is running). It does not need to explain return values due to the output schema, so this is a reasonable middle ground.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema's description of the 'playback' parameter is detailed (e.g., 'Omit to pause the console's current playback'). The tool description adds no extra parameter information, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Pauses a running fade' clearly identifies the action (pauses) and the resource (a running fade). This distinguishes it from sibling tools like release_playback (which releases) and fire_cue (which initiates cues). The word 'fade' adds specificity beyond the tool name, making its function 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 description implies usage when a fade is running, but it does not explicitly state when to use this tool versus alternatives (e.g., release_playback), nor does it mention what happens if no fade is running. This falls between 'implied usage' and 'no 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, the description carries the burden. It states the core action and adds a useful behavioral detail about sending '1'/'0' spellings. However, it does not mention any side effects, reversibility, or what blackout means for the rig output beyond the schema parameter description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is remarkably concise: one clear main sentence and one clarifying sentence about argument handling. Every sentence earns its place, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter boolean setter, the description combined with the schema and output schema is nearly complete. It lacks only broader usage guidance or notes about interaction with other console states, but these are not critical for such a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single boolean parameter is well described in the schema ('True to black out the rig, False to restore it'). The description's note about accepted spellings adds peripheral context but does not enhance the semantic meaning of the parameter itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action: 'Turns the console's blackout on or off.' It uses a specific verb and resource, and this tool is distinct from all siblings (which handle macros, cues, playbacks, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, or about any prerequisites or exclusions. The description simply states what it does, leaving usage context entirely 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 burden. It discloses a specific behavioral quirk (playback-qualified address ignored on FLX S48) and provides a workaround, which goes beyond the schema. It does not mention side effects or permissions, but the disclosed quirk is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the core purpose in the first sentence. The anecdote about the FLX S48 user adds credibility but is slightly verbose; still, it earns its place by providing concrete troubleshooting advice.
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 simple 2-parameter tool and the presence of an output schema, the description covers the key behavior and a notable exception. It doesn't explain return values, but the output schema covers that. The description is sufficient for an agent to use 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 schema already describes both parameters well, but the description adds meaningful context about the playback parameter, explaining that omitting it can be more reliable in certain cases. This goes beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fires a specific cue, using a specific verb and resource. It also mentions the cue-only form and its utility, but does not explicitly differentiate from sibling tools like go_cue or set_pending_cue, so it lacks sibling distinction.
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 practical guidance on when to omit the playback parameter, suggesting a fallback for when a cue won't fire. However, it does not explicitly state when to use this tool over alternatives, leaving the usage context 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.
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 clearly states that the tool can black out a show and advises confirmation during performance, which is valuable risk-related context. It does not describe return values or persistence, but the output schema exists and the warning covers the most critical behavioral trait.
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 with the purpose stated first, followed by a crucial safety note. Every sentence earns its place and no words are wasted.
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 setter with a complete output schema, the description adequately covers the tool's purpose and the most important behavioral caveat (blackout risk). It could mention prerequisites like connection state or that the effect applies globally, but the existing content is sufficient for an agent to invoke it safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for both 'level' and 'fade_seconds', including the default and meaning of null. The description adds 'optionally fading' which aligns with fade_seconds but does not add new meaning beyond the schema. Thus the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Sets the grand master level') and immediately clarifies its unique scope ('scales the entire rig'). This distinguishes it from sibling tools like set_playback_level and set_blackout by highlighting its master-level impact.
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 a caution ('Confirm before sending it during a performance') but gives no explicit guidance on when to use this tool versus alternatives like set_blackout or set_playback_level. The usage context is implied by the name and the risk warning, but no positive or negative selection criteria are offered.
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 explains the primary effect (channels returned to the stack below), which is valuable, but it does not mention any side effects, prerequisites, or error conditions (e.g., what happens if the playback is not running). The behavior is not fully transparent, but the core action is 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 single, well-structured sentence that immediately states the action and its consequence. There is no wasted language or repetition, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, output schema present), the description provides sufficient coverage of purpose and core behavior. It could be more complete by explicitly addressing when to use this over pause_playback, but the existing context is adequate for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides exhaustive documentation for the single parameter, including its default value (null) and the meaning of 0 (Master Playback). Since schema description coverage is 100%, the description adds nothing beyond the schema, matching the baseline of 3.
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 ("releases") with a clear resource ("playback") and immediately distinguishes the action by explaining the consequence ("returning the channels it holds to the stack below"). This clearly differentiates it from sibling tools like pause_playback or view_playback.
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: it describes the core behavior of releasing a playback and freeing its channels, implying it is appropriate when a playback no longer needs to hold channels. However, it does not explicitly state when not to use it or name alternatives, such as using pause_playback to temporarily hold channels.
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 were provided, so the description carries the full burden. It discloses important behavioral nuance: the server cannot know which playback is active when playback is omitted. This adds valuable context about potential ambiguity. It does not discuss side effects or reversibility, but for a simple Go action this is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core action, the second provides a concise caveat about playback selection. It is front-loaded, efficient, and free of 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 one optional parameter and an output schema, the description is quite complete. It covers the main behavior and the key edge case of omitted playback. It does not describe return values, but that is not required when an output schema exists. Minor gaps like error handling are not critical for this simple action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% coverage for the single parameter. The description enhances the schema by explaining why omitting playback is risky and that providing it is safer. This adds meaningful context beyond the structured definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Presses Go, advancing to the next cue.' This is a specific verb and resource. It does not explicitly name sibling tools to differentiate, but the action of pressing Go to advance to the next cue is distinct from sibling tools like fire_cue, which likely targets a specific cue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance for the playback parameter: when omitted, it uses the console's current active playback, and it recommends naming the playback as the safer choice. It does not, however, discuss when to choose this tool over siblings like fire_cue.
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 for behavioral disclosure. It clearly states the key behavior: the tool does NOT fire the cue (critical to distinguish from go_cue/fire_cue). It also explains the 'standby' concept and the intended workflow. However, it does not mention edge cases like invalid cue numbers, overwriting of current pending cue, or any limitations, which would make it fully transparent. The core behavior is well covered, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—two sentences—and front-loaded with the core purpose. Every sentence adds value: the first states what it does, the second explains when/how to use it. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the schema's richness, and the presence of an output schema, the description is largely complete. It explains the setting, the non-firing behavior, and the intended sequence with go_cue. However, since there are no annotations and no explicit mention of when to prefer this over fire_cue or go_cue, a small gap remains. For a simple tool, this is nearly complete, so a 4 is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage, with clear parameter details (e.g., cue supports point cues, playback defaults to null and references the master playback). The tool description itself adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Sets which cue is next, without firing it.' This is a specific verb and resource, and the phrase 'without firing it' distinguishes it from fire_cue and go_cue. The reference to ZerOS's 'Next' command adds helpful domain context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: use it to 'jump the standby cue somewhere else in the stack, then `go_cue` to run it.' This implicitly contrasts with immediate-firing tools and names go_cue as the follow-up action. However, it does not explicitly mention alternatives like fire_cue or when not to use the tool, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The explicit statement that it changes only the operator's view and 'nothing about the lighting output' is a valuable, transparent side-effect guarantee. It does not disclose additional behavior like whether it persists or resets selection, but for a simple view tool 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?
Two compact sentences: the first states the action, the second preemptively eliminates a common misconception about side effects. Every word adds value, and the structure is front-loaded with the primary purpose.
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 one parameter, an output schema, and no annotations, the description adequately covers what the tool does and its non-effect on lighting output. The parameter is well-documented in the schema, and the description resolves the critical ambiguity about whether this alters lighting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single parameter (playback integer, with an example that Master Playback is 0), giving 100% coverage. The description adds no parameter-specific details beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Brings a playback into view') and the target resource ('on the console's screen'), clearly distinguishing it from siblings by explicitly noting it changes nothing about lighting output. This differentiates it from tools like set_playback_level or go_cue that affect lighting.
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: this is for viewing/selecting a playback without affecting the lighting output. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of the highest bar but offers strong implied usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a critical behavioral nuance: omitting fade_seconds uses the playback's own raise/lower times, resulting in a moving not snapping change. This is valuable beyond the schema. It does not discuss side effects or permissions, but the most surprising behavior is highlighted, so a 4 is warranted.
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 and front-loaded. The first sentence states the core purpose; the second paragraph is a focused warning. Every sentence carries useful information with no redundancy or fluff. It is well structured for quick parsing.
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, the schema coverage, and the presence of an output schema, the description is largely complete. It explains the essential behavior and parameters. The only gap is the absence of explicit guidance on when to choose this tool over siblings, but this is a minor omission given how distinct the tool's purpose 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 input schema covers 100% of parameters, so the baseline is 3. The description adds significant semantic value by clarifying that omitting fade_seconds is not equivalent to a zero-second fade and explicitly advises passing 0 for an instant change. This goes beyond the schema's 'Omit to use the playback's raise/lower time' by emphasizing the practical implication.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (sets) and resource (a playback's fader level), and adds the optional fading capability. This distinguishes it from sibling tools like set_grand_master or fire_cue, which target different controls. The scope 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 clear operational context: set a playback's fader level with optional fade. It includes important guidance on the distinction between omitting fade_seconds and passing 0, which affects behavior. However, it does not explicitly mention when to use this tool over siblings or mention exclusions, 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 fully discloses the critical behavioral limitation: the macro's behavior is opaque to the server, and the number provides no meaningful info about its effect. This prevents the agent from making incorrect assumptions.
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 concise sentences: the first states the core purpose, the second adds an essential caveat. No wasted words, and the key information 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?
The tool is simple with one parameter and an output schema exists, so the description does not need to explain return values. It covers the essential operational detail (opaque macro contents) and gives practical advice for the agent, making it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single parameter ('User macro number as stored on the desk'). The description adds no additional semantic detail about the number beyond what schema provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Runs a user macro stored on the console') with a specific verb and resource. It distinguishes itself from sibling tools (e.g., fire_cue) by focusing on macros.
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 on how to use the tool: since the server cannot see macro contents, the agent should ask the user what a macro does rather than guessing. This is helpful guidance, though it does not explicitly contrast with alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It excellently explains transport-dependent behavior, the limits of UDP, and the fact that a healthy link does not verify command acknowledgment—offering deep transparency about what the result means.
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 well-structured: it opens with a clear purpose, then explains transport nuances, and ends with an important caveat. Every sentence contributes value without 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?
For a zero-parameter diagnostic tool with an output schema, the description fully covers the necessary context: what the tool does, how to interpret results, and its limitations. No further details are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. The description adds useful context about interpreting results based on the transport, but there are no parameter semantics to clarify. Baseline 4 is appropriate given no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports on what can be determined about the link to the console, using a specific verb and resource. This distinguishes it from sibling tools that control playback or macros, making its diagnostic purpose evident.
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 on when the tool is reliable (TCP) and when it is not (UDP), and explicitly warns not to use it as evidence that commands were understood. While it does not name alternative tools, it gives strong situational guidance.
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 explains that entries mean messages left this machine, not that the desk received or acted on them, and warns about manual fader movements that the server wouldn't know. This reveals crucial behavioral limitations beyond a simple 'returns' 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 front-loaded with the core purpose, then uses two further paragraphs that each add essential caveats about data interpretation and usage. Every sentence earns its place without being wordy, and the structure is logical (function, meaning, guidance).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a zero-parameter tool with an output schema, the description provides all necessary context: what the data represents, its limitations, and when to use it. It sufficiently covers the semantics of the returned journal without needing to detail return fields.
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 empty schema already provides complete coverage. The description appropriately avoids inventing parameters, and no further parameter-level explanation is needed, matching the baseline 4 for parameterless tools.
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 that the tool returns this server's sent console messages, using a specific verb ('returns') and resource ('what this server has sent to the console'). It actively distinguishes this from the console's actual state, setting it apart from sibling tools that query or modify state.
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 gives explicit positive guidance ('Use it to retrace what you did') and negative guidance ('never to answer what the rig is doing'). It also clarifies that entries do not imply receipt or action, which is a clear exclusionary instruction.
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:

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

Score Badge

Copy to your README.md:

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

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