room-eq-wizard-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose, even in dense areas like imports (file vs data vs RTA) and alignment (auto, manual, state, raw command). Escape hatches (run_measurement_command, run_alignment_command) are explicitly separated from dedicated tools, preventing misselection.
Naming Consistency4/5
The overwhelming majority follow verb_noun (list_*, create_*, import_*, get_*, run_*). A few exceptions (status, generator, arithmetic, auto_eq, room_mode_analysis) break the pattern, but they are memorable and not confusing.
Tool Count2/5
46 tools is well above the 25-tool threshold and feels heavy even for a complex REW wrapper. Many could be consolidated (e.g., import_* variants, raw command escape hatches), making the surface harder for an agent to navigate.
Completeness5/5
The tool set covers the full measurement lifecycle (create/import/load/save/delete), analysis (FR, RT60, distortion, response interpretation), EQ (auto EQ, filters, prediction), alignment, groups, SPL, and generator control. Raw command tools act as a catch-all, leaving no obvious dead ends.
Average 4/5 across 46 of 46 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for explaining side effects or safety. It implies a read-only listing via the word 'list', but it does not explicitly state that no mutations occur, nor does it explain how a 'specific measurement's commands' would work (e.g., whether a measurement ID is needed). The lack of clarity about return format and edge cases (e.g., invalid area) leaves transparency gaps.
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 efficient and front-loaded with the main action. The parenthetical list of areas is somewhat lengthy but acceptable. The second sentence provides useful context without unnecessary verbosity. No redundancy with schema because the schema does not list these examples (though it has an enum), so the examples add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with a rich schema enum and no output schema, the description covers the basic purpose and usage context. However, the problematic 'specific measurement's commands' part is not elaborated or aligned with the schema, and given the sibling tool get_measurement_commands, the description fails to clarify the boundary. This leaves the tool's overall context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear enum and description, so the baseline is 3. However, the tool description adds an extra option ('or a specific measurement's commands') that is not present in the schema enum, which actively misleads about valid parameter values. This contradicts the schema and reduces trust in the parameter semantics, so the score is lowered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists raw commands for REW endpoint areas, with a specific verb and resource. However, the inclusion of 'or a specific measurement's commands' creates ambiguity about the tool's exact scope, especially since a sibling tool (get_measurement_commands) likely covers that case. This muddles the distinction and makes the purpose less crisp.
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 gives a general guideline ('useful to discover REW capabilities not covered by a dedicated tool'), but it contradicts itself by also listing 'specific measurement's commands' as an area when a dedicated sibling tool exists for that purpose. It fails to explicitly clarify when to prefer this tool over alternatives or exclude the overlapping case, leading to potentially inappropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the core function ('List... models REW can generate filters for') but does not clarify whether this is a read-only operation, what the return format looks like, or whether any side effects exist. For a list operation, the lack of explicit read-only/disclosure is a 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, concise sentence that directly states the purpose without any filler. Every word adds value, and it is front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description provides the core meaning but omits details about the return value or typical usage context. It does not explain what the output looks like (e.g., list of strings, array of objects), but given the simplicity and rich sibling context, it is minimally adequate.
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 is fully self-documented (100% coverage) with a clear description for 'manufacturer' including an example. The description adds no extra parameter semantics, but the schema already handles it adequately, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List'), a specific resource ('equaliser hardware models'), and a qualifier ('REW can generate filters for') that distinguishes it from the many sibling tools. It leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that it is useful for discovering supported hardware before using eq-related tools like auto_eq or get_eq_filters, nor does it state any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects. It states 'Create a REW measurement,' which clearly implies a state-changing write operation, but it does not mention whether the new measurement replaces an existing one, becomes the active measurement, or requires any pre-existing session/calibration context. This lack of behavioral context is a significant gap for an action with side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and provides essential details about the input format. Every phrase 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the core functionality for a data-import tool, and the rich schema descriptions fill in parameter details. However, with no output schema and no annotations, it omits guidance on post-creation effects (e.g., whether the measurement appears in the current measurement list, whether existing data is overwritten) and any prerequisites like needing an active measurement input for calibration. This is a moderate gap given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description adds some context by explaining that 'samples' are raw impulse response values and 'sampleRate' is intended for time-domain data, but this is largely redundant with the schema descriptions (e.g., 'Impulse response sample values'). It does not meaningfully enhance understanding beyond the structured parameter definitions.
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 ('Create a REW measurement') and specifies the exact input format ('raw sample values at a given sample rate'), distinguishing it from file-based imports like import_impulse_response or frequency-domain data tools. The verb 'Create' and the resource 'REW measurement' are specific and 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 a use case: when you have an in-memory impulse response (as opposed to a file), and the phrase 'in-memory' provides context against file-based sibling tools. However, it does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It does not state whether the operation is destructive, reversible, or requires special permissions, nor does it describe side effects or return behavior. The description only states the basic action, which is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action 'Change', and contains no filler or redundant information. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with full schema coverage, the description provides the minimal core purpose. However, it lacks information about return values, side effects, or usage context, which leaves the description adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of parameter descriptions, so the baseline is 3. The description adds semantic value by using 'and/or' to clarify that title and notes can be updated independently or together, a relationship not explicitly encoded 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 'Change a measurement's title and/or notes' clearly specifies the verb (change), resource (measurement), and the specific fields affected (title/notes). This distinguishes it from sibling tools like delete_measurement and get_measurement, which have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. There is no mention of prerequisites, conditions, or the relationship to other measurement tools, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the action but fails to mention whether updates are partial (only provided fields), whether the operation is reversible, or any permission requirements. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently communicates the core purpose without unnecessary detail.
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 and full schema coverage, the description is minimally viable. However, it lacks context about update semantics (e.g., partial updates, behavior when fields omitted) and return value, which would be valuable in the absence of annotations and an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description's mention of 'name and/or notes' adds no new semantic meaning beyond the schema's 'New name' and 'New notes'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Change' and identifies the resource 'group' and the updatable fields 'name and/or notes.' It clearly distinguishes this tool from siblings like create_group, delete_group, and list_groups.
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 use when modifying an existing group's name or notes, but it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes 'changes the measurement in place', which discloses a key behavioral trait (mutation). However, with no annotations, it does not discuss reversibility, effects on derived data, or prerequisites. This adds some value but leaves several transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that is direct and free of filler. It earns its place by conveying the core purpose and in-place mutation 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 simple two-parameter mutation tool with no output schema, the description is mostly complete. It covers the purpose and the mutation behavior, but omits details like return value or preconditions (e.g., measurement must exist). Slight gap, but adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with concise parameter descriptions (offsetDb: 'negative to lower'; measurement: UUID vs index). The description adds no new semantic detail beyond the schema, so it does not improve upon the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Shift a measurement's SPL level by a fixed offset in dB') and differentiates it from siblings like align_spl or arithmetic by specifying the exact operation. The resource (measurement's SPL level) and manner (fixed offset) 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to prefer this tool over alternatives. It does not mention related tools (e.g., align_spl, arithmetic) or when this would be a better choice. The description implies a simple offset but lacks explicit usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the core operation but fails to mention side effects, whether measurements are modified in place or new data is returned, prerequisites, or limitations. This is a significant transparency gap for an operation that may alter measurement data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It clearly communicates the action and purpose in a concise manner, using a dash to append the rationale.
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 4-parameter alignment operation with no output schema and no annotations, the description is incomplete. It does not describe what the tool returns, whether the operation is destructive, or any error/validation behavior. The one-liner is useful but leaves critical gaps for an agent to use 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 schema already provides descriptions for all four parameters (targetDb, frequencyHz, spanOctaves, measurements), and coverage is high. The description reinforces the meaning of targetDb ('target level or average') and frequencyHz ('centre frequency') but adds little beyond the schema. Baseline 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 clearly states the action ('Align'), the resource ('SPL of several measurements'), and the scope ('to a target level or their average around a centre frequency'). The dash adds the purpose ('level-matching before comparison or averaging'), which distinguishes it from sibling tools like average_measurements or align_measurements.
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 'level-matching before comparison or averaging' provides clear context for when to use the tool. However, it does not explicitly mention alternatives or when not to use it compared to similar sibling tools such as align_measurements or add_spl_offset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this is a prediction computed from current EQ filters, which is a key behavioral trait. However, it doesn't state whether the operation is read-only, what happens if no EQ filters exist, or any other side effects or limitations.
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 conveys the essential information without any wasted words. It is front-loaded with the core purpose and adds the crucial 'not a re-measurement' distinction at the end.
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 read-only tool with one well-documented parameter and no output schema, the description provides the essential context: what it returns and its predictive nature. It doesn't explain return format, but that was not required. Overall, complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single 'measurement' parameter thoroughly (UUID vs index, stability). Since schema description coverage is 100%, the description need not add parameter details, and it doesn't — baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a summary of the predicted frequency response after applying current EQ filters, and explicitly notes it's REW's prediction, not a re-measurement. This distinguishes it from siblings like get_frequency_response, though it lacks a direct imperative verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'not a re-measurement' implies using this when a prediction is desired instead of actual measurement, but no explicit alternatives or exclusions are named. The context is helpful but doesn't fully guide selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of disclosure. It mentions the outcome (producing an RTA measurement) but fails to mention key behaviors like whether a new measurement is added to the list, whether the operation is destructive, prerequisites (e.g., REW running), or supported file formats. This is a significant gap for a mutation-like 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 a single, focused sentence that uses no filler. It front-loads the key verb and resource, and every word contributes meaning.
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?
With no output schema and no annotations, the description should at least clarify what the tool returns and how it fits among the many import siblings. It does none of that. The description is minimal and leaves the agent to infer side effects, return values, and the precise distinction from similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional semantic nuance beyond what the schema already supplies for 'filePath' and 'channel'. It neither clarifies the relationship between parameters and the RTA process nor introduces helpful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific and action-oriented: 'Import an audio file' followed by the mechanism 'through REW's RTA' and the outcome 'producing an RTA measurement of its spectrum.' It clearly distinguishes this tool from siblings like import_frequency_response or import_impulse_response by emphasizing RTA analysis.
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: use this to generate an RTA spectrum measurement from an audio file. However, it does not explicitly contrast with alternative import tools or state when not to use it, missing the 'exclusions' part of the rubric.
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?
It discloses the process (sets model/target, matches response) and the return value (filters + summary), and adds that the output matches the REW GUI. However, with no annotations, it does not clarify whether running the tool has side effects on the REW session state or only computes/returns filters, leaving behavioral transparency incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action and key output, and the second sentence adds valuable credibility without redundancy. Every word contributes to understanding the tool's purpose and behavior.
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 has 7 parameters, no annotations, and no output schema, the description provides a clear core purpose and return value but lacks explicit usage guidance, side-effect disclosure, and details on the summary format. It is adequate but leaves notable gaps for a complex 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 coverage is 100%, so the baseline is 3. The description provides high-level context about model and target parameters but does not elaborate on each parameter's format or interaction beyond what the schema already documents. It adds marginal semantic value.
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 runs REW's automatic EQ on a measurement, details the steps (sets model/target, matches response), and explicitly distinguishes it from sibling filter tools by noting it is REW's own optimiser and produces filters matching the GUI. This makes the purpose unambiguous and distinct.
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 as an automatic optimizer but does not explicitly state when to use it versus manual alternatives like set_eq_filters or get_eq_filters. It provides no exclusions or direct alternative references, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only notes that the data is 'only meaningful' under certain conditions but does not disclose what happens when the condition is not met (e.g., error vs. empty result), nor does it describe output structure beyond 'table'.
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, effectively front-loaded with the verb and resource. No wasted words; every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read operation with no output schema or annotations. The description covers the core purpose and a key precondition, but lacks details on error handling, return table structure, or potential side effects, leaving some gaps for a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description itself adds minimal parameter-level insight beyond the schema, so it meets the baseline but does not enhance understanding of parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves distortion data (THD and harmonics) for a measurement as a table. It uses a specific verb ('get') and resource ('measurement's distortion data'), distinguishing it from sibling retrieval tools like get_frequency_response and get_rt60.
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 when the tool is meaningful: only for measurements captured with distortion analysis (swept sine). This provides clear contextual guidance, though it does not name alternative tools for non-distortion measurements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses that the output is 'measurement summaries' (a useful behavioral hint), but it does not clarify what fields summaries include, ordering, whether the group must exist, or error behavior. The read-only nature is implied by 'List' but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the action and resource. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one parameter and no output schema, the description is moderately complete. It communicates the core purpose but leaves ambiguity about the structure of 'measurement summaries' and how this tool relates to sibling operations like add_measurements_to_group or list_groups. Given the low complexity, a bit more detail on return contents would push it higher.
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 has 100% coverage for the single 'group' parameter, which includes a description ('Group UUID (from list_groups or create_group)'). The tool description adds minimal extra meaning—'in a group' echoes the parameter—but does not provide details on format or validation beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('measurements currently in a group'), with the qualifier 'as measurement summaries' indicating a summary-level response. This distinguishes it from siblings like list_measurements (all measurements) and get_measurement (single measurement).
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 you need to see which measurements belong to a group, but it does not explicitly contrast with alternatives such as list_measurements or add_measurements_to_group. There is no mention of when not to use it or prerequisites beyond the group parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only says 'List' which implies a read-only operation, but it doesn't explicitly mention safety, error behavior, or any side effects. This minimal disclosure is insufficient for a tool in a complex suite.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the purpose without any filler or unnecessary words. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), but the description lacks context about what the returned 'commands' look like, how they relate to 'run_measurement_command', or any caveats. It is minimally viable but leaves gaps that could confuse an agent.
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%, with the parameter 'measurement' fully explained as either UUID or index. The description text itself adds no extra parameter meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies a clear resource ('commands REW accepts for a specific measurement'). It is scoped to a particular measurement, distinguishing it from the broader 'list_api_commands' sibling tool.
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 implies the tool is used to retrieve commands for a specified measurement, providing context for when to use it. However, it does not explicitly mention alternatives or state when not to use it, keeping it just below the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the side effect of loading into REW and that it returns measurements, but does not state whether existing measurements are affected, path handling beyond forward slashes, or failure/error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, using two sentences to state the action, scope, and return value. It is front-loaded with the primary verb and resource, with no redundant 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 simple load tool, the description covers the core function but is thin given the lack of annotations and output schema. It omits usage context, side-effect details, and error conditions, making it minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single `paths` parameter, so the baseline is 3. The description adds the .mdat file format detail, clarifying the expected input beyond the schema's generic 'file paths' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads .mdat measurement files into REW and returns the measurements that appeared. It is specific as to the resource (REW measurements) and action (load), and distinguishes itself from import_* tools that handle different data formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for loading .mdat files, but provides no explicit context for when to use this tool versus alternatives like import_frequency_response or read_measurement. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool returns a full summary, which implies read-only behavior, but it does not explicitly state that it has no side effects, requires no special permissions, or how it behaves when the measurement is not found. The description adds minimal behavioral context beyond the basic 'Get' verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. Every part contributes meaning: 'one measurement' scopes the noun, 'full summary' specifies the output, and 'all metadata REW holds for it' clarifies the extent. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with one well-documented parameter and no output schema, the description is nearly complete. It explains what is returned (full summary of metadata) and the schema covers the input. It lacks guidance on edge cases or error handling, but given the tool's simplicity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter description coverage and the parameter description already explains the UUID vs index distinction and the stability caveat. The tool description itself adds no parameter-specific meaning, so the baseline of 3 is appropriate given the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'measurement' and explicitly scopes to 'one measurement' and 'full summary (all metadata REW holds for it)'. This clearly distinguishes it from siblings like list_measurements (which lists) and get_measurement_commands (which gets commands), leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the use case: when you need a single measurement's complete metadata. However, it does not explicitly mention alternative tools or when not to use it, such as pointing out that list_measurements is for enumerating measurements. This is clear context but lacks explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the key behavior that each imported channel becomes a measurement, which is useful. However, it does not mention prerequisites (e.g., REW running), whether existing measurements are overwritten, or how errors are handled. This is moderate transparency but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the essential information without wasted words. It is concise and structured clearly, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple import tool with a well-described schema, the description covers the core outcome: channels become measurements. The lack of an output schema and annotations is partially compensated by the clarity of the schema and the description. It could mention success/failure behavior or side effects, but given the tool's simplicity, it is largely 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 description coverage is 100%, so the baseline is 3. The description adds semantic value by explaining that each imported channel becomes a measurement, which directly clarifies the purpose of the 'channels' parameter. It also gives an example format (WAV), going beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Import an impulse response file (e.g. WAV) into REW; each imported channel becomes a measurement.' This gives a specific verb, resource, and outcome, and it distinguishes this tool from sibling import tools by focusing on impulse response files and their conversion to measurements.
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 explicit guidance on when to use this tool versus alternatives like import_impulse_response_data or import_rta_file. It only states what it does, leaving the selection criteria to the agent. There are no exclusions or mention of alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that each imported channel becomes a measurement and that the stimulus file must be set first, adding useful behavioral context. However, it does not mention side effects, whether existing measurements are overwritten, or any error/edge-case behavior, so transparency is moderate.
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, immediately states the core purpose, and uses no filler. It is front-loaded with the main action and provides necessary context clearly.
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 three parameters, no annotations, and no output schema, the description covers the workflow and outcome adequately. It explains the import process and the resulting measurements. Minor gaps include lack of mention of return values or error handling, but these are not critical for understanding core usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all parameters, so the baseline is 3. The tool description reaffirms the roles of stimulusPath and responsePath but adds no new details about the channels parameter or parameter formats beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Import a recorded sweep as a measurement' with a specific verb and resource. It also explains the process (set stimulus file, then import response file) and differentiates from sibling import tools by focusing on sweep recordings rather than generic frequency/impulse responses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool ('recorded sweep') and provides input requirements, but it does not explicitly contrast with alternatives like import_frequency_response or run_sweep. There are no explicit when-not-to-use or exclusion statements, leaving the usage guidance somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It fails to disclose whether commands mutate measurements, require permissions, or what side effects may occur. Since this is a 'raw' command runner capable of potentially destructive operations (e.g., 'Trim IR'), the lack of any warning or effect disclosure 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 two concise sentences with no fluff. The main action is front-loaded, and every sentence adds necessary context without redundancy.
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?
Despite rich schema documentation, the tool is an arbitrary raw command runner with no output schema and no annotations. The description does not cover return values, mutability, error scenarios, or risk, leaving the behavior largely opaque for a tool that can execute commands with varying effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described. The description adds value beyond the schema by explaining where to discover command names and providing example commands ('Estimate IR delay'), helping the agent understand the 'command' parameter format.
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: 'Run a raw REW command on one measurement'. It uses a specific verb and resource, and distinguishes itself from siblings by positioning as an 'escape hatch' with concrete examples ('Trim IR to windows', 'Estimate IR delay').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly frames when to use the tool ('Escape hatch for operations without a dedicated tool'), implying not to use it when a dedicated tool exists. It also gives discovery guidance (list_api_commands / the measurement's own command list), though it doesn't name specific alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses the key side effect that the tool overwrites an existing file, which is critical for an agent to know. However, it does not mention other behavioral aspects such as whether it requires loaded measurements, what happens if the path is invalid, or what the tool returns after saving.
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, consisting of just two short sentences. It front-loads the main action ('Save every loaded measurement to a single .mdat file') and then immediately states the overwrite behavior and path formatting. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with only two parameters and no output schema, the description provides enough context for agent selection and invocation. It explains the tool's scope, the destructive overwrite behavior, and the required path format. It could be slightly more complete by mentioning the optional note parameter or return behavior, but given the tool's simplicity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for both parameters ('path' and 'note'). The description adds minimal parameter-specific value; it repeats the forward-slash requirement already present in the schema and does not elaborate on the optional 'note' parameter. Since schema coverage is high, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Save' with the resource 'every loaded measurement to a single .mdat file', making the tool's action and scope unmistakable. It also distinguishes itself from sibling measurement tools by focusing on the save-all-to-one-file behavior, and the parenthetical '(overwrites an existing file at that path)' adds important clarifying detail.
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 clearly implies when to use the tool (when saving all loaded measurements to a single file) but does not explicitly discuss alternatives or when not to use it. It does mention the requirement to use forward slashes, which is useful, but there is no explicit 'use this instead of X' 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 full burden of behavioral disclosure. The verb 'Read' strongly implies a side-effect-free operation, but it does not explicitly state that nothing is modified, nor does it mention potential errors (e.g., if alignment is not configured) or prerequisites. The description does add useful context about the scope of the state, but stops short of full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary purpose and then enumerates the contents concisely. Every element listed (mode, frequency, indices, per-side settings, delay limits, accepted modes/commands) is necessary and adds value without 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 zero-parameter read tool with no output schema, the description is remarkably complete. It lists all the state components that will be returned, which is essentially the full contract for the tool. There are no gaps that would leave an agent guessing about what this tool provides.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. The description adds relevant information about what the returned state contains, which is more meaningful than parameter details. There is nothing more to add for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and resource ('the alignment tool's full state'), and enumerates the exact components returned (mode, frequency, indices, per-side gain/delay/polarity, delay limits, accepted modes/commands). This clearly distinguishes it from sibling tools like configure_alignment or run_alignment_command, which are write/execute operations.
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 explicit guidance on when to use this tool versus alternatives. It does not mention that it is the read counterpart to configure_alignment, nor does it state that it should be used to inspect state before making changes. The only implied usage is from the verb 'Read', but no exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the impulse-response prerequisite, but does not explicitly state whether the operation is read-only, what it returns, or potential error conditions. 'Generate and read' implies analysis, but lacks explicit side-effect or safety disclosure, leaving a 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 two sentences long, front-loads the purpose, and adds a key prerequisite without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema) and the description covers purpose and a key constraint. However, because there are no annotations, the description should carry more behavioral context (e.g., return format, non-destructive nature), which is missing. For a simple read tool, this is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage, explaining both 'measurement' and 'octaveFraction'. The description's mention of 'per octave or one-third-octave band' merely echoes the schema's enum descriptions, adding no new parameter semantics.
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 specifies a clear verb ('Generate and read') and resource ('RT60 / ISO 3382 decay parameters'), naming specific parameters (EDT, T20, T30, Topt) and band types (octave/one-third-octave). This clearly differentiates it from sibling tools like get_frequency_response or get_distortion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a prerequisite: the measurement must have an impulse response, and notes that swept measurements do. This provides clear context on when the tool is applicable, but it does not explicitly name alternatives or when-not-to-use scenarios, so it earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It does disclose that the tool predicts modes and can correlate them with measurements, and it explains the implications for EQ vs. nulls. However, it does not describe the output format, whether the tool is read-only, or any assumptions/limitations beyond 'rectangular-room.' This is some behavioral context, but not full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys purpose, optional behavior, and practical interpretation. There is no redundant or filler content; every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters and no output schema or annotations. The description explains the core purpose and optional correlation, but it does not specify what the tool returns (e.g., a list of modes, frequencies, or a correlation report). While the schema covers each parameter, the lack of output details leaves a notable gap for an analysis 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%, so the baseline is 3. The tool description does not add parameter-level detail beyond what the input schema already provides, such as units or the meaning of maxHz or rt60Seconds. It only conceptually references 'room dimensions' and 'measurement,' which the schema already covers.
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: 'Predict rectangular-room standing-wave modes from room dimensions.' It further clarifies the optional correlation with measured peaks/nulls to identify modal response problems, which clearly distinguishes it from sibling analysis tools like analyze_response or get_predicted_response.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use the tool: to predict room modes and optionally correlate them with a measurement to identify which response problems are modal. It also gives practical guidance (EQ can tame modal peaks; modal nulls need placement or treatment). However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: 'Returns the UUIDs of the measurements added.' It also states the group must already exist ('existing group'). However, it does not disclose side effects such as whether duplicates are allowed or if the operation replaces existing memberships, which is notable for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, front-loaded with the action, and no filler. Every word adds value—purpose in the first sentence, return behavior in the second.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with fully documented parameters, the description covers the essential aspects: action, target (existing group), and return value. It lacks details on edge cases or errors, but given the tool's simplicity and the schema richness, it is sufficiently complete. The absence of an output schema is mitigated by the explicit mention of return UUIDs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly, including the group UUID source and the measurement UUID/index choices. The description does not add meaningful parameter semantics beyond the schema; it only restates 'one or more measurements' which mirrors minItems. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific and clear: 'Place one or more measurements in an existing group' uses a direct verb and resource, distinguishing it from sibling tools that create, delete, or retrieve groups/measurements. It also states the return value, further clarifying its function.
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 implies when to use the tool: when you need to add measurements to an existing group. While it doesn't explicitly mention alternatives, the context is unambiguous and the phrase 'existing group' signals a prerequisite. It lacks an explicit exclusions list but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses what the tool computes and outputs, implying read-only behavior, but doesn't explicitly state safety, error conditions, or side effects. The lack of explicit non-destructive confirmation is a gap, though the analysis nature mitigates concern.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and outputs, followed by a clear usage statement. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, no output schema, no annotations), the description provides sufficient context: what it does, what it returns, and when to use it. It could mention prerequisites or output format, but the listed outputs and clear purpose make it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description adds no extra parameter nuance beyond what the schema provides. Baseline of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool interprets a measurement's frequency response, listing specific outputs (per-band levels, flatness, peaks/nulls with frequency, deviation, Q, severity). It distinguishes itself from siblings like get_frequency_response by positioning as 'the primary tool for answering what is wrong with this response?'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it's the primary tool for diagnosing response issues, giving clear usage context. It doesn't name specific alternatives or when not to use it, but the positioning implies when to prefer it over raw data retrieval 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 carries the full burden of behavioral disclosure. It transparently states that the tool 'produces a new measurement,' indicating a non-destructive operation. However, it omits details about edge cases (e.g., division by zero), whether the result is saved or returned, or any permission/state requirements. This is an acceptable baseline but leaves room for more behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, directly states the core purpose and result, and uses efficient, specific language. There is no redundant or tangential content, and the most important information is front-loaded. This is exemplary conciseness.
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 moderate complexity (6 parameters, no output schema, no annotations), the description sufficiently covers the purpose, operation semantics, and the fact that a new measurement is produced. It could be more complete by mentioning how the result is returned or any prerequisites, but the essential behavior and context are adequately conveyed for an agent to understand and invoke the tool 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 provides full descriptions for all six parameters, so the baseline is 3. The description adds minimal extra value by clarifying the A/B ordering and giving examples of valid operation strings, but it does not compensate for any missing parameter details since the schema already covers them thoroughly.
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 tool's function as arithmetic operations on a pair of measurements, names the roles of the inputs (first = A, second = B), and provides concrete examples of operations and their use cases (division for transfer functions, subtraction for difference curves, inversion for correction curves). This distinguishes it from sibling tools like compare_measurements or average_measurements, which focus on other analysis tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear contextual guidance by mapping each operation type to its intended purpose, implying when the tool should be used. However, it does not explicitly contrast with alternatives or state when not to use it, such as when averaging or comparing measurements would be more appropriate. This is a minor gap, but the practical use cases are well illustrated.
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 full burden for disclosing behavior. It explicitly states that there is no confirmation and no undo, and that REW deletes immediately, which is critical for a destructive operation. It does not cover permissions or side effects, but the most important behavioral trait is well-disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource. The second sentence adds essential warning about irreversibility without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required parameter, no output schema), and the description plus schema cover its core usage and the critical destructive behavior. It could mention what happens on invalid input or whether deletion is permanent across sessions, but the essential context is present, making it sufficiently complete for this 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%, so the schema already documents the measurement parameter well (UUID preferred or 1-based index). The tool description adds no additional parameter semantics beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete'), the resource ('one measurement from REW'), and the scope ('one measurement'). It distinguishes the tool from sibling tools like rename_measurement and get_measurement by naming the specific action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting a measurement but does not explicitly state when to use it over alternatives or when not to use it. The warning about no undo suggests caution, but there is no mention of exclusions or alternative tools for safer deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly states this is a read operation and describes the returned data fields, which adds transparency about the output. However, it does not mention potential side effects (likely none) or error conditions like missing measurement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that fronts the action (Read) and resource (EQ filter bank), then lists the key contents. Every word adds value; no wasted phrasing.
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 (one parameter, no output schema), the description adequately covers return content and the measurement scope. It does not specify the output format structure (e.g., array of objects), but the mention of 'per filter' communicates this sufficiently. It could be more explicit about exclusivity to EQ filter data, but the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'measurement' clearly documented as UUID (preferred) or index, noting index instability. The tool description adds no further parameter semantics beyond this, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the EQ filter bank for a measurement, listing the specific attributes (type, frequency, gain, Q, enabled per filter). This distinguishes it from sibling tools like set_eq_filters (write) and get_frequency_response (frequency response data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading EQ filter settings but does not explicitly contrast with alternatives or state when not to use. Siblings like get_frequency_response and get_rt60 exist, so some guidance would be helpful, but the specific resource is clearly identified.
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 data format (log-spaced, dB SPL or ohms) and optional phase, which is useful, but it does not mention side effects such as whether an existing measurement with the same name is overwritten, or how the measurement is stored. This is a moderate disclosure for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the purpose, input format, and key parameter relationships. No words are wasted, and it is easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters and no output schema, the description covers the essential input structure and units, but it omits details about return values or error behavior. However, the schema provides full parameter coverage, so the description is sufficient for most selection and invocation purposes.
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 100%, so the baseline is 3. The description adds interpretive value by clarifying that magnitude values are log-spaced, starting at startFreqHz with pointsPerOctave resolution, and that ohms relate to isImpedance. This goes beyond the schema's individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'REW measurement', and specifies the input as 'in-memory frequency response data'. It distinguishes itself from siblings like import_impulse_response_data by mentioning frequency response and log-spaced magnitudes, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have in-memory frequency response data, but it does not explicitly mention when not to use this tool or name alternatives like import_frequency_response or import_impulse_response_data. The context is clear, but exclusionary guidance is missing.
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 explicitly states 'changes the measurement in place', alerting the agent to the mutating nature. However, it does not disclose reversibility, permissions, or potential side effects on other dependent measurements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and the parenthetical adds the crucial in-place caveat economically. Every word earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with fully documented parameters, the description adequately covers purpose and side effect. The lack of output schema and annotations is partially mitigated by the clear in-place note, though it could mention which measurement types support smoothing or whether the operation is reversible.
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%, with both 'measurement' and 'smoothing' already documented. The description adds no extra parameter semantics beyond what the schema provides, such as the UUID vs index distinction or the enum values, so it meets the baseline without adding value.
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 (apply smoothing) and the resource (a measurement), and notes the in-place effect, distinguishing it from read-only measurement tools. 'Fractional-octave smoothing' further specifies the exact operation, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when smoothing is needed, but provides no explicit guidance on when to choose this over alternatives like 'arithmetic' or 'average_measurements'. No exclusions or prerequisites are stated, leaving the agent to infer usage from the operation name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool creates a new measurement, which is useful, but it does not describe error behavior, file format validation, or side effects beyond creating a measurement. This is a moderate gap given the absence of 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, front-loaded with the core purpose, and the second sentence provides an alternative. Every word earns its place; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple input (one parameter) and no output schema. The description clearly states the outcome (new measurement) but does not mention expected return values or error handling. It also does not distinguish from other similar import siblings like import_frequency_response_data, which would improve completeness. Overall adequate but with notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the only parameter (filePath) with 100% coverage. The description adds context about the file being a 'text frequency response file' with a specific line format, but does not add detail about the parameter itself. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Import') with a clear resource ('text frequency response file') and outcome ('into REW as a new measurement'). It also explicitly distinguishes from a sibling tool ('For native .mdat files use load_measurement_files instead'), satisfying the requirement for 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-not-to-use guidance by stating 'For native .mdat files use load_measurement_files instead.' This gives a clear alternative for a specific scenario, effectively guiding tool selection. The implied usage (for text frequency response files) is also evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool creates a new measurement and applies current settings, and requires a prior setup. However, it does not mention side effects, error conditions, permissions, or return value, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The first sentence states the action and specifics; the second gives the prerequisite. Perfectly 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 parameterless tool with no output schema, the description explains the purpose and prerequisite adequately. It does not describe return format or error handling, but the creation of a new measurement implies the outcome. Slight gap, but overall complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema is trivially complete at 100% coverage. The description adds context about what the operation does, which is appropriate for a parameterless tool. Baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create'), identifies the resource ('new measurement'), and explains the exact operation (sum of alignment tool's A and B with current settings). This clearly distinguishes it from sibling tools like align_measurements (setup) and arithmetic (generic math).
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 the prerequisite to run align_measurements or configure_alignment first, giving clear context for when to use. It does not provide explicit exclusions or alternative tools, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: failure on duplicate names, optional placement of measurements, and the return of the group with its UUID. It could mention permissions or side effects, but the provided details are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that efficiently conveys the action, optional behavior, failure mode, and return value without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the schema's thorough parameter coverage, the description is largely complete. It includes essential context (duplicate handling, return info), though it could benefit from a hint about when to use this tool over sibling group tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description's mention of placing measurements is somewhat redundant and doesn't add meaning beyond the schema's details like the distinction between UUIDs and indices.
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 ('Create a new measurement group'), the resource, and an optional behavior ('optionally placing measurements'). It also mentions the failure condition and return value, distinguishing it from siblings like update_group and add_measurements_to_group.
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 context is clear: this tool is for creating new groups. However, it does not explicitly mention alternatives or when not to use it (e.g., use update_group for existing groups), so it falls short of the highest bar.
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 mentions data decimation ('decimated to a readable number of points') and summary statistics, but does not disclose the return format, error behavior, or explicitly state read-only. This is reasonable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core function, followed by a useful pointer to an alternative. Every word contributes; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does and when to use a sibling instead. The schema fully documents all parameters. Given there is no output schema, the description could have elaborated on summary statistics or curve format, but it is complete enough for a straightforward retrieval 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%, so the baseline is 3. The description adds context about log-spacing and decimation, which relates to maxPoints, but doesn't provide per-parameter syntax beyond the schema. It doesn't need to compensate for missing coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a measurement's frequency response as a log-spaced, decimated curve plus summary statistics. It also explicitly differentiates from the sibling tool analyze_response by directing interpretation tasks there.
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 'For interpretation (peaks/nulls/band balance) prefer analyze_response,' providing a clear when-not-to-use and naming the alternative. This gives the agent practical guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently describes the workflow: starts the meter, waits for integration, reads, optionally stops. This discloses side effects and timing behavior, adding value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, followed by workflow and a usage hint. Zero fluff, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with 100% schema coverage and no output schema, the description is quite complete. It covers purpose, workflow, and a practical usage tip (play a signal, see generator). It could mention prerequisites like REW running or return format, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal parameter-specific meaning; it mentions 'optionally stops' and 'waits for it to integrate' which map to stopAfter and settleSeconds, but the schema already describes each parameter adequately.
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 reads sound pressure level from REW's SPL meter, listing specific measurements (SPL, Leq, SEL). It distinguishes from sibling tools by focusing on live SPL metering rather than stored measurements or sweeps.
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: use this to measure playback level and suggests playing a signal via the generator tool. However, it does not explicitly state when not to use it or compare to alternatives like get_measurement, so it misses a full exclusion list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that extra parameters merge into the command body at the top level, but does not warn that this is a raw escape hatch that could execute arbitrary alignment commands, potentially with side effects. Given the tool's broad power, this lack of caution or side-effect disclosure is a notable 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?
Three concise, information-dense sentences. Each sentence earns its place: what it does, how to discover command names, the escape-hatch use case, and parameter handling. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a raw command runner with full schema coverage, the description is mostly complete: it explains the purpose, parameter merging, and where to find valid commands. It could be more complete by mentioning likely return behavior or cautioning about destructive actions, but given the tool's intentionally open-ended nature, the current level is solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both command and parameters have descriptions), so the baseline is 3. The description adds meaningful semantic value by explaining that parameters merge into the command body at the top level, and by pointing to get_alignment_state for discovering valid command names. This goes beyond what the schema states.
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 runs a raw alignment tool command, positioning it as an escape hatch for commands without a dedicated tool. It distinguishes itself from more specific sibling tools like align_measurements or create_aligned_sum by explicitly covering the 'raw' and 'escape hatch' use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells users to discover command names via get_alignment_state's availableCommands, and explains when to use this tool: for commands without a dedicated tool, such as impulse-mode alignment or 'Aligned copy'. This clearly signals when this tool is appropriate over more specialized alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses that the tool blocks until the sweep completes and returns the new measurement, which are critical behavioral traits. It also surfaces the license/configuration dependencies. However, it does not mention potential side effects (e.g., overwriting an existing measurement with the same name) or failure behaviors, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, then prerequisites, then behavior. Every clause adds value: configure/run, license requirement, blocking, and return value. There is zero redundancy or verbose padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description covers the essential operational context: purpose, prerequisites, blocking behavior, and return value. It is missing a note on failure modes or what constitutes a successful 'new measurement' in terms of storage/session, but the description is largely complete for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level guidance beyond what the schema already provides, such as the enum for sweep length and the default values. It does not explain how parameters interplay (e.g., startFreq vs endFreq), but the schema is self-sufficient, so a 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 opens with a specific verb+resource: 'Configure and run a swept-sine SPL measurement.' This clearly distinguishes it from generic siblings like run_measurement_command and other measurement tools. It also states the result ('returns the new measurement'), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool by stating prerequisites: REW audio input/output must be configured and a REW Pro license is required for API-triggered measurement. It implies this is the dedicated path for swept-sine measurements, but it does not explicitly mention alternatives or when to choose another tool, so it misses a strong 'when not to use' statement.
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 provided, so description carries the burden. It discloses that the result remains in the alignment tool's preview state and does not persist, and that the tool reports the computed delay. This is key behavioral context, though more detail on side effects could be useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, information-dense sentences. Front-loaded with the action, then role clarification, then next steps. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description indicates the primary output (the delay). It covers workflow and preview state. It does not detail output formatting or edge cases, but overall it is sufficiently complete for a tool with good schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds role semantics (A as reference, B as delayed) and contextualizes frequencyHz as the crossover, enriching the schema definitions.
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 phase-aligns measurement B to A at a specified frequency and reports the computed delay. It distinguishes from siblings by specifying the phase-alignment use case and the preview-state result.
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: A is reference (mains), B is delayed (sub), frequency typically the crossover. Includes follow-up guidance (create_aligned_sum or apply delay in DSP), though it does not explicitly contrast with siblings like align_spl.
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 explicitly states that the tool creates a 'new one' (a new measurement), implying non-destructive behavior, and discloses the recommended default method. This adds useful behavioral context, though it stops short of detailing potential side effects like measurement compatibility requirements or whether the original measurements are fully unchanged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero wasted words. The first sentence front-loads the action and resource, and the second sentence adds directly useful guidance about the default method. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (two parameters, one enum, one array) and the schema already documents the parameters. The description covers the core purpose and recommended method, which is sufficient for an agent to invoke it correctly. It does not describe the return format, but since there is no output schema and the operation is straightforward, this is an acceptable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 50% of the parameters with descriptions, and the description adds meaning by mapping 'several measurements' to the measurements array and 'Vector average' to the method parameter. It also provides a practical recommendation for which enum value to use, which goes beyond the schema's raw enum list.
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 construction: 'Average several measurements into a new one' — clearly stating what the tool does. It also distinguishes itself from siblings by identifying this as 'the standard way to combine multiple mic positions', differentiating it from smoothing, alignment, and arithmetic tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: combining multiple mic positions via spatial averaging. It also recommends 'Vector average' as REW's default method, offering practical usage guidance. It does not explicitly state when not to use it or name alternatives, but the context is strong enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output form (per-band summary, largest divergences) and the meaning of sign ('Positive values mean A is hotter'), which is meaningful behavioral context. It does not mention read-only status or side effects, but for a comparison tool the absence of mutation is inferable and the description does add useful non-obvious information.
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-crafted sentence that front-loads the purpose and packs in examples and output semantics without redundancy. Every clause adds useful information, achieving maximum conciseness without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately summarizes the return content (difference curve per band, largest divergences). It covers the core behavior and provides context for typical use. It could be more explicit about how 'per band' is determined or how maxPoints affects results, but those are partially covered by the schema and domain conventions, making the description reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds extra value by clarifying the directional relationship between measurementA and measurementB through 'Positive values mean A is hotter', which helps the agent understand parameter orientation. This exceeds simple schema repetition.
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 'compare' with a clear resource ('two measurements') and specifies the output ('A-minus-B difference curve summarised per band, plus the largest divergences'). The examples (before/after EQ, left/right symmetry) and the direction semantics ('Positive values mean A is hotter') distinguish it from sibling tools like arithmetic or average_measurements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage contexts ('e.g. before/after EQ, left/right symmetry'), making it clear when comparison is appropriate. It does not explicitly state exclusions or name alternative tools, but the examples imply the intended use case, which is more than vague 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?
No annotations are provided, so the description must carry the full burden. It discloses the core behavior (setting knobs and returning the resulting state) and implies a non-destructive configuration operation. However, it does not mention potential side effects, persistence, or whether the configuration is temporary or affects other alignment tools. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and knobs, then the usage context and alternative. No filler or redundancy; every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters, no required fields, no output schema, and no annotations, the description provides a solid complete picture: any subset can be set, the resulting state is returned, and it's positioned against the standard alignment tool. It could mention the output structure or state details, but given the tool's simple config nature, it is nearly 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 high (83%), but the description adds meaningful grouping of parameters (measurement pair, mode, frequency, per-side gain/delay/polarity, delay limits), which helps the agent understand the parameter landscape. It also covers the two undocumented params (maxNegativeDelayMs, maxPositiveDelayMs) via 'delay limits', compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set any subset of the alignment tool's knobs' and enumerates the specific knobs (measurement pair, mode, frequency, per-side gain/delay/polarity, delay limits). It explicitly distinguishes itself from the sibling align_measurements, which performs the standard phase-align in one call, making the identity and scope immediately clear.
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 usage guidance: 'For manual what-if adjustments' and directly names the alternative tool for standard operation ('align_measurements does the standard phase-align in one call'). This tells the agent exactly when to choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly warns 'There is no confirmation and no undo' and states that deletion is immediate. This is critical for a destructive operation and is transparent about the irreversibility and scope.
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 short sentences, each earning its place: the action, the warning about no undo, and the scope (measurements not deleted). It is front-loaded with the primary action and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter delete tool without an output schema, the description covers the necessary context: it identifies the target by UUID, emphasizes the irreversible nature, and clarifies that measurements survive. This is sufficient; no return value is expected for such a command.
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% for the single 'group' parameter, which already states 'Group UUID (from list_groups or create_group)'. The description adds little beyond the schema, merely repeating 'by UUID'. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete one measurement group by UUID' with a specific verb and resource. It distinguishes itself from sibling tools by clarifying that only the group is deleted, not its measurements, which sets it apart from delete_measurement.
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 delete a group but keep its measurements. It does not explicitly name alternatives, but the clarification that measurements are not deleted serves as an implicit distinction from delete_measurement. No explicit exclusions are given.
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 transparency burden. It discloses the partial-application behavior ('Applies whichever settings are provided') and the playback toggling behavior, which are important non-obvious traits. It does not mention return values or no-op behavior when called with no parameters, but coverage 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 well-structured sentences: the first states the core operation and optional playback; the second gives the minimal toggle use case. Every word earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four optional parameters, no output schema, and no annotations; the description covers the operation and the key usage pattern. It could additionally mention what happens when called with no parameters or how results are returned, but for a signal-generation control tool the description is substantially 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 description coverage is 100%, so the baseline is 3. The description adds value by specifying that provided settings are applied independently and that omitting play leaves playback state unchanged, which clarifies parameter interaction beyond per-parameter schema text.
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 action-resource pair ('Control REW's signal generator'), identifying a unique tool among sibling measurement commands. It further clarifies the tool's two functions (apply settings and optionally toggle playback), leaving no ambiguity about its 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?
It gives concrete usage guidance, including the exact minimal call for toggling playback with only { play: true } or { play: false }. It does not, however, explicitly contrast with alternative tools or state when it should not be used, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It openly states the partial-update semantics: 'fields you omit keep their current value,' which is a critical behavioral trait beyond what the schema conveys. It also implies a mutating operation via 'Replace or update,' making the non-read nature clear. While it doesn't mention returns or errors, the partial-update nuance is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the primary action, then a key behavioral note, then a practical usage hint. Every sentence adds value with no redundancy or filler. It is efficiently 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?
For a simple setter with two parameters, the description provides the core context: what it does, how partial updates work, and a prerequisite read step. It does not detail return values, but in the absence of an output schema and given the simplicity, this is sufficient. A minor gap is whether it creates new slots, but overall it is complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes each filter field but not the interaction between entries. The description adds essential meaning: 'Each entry is one filter slot' and 'fields you omit keep their current value.' This clarifies how to construct the filters array (incremental updates) and the role of the index parameter. With schema coverage at 50%, this fills a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb and resource: 'Replace or update individual EQ filters on a measurement.' This is specific and distinguishes it from siblings like get_eq_filters (read) and auto_eq (automatic adjustment). The phrase 'individual EQ filters' clarifies it operates on existing filter slots, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use get_eq_filters first to see the slots.' This tells the agent when to use this tool relative to its sibling get_eq_filters, implying a read-before-write workflow. It does not explicitly mention when not to use it, but the instruction is clear and context-rich.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that all groups are listed and specifies the exact output contents (UUID, name, notes). It also reveals an important behavioral trait: UUIDs are the only stable way to reference groups elsewhere. The description could mention that it is read-only explicitly, but 'List' strongly implies no side effects, so this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, both of which add value: the first states the function and output, the second provides essential guidance on UUIDs. There is no redundancy or filler. It is front-loaded with the core 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 zero-parameter tool without an output schema, the description is complete. It names the tool's scope ('all measurement groups in REW'), enumerates the return fields, and highlights a critical usage note. Given the low complexity, the description fully equips an agent to invoke and interpret the results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter semantics to document. The description adds context about the output fields and UUID stability, which is relevant to using the tool effectively. With no parameters, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as listing all measurement groups in REW and specifies the returned fields (UUID, name, notes). This distinguishes it from sibling tools like list_measurements, which target a different resource. The verb 'List' plus the explicit resource 'measurement groups' makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence provides clear context for when to use this tool: to obtain persistent UUIDs for groups that serve as stable references in other tools. It does not explicitly name alternative tools or state when not to use it, but it establishes a key use case. The context is clear enough for an agent to infer this is the go-to tool for discovering group identifiers.
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 verb 'List' implies a non-destructive read operation, and the description enumerates the returned fields, making the tool's behavior reasonably transparent. However, it does not explicitly state that no changes are made or mention potential limitations like large result handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and followed by concrete details. Every word contributes value, with no filler or repetition of 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?
Given the tool's simplicity (no parameters, no output schema), the description is fully complete: it states what the tool does, what data it returns, and how that data should be used. The mention of UUID stability adds important cross-tool context. No further information is needed for an agent 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, so the description's role is to clarify output rather than input. It adds value by enumerating the fields returned (UUID, index, title, notes, date, frequency range), which is meaningful beyond the empty input schema. The 0-parameter baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all measurements currently loaded in REW' with a specific list of returned fields. This distinguishes it from sibling tools like get_measurement, which implies retrieving a specific measurement rather than listing all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by noting that UUIDs are the stable way to reference measurements in other tools, implicitly guiding the agent to use this tool to obtain UUIDs before invoking other measurement tools. It lacks explicit 'when not to use' exclusions, but the context is sufficient for a simple listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It explains the tool checks connectivity and reports application state, including errors and warnings, which implies a read-only diagnostic operation. It does not explicitly state side effects, permissions, or rate limits, but the nature of 'check' and 'report' makes the lack of mutation clear. This is adequate for a simple status tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each earning its place: the first states the tool's purpose and output details, the second provides critical usage guidance. It is front-loaded and free of redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 parameters, no output schema, and a simple diagnostic role, the description is complete. It specifies what is checked, what is reported, and when to use it. Given the tool's simplicity, no additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for parameter semantics is 4. There is no need for the description to explain parameters, and the schema confirms no inputs are required. The description appropriately focuses on behavior rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and clearly identifies the resource ('REW API connection') and the scope of what is reported ('reachability, measurement count, and any logged errors or warnings'). It distinguishes itself from sibling tools, none of which perform a status/diagnostic function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Run this first if other tools fail.' This provides clear usage guidance and positions the tool as a first-line diagnostic. While it doesn't list when-not-to-use alternatives, the instruction is sufficiently specific for a unique status tool.
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:

[![room-eq-wizard-mcp MCP server](https://glama.ai/mcp/servers/brandon-fryslie/room-eq-wizard-mcp/badges/card.svg)](https://glama.ai/mcp/servers/brandon-fryslie/room-eq-wizard-mcp)

Score Badge

Copy to your README.md:

[![room-eq-wizard-mcp MCP server](https://glama.ai/mcp/servers/brandon-fryslie/room-eq-wizard-mcp/badges/score.svg)](https://glama.ai/mcp/servers/brandon-fryslie/room-eq-wizard-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/brandon-fryslie/room-eq-wizard-mcp'

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