Server Quality Checklist

Tool Scores

• eos_fire_macroB
  3.1/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description simply says 'Run a saved macro' and adds no information about side effects, execution timing, or potential consequences. Annotations already mark destructiveHint: true, but the description does not elaborate on what firing a macro might do (e.g., changing show data). It adds no behavioral context beyond the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, with a clear main sentence and a bulleted argument list. Every word earns its place; there is no fluff or repetition. The structure is ideal for quick parsing by an agent.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive, open-world tool with no output schema, the description is insufficient. It does not explain what happens when the macro is fired, whether the operation is synchronous, what errors might occur, or how the result is reported. The annotations give a hint of destructiveness but the description does not prepare the agent for the broader impact on the lighting state.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description lists 'macro_number (number): Macro to fire,' which is nearly tautological with the parameter name. The schema already defines the integer type and bounds (1-127). With 0% schema description coverage, the description provides only a minimal label and does not explain how the number maps to a saved macro or what 'fire' entails.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Run a saved macro by number (1-127).' The verb 'run' and resource 'saved macro' are specific, and the number range adds precision. This distinguishes it from siblings like eos_fire_cue and eos_go, which target different objects.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives, no prerequisites (e.g., macro must exist), and no context such as whether this should be used for command-line triggers or manual actions. It is a bare instruction without usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• eos_fire_cueA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds important behavioral context beyond annotations by disclosing that return means the OSC message was sent, not that the cue finished, and that Eos provides no synchronous acknowledgement. This is significant because the tool is marked destructive/readOnly=false, and the async caveat helps set correct expectations.

  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 front-loaded with the main purpose, then organized into Args, Returns, and Example sections. It is concise and every section contributes useful information, though the Args section somewhat duplicates the schema.

  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 two-parameter tool, the description is complete: it explains the action, its sequencing flexibility, the return value, the asynchronous nature, suggests a follow-up tool, and provides an example. Given the schema and annotations, no critical context is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers both parameters thoroughly, including examples for cue_number. The description largely repeats this information, adding only the 'numbered part' clarification and a worked example, which is marginal value over the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses the specific verb 'Fire' with the resource 'specific cue' and clarifies that it works 'regardless of playback sequence,' which differentiates it from sequential tools like eos_go or selection tools like eos_select_cue. It clearly states what the tool does and its distinctive out-of-order capability.

  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 notes when to use the tool ('works even if it's out of order') and recommends eos_get_status afterward to verify playback position. It does not explicitly name alternatives like eos_go for sequential playback, so it lacks full exclusion guidance, but the context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• eos_goA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false. The description adds that it advances sequentially, which is useful context, but doesn't disclose additional behavioral details beyond what annotations already convey. No contradiction exists.

  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 plus a bullet, front-loaded with the action and purpose. No wasted words; every sentence earns its place, including the sibling comparison.

  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 simplicity (one optional parameter, clear annotations, no output schema), the description is complete. It covers the action, the norm of use, the alternative, and the parameter semantics adequately.

  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 description's arg bullet mirrors the schema exactly ('Cue list to advance. Omit to press Go on the default/active cue list.' vs schema's 'Cue list to advance; omit for the active list'). No additional semantic value is added.

  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: 'Press the [Go] button on a cue list, advancing to the next cue in sequence.' It specifies the exact verb and resource, and distinguishes itself from eos_fire_cue by contrasting sequential advancement with jumping to an arbitrary cue.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly says when to use this tool (the normal way a show runs) and contrasts it with eos_fire_cue which jumps out of order. This gives clear guidance on when to choose this over an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• eos_nudge_wheelA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate non-read-only, non-idempotent, and non-destructive. The description adds behavioral context beyond these: relative ticks, fine/coarse mode, prerequisite channel selection, and magnitude guidance. It doesn't cover return values or edge cases but sufficiently enriches the annotation-provided profile.

  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?

  Well-structured with a concise opening sentence and a labeled Args list. It front-loads the core purpose and then neatly explains parameters. It repeats some schema descriptions, but this is not detrimental. Size is appropriate for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 3-parameter command with no output schema, the description covers functionality, prerequisites, parameter semantics, and usage context. Missing return value and edge-case behavior (e.g., 'no channel selected'), but the core information is complete enough for an OSC simulation tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers all 3 parameters with descriptions, so baseline is 3. The description adds extra value by giving examples ('pan'), magnitude guidance ('~1 for fine nudges, ~5-10 for bigger moves'), and clarifying the omission behavior for intensity/level. This goes beyond schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states it simulates turning an encoder wheel by a relative number of ticks for the currently selected channel/parameter. It distinguishes itself from absolute-value tools by explicitly noting 'rather than jumping to an absolute value' and referencing the prerequisite eos_select_channel tool, separating it from siblings like eos_set_parameter.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context: 'useful for live "nudge it a bit" adjustments' and the prerequisite 'use eos_select_channel first.' It implies when to use relative nudging over absolute setting but does not explicitly name alternative tools, so it stops short of a full when/when-not list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• eos_set_faderA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already convey read-only false, idempotent, non-destructive, and open-world. The description adds the precondition that the bank must exist and mentions a one-time session setup, giving useful session-level context. It does not contradict the annotations and adds value beyond the structured hints.

  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 front-loaded with a clear purpose sentence and then a structured Args list. The prerequisite note is valuable. It is slightly verbose with the parenthetical 'it only needs to be done once per session,' but that is relevant. Overall, it is efficiently organized.

  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 3-number tool with no output schema, the description covers the essential context: purpose, prerequisites, and parameter meanings. The only notable gap is that fader_index's base (1-based vs 0-based) is not explicitly stated, but the inclusion of the master fader hint and the bank creation workflow makes it mostly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is only 33% (only level has a schema description). The description compensates by documenting all three parameters, including bank_index's 1-based indexing and 0-for-master special case, fader_index's meaning as a position, and level's range. This adds meaning beyond the schema, though fader_index could be more explicit about its base.

  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: "Set a fader in an OSC fader bank to a level." This clearly states the action and target, distinguishing it from siblings like eos_set_channel_level (channels vs faders) and eos_configure_fader_bank (creation vs setting).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states a prerequisite and alternative: "Requires the bank to already exist on the console (call eos_configure_fader_bank first if you haven't created bank_index yet)." It also gives a special-case instruction for the master fader (use 0). This provides clear context, though it doesn't explicitly discuss when not to use this tool relative to other fader-related commands.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• eos_set_parameterA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotency and non-destructiveness. The description adds valuable behavioral context, such as value ranges depending on the parameter (degrees for pan/tilt, 0-100 for colors) and the encoder-dialing equivalence. This goes beyond the structured data, though it does not detail potential side effects or error cases.

  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 well-structured with an introductory sentence, a clear Args list, and a concrete example. It is slightly longer than necessary but every sentence serves a purpose. The example adds practical clarity without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a three-parameter tool with no output schema, the description provides adequate context: purpose, parameter meanings, range behavior, and an example. It lacks explicit error-handling or return-value information, but this is minor given the tool's simplicity. Overall, it is complete enough for an agent to select and invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 67%, leaving 'channel' undocumented. The description compensates by explaining the parameter name format and giving explicit examples for each argument. It also adds range dependency information for 'value', which is absent from the schema. This meaningfully enhances parameter understanding beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Set') and resource ('non-intensity parameter') with clear scope ('to an absolute value for a specific channel'). It explicitly differentiates from siblings by stating 'non-intensity' and 'absolute value', contrasting with relative adjustments like eos_nudge_wheel. The example further concretizes the purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates this tool is for non-intensity parameters (pan, tilt, color) rather than intensity, which implies not using eos_set_channel_level. It also specifies 'absolute value' versus relative nudge, giving clear context. However, it does not explicitly name alternative tools or list explicit when-not-to-use conditions, 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.

• eos_select_cueA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond these by explaining the 'without firing it' behavior and the inspect/edit use case, clarifying that no cue is activated. It complements rather than contradicts the annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences plus a compact arg list. It is front-loaded with the core behavior, then usage guidance, then parameters. Every word earns its place with no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple selection tool with strong annotations, the description is complete. It covers purpose, side-effect behavior, usage context, and parameter meanings. No output schema is present, but none is needed for this operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries the burden. It provides basic meaning for both parameters ('Cue list number', 'Cue number to select'), but this largely restates the parameter names. Additional format details (e.g., why cue_number is a string, allowing decimals) would have been more informative.

  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 the specific verb 'Select' with a clear resource ('a cue') and scoping ('on the command line without firing it'). This distinguishes it from sibling tools like eos_fire_cue, eos_go, and others, making the tool's purpose immediately understandable.

  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?

  Explicitly states when to use: 'useful before eos_record_cue-style raw edits, or to inspect a cue before running it.' This gives concrete context and implies exclusions (e.g., not for firing cues), making the appropriate invocation scenario clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• eos_configure_fader_bankA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare idempotency and non-destructiveness; the description adds valuable context beyond that, such as the 'Must be called once' prerequisite, the 're-page' behavior, and the fact that bank_index is independent of console fader numbers. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded with the core purpose, followed by a clear prerequisite statement and a well-formatted Args section. No redundancy or unnecessary detail.

  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 simplicity (3 params, no output schema) and the existing annotations covering safety and idempotency, the description covers all essential aspects: purpose, prerequisites, parameter explanations, and repeated-use behavior. It is complete for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With schema description coverage at 0%, the description fully compensates by documenting each parameter: bank_index (1-based, custom numbering), fader_count (how many faders), and page (optional, defaults to page 1). This adds meaningful semantics beyond the raw schema types and constraints.

  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: 'Create (or re-page) an OSC fader bank so eos_set_fader can address it.' This specifies the verb, resource, and purpose, and distinctly connects to a sibling tool (eos_set_fader), making it unique among the listed siblings.

  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 prerequisites ('Must be called once before using a given bank_index') and explains repeated use ('Safe to call again to jump pages'). While it doesn't explicitly exclude alternatives, the context of being a required setup step for eos_set_fader gives sufficient usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• eos_select_channelA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark read-only/idempotent, but description adds that selection is a persistent command-line state and explicitly states no level change. This clarifies side-effect-free behavior beyond the hints.

  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 action, then gives usage direction and an argument list. No redundant sentences.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter, no-output tool, description plus annotations fully cover purpose, usage, and side effects. Sibling references provide adequate context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description only restates 'channel (number): Channel number to select,' which duplicates the schema's integer type and minimum. It adds no behavioral meaning like what the channel number refers to or how selection manifests.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description uses specific verb 'Select' and states scope: 'a channel on the command line without changing its level,' clearly distinguishing from level-setting tools like eos_set_channel_level. The resource and action are unambiguous.

  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?

  Explicitly instructs to use before eos_adjust_parameter or eos_nudge_wheel, explaining these act on 'whatever is currently selected.' This names specific sibling alternatives and defines the prerequisite context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• eos_get_statusA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description enriches the annotations (readOnlyHint, idempotentHint, etc.) with important behavioral details: the asynchronous/non-live nature, session-scoped buffering, and the meaning of an empty array (including a troubleshooting hint about OSC TX connectivity). This goes significantly beyond what annotations alone 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 well-structured: a one-sentence purpose statement, a two-sentence usage caveat, and clearly labeled Args/Returns sections. Every sentence contributes meaningful information, with no filler or repetition of schema details.

  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 simplicity (read-only, 2 optional params, no output schema), the description covers everything needed: what it does, when to use it, parameter semantics, return format, and how to interpret empty results. The troubleshooting note about OSC TX adds completeness that the annotations cannot provide.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description adds practical meaning to both parameters: filter with substring examples and the "Omit for everything" behavior, and limit with "most recent last" ordering plus the default (which matches the schema). The schema already documents filter and limit's default/range, but the description clarifies usage semantics and return-order expectations.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: "Read back recent OSC feedback Eos has sent," with concrete examples (active cue, command line text, live/blind state). This clearly distinguishes it from the sibling tools, which are all control/action tools (e.g., eos_fire_cue, eos_go, eos_set_channel_level) rather than status reads.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  States a clear usage context: Eos pushes asynchronously, so the tool returns whatever has arrived so far and should be called shortly after an action to see the effect. While it doesn't explicitly describe alternatives, the sibling list contains no competing read-status tool, making the intended use unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• eos_set_channel_levelA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds important behavioral context beyond the annotations: it affects Live output immediately and is not automatically recorded into a cue. This complements the readOnlyHint=false and idempotentHint=true annotations, providing the agent with critical side-effect information that structured data alone does not 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 concise and well-structured: a clear one-sentence purpose, an explicit console-equivalent reference, a compact arg list, and a note about recording behavior. Every sentence contributes meaningful information with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter setter tool, the description covers all essential aspects: what it does, how parameters map, immediate live effects, and the recording caveat. With helpful annotations and no output schema requirement, the description is complete enough for an agent to invoke the tool correctly and understand its consequences.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides full coverage (100%) with descriptions for both parameters. The description adds value by including the console command equivalent ('Chan <n> At <level> Enter'), which gives semantic context for how the parameters map to real-world usage. It also clarifies that the channel parameter simultaneously selects the channel, a nuance not present in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action: 'Set a channel's intensity level directly (0-100).' It distinguishes itself from sibling tools by explicitly noting that it both selects the channel and sets the level, unlike eos_select_channel. The console command equivalence ('Chan <n> At <level> Enter') adds concrete clarity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool: when you want to set a channel's intensity directly. It explicitly addresses the alternative of recording cues by stating the set is not recorded unless eos_record_cue is separately called. However, it does not explicitly mention alternatives like eos_select_channel for selection-only scenarios, though the 'both selects and sets' phrasing partially covers this.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• eos_send_raw_commandA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (destructiveHint, openWorldHint, etc.), the description adds critical behavioral details: the command is auto-terminated with Enter, requires explicit confirmation to send, is rate-limited, and can perform any console action. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Well-structured with a brief intro, Args section, and important safety notes. Each sentence contributes meaningful information: examples, confirmation requirement, auto-Enter, destructive warnings, and rate limiting. No fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, the description covers usage, safety, limitations, and operational constraints comprehensively. It explains the preview mechanism, arbitrary capabilities, and rate limiting, making it complete for an agent to decide when and how to invoke it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage with descriptions for both params. The description adds value with example command strings, clarifies the preview vs. send behavior of confirm, and explains auto-termination. This exceeds the baseline but doesn't go into exhaustive detail on all edge cases.

  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 sends arbitrary text to the Eos command line, acting as an escape hatch. It distinguishes itself from siblings by specifying it covers anything the other tools don't, with concrete examples like patch changes and palette recording.

  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?

  Explicitly tells when to use this tool: 'Use this for anything the other tools don't cover'. It also provides guidance on the confirm flag for preview, warns about destructive commands, and mentions rate limiting, giving clear context for safe usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• eos_record_cueA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as destructive and non-read-only, but the description adds critical context beyond that: it explicitly warns that the tool OVERWRITES existing cue data with no separate confirm step, reveals that it uses the Eos command line under the hood, explains the 'Cue List Does Not Exist' error condition, and notes rate limiting. It also explains the confirm parameter's preview behavior. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is appropriately detailed for a destructive tool, yet every sentence serves a purpose: warnings, prerequisites, error handling, verification, and parameter semantics. The structure (overview, mechanism, prerequisites, args, rate limit) is logical and front-loaded with the most critical warning. No redundant 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 mutation tool with no output schema, the description is exceptionally complete. It covers the action, when to use, destructive consequences, prerequisites (existing cue list), failure modes and workarounds, post-invocation verification via eos_get_status, and rate limiting. The agent is fully equipped to invoke this tool safely and correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although the schema covers 100% of parameter descriptions, the description adds meaningful semantics: it explains that cue_list must already exist, provides cue_number format examples, clarifies that confirm must be explicitly true to execute, and describes the preview behavior when false. It also mentions rate limiting that affects parameter usage. This goes well beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Record the current live state into a cue.' It clearly distinguishes from sibling tools like eos_fire_cue (firing a cue) and eos_select_cue (selection), and explicitly names the underlying Eos command. The scope and behavior are unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit when-to-use and when-not-to-use guidance. It states the tool will overwrite existing cue data and advises double-checking cue numbers on a real rig. It also names alternatives: use eos_send_raw_command to create a cue list first or record the first cue, and use eos_get_status to verify success. This gives the agent clear decision context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.