mcp-rs-cmw500

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation3/5
The technology prefixes (gen, meas, bt, lte, wlan) and consistent verb_noun pattern help differentiate tools, but with 90 tools there is some overlap, e.g., cmw_get_full_state vs cmw_get_status and cmw_set_signal_path vs cmw_rf_route_set. Most tools are clearly distinct, but a few pairs could cause misselection.
Naming Consistency5/5
All tool names follow a strict cmw_<domain>_<verb>_<noun> pattern, with minor exceptions like cmw_connect and cmw_discover, but these are still clear and predictable. The naming is extremely consistent across the entire set.
Tool Count2/5
90 tools is far above the 25+ threshold and feels excessive even for a complex instrument like the CMW500. While each tool has a purpose, the sheer volume makes the server unwieldy and likely contains functions that could be consolidated or parameterized.
Completeness5/5
The tool set covers connection management, identification, error handling, capabilities, system operations, templates, GPRF generation and measurements, Bluetooth, LTE (including signaling), WLAN, RF routing, external attenuation, limits, and raw SCPI access. This is a thorough and near-complete surface for the instrument's capabilities.
Average 3.1/5 across 90 of 90 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 63 commits in the last 12 weeks
- Last stable release on July 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under AGPL 3.0.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full responsibility for disclosing behavior. It fails to mention side effects (e.g., resetting all settings), prerequisites (e.g., connection), or the impact on the current system state. The text is a mere label with no behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but this is under-specification rather than conciseness. It uses few words but conveys no meaningful information, so the sentence does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is severely incomplete. Even with only two simple parameters, the tool's core function is undefined, making it impossible for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists only 'host' and 'port' with no descriptions, and the description makes no reference to these parameters. With 0% schema description coverage, the description does nothing to compensate, leaving their purpose and requirements completely unknown.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Full system preset of CMW500' is a noun phrase with no verb or action, essentially restating the tool name 'cmw_preset'. It does not state whether the tool applies a preset, returns one, or resets the system, and it fails to distinguish itself from sibling tools like cmw_load_state or cmw_apply_template.
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?
There is no guidance on when to use this tool versus alternatives such as cmw_load_state, cmw_apply_template, or cmw_reset. The description provides no context for tool selection, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits, but it only repeats the enum options already in the schema. It does not reveal potential side effects (e.g., whether setting the technology resets other Bluetooth parameters), required permissions/authorization, or expected response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise at a single sentence, but it lacks any structured elaboration that would aid an agent. It is neither bloated nor particularly well-organized; it reads as a bare minimum functional statement rather than a carefully crafted summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, this description is severely incomplete. It does not mention the need for an active connection (inferred from host/port), the role of meas_instance, or how this setting interacts with other Bluetooth configuration tools, leaving the agent without sufficient context to use it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description does not compensate by explaining host, port, or meas_instance. The technology parameter's meaning is already implied by the enum values, so the description adds no substantive parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Set Bluetooth technology') and specifies the two options (Classic or Low Energy), making the resource and scope unambiguous. It does not explicitly distinguish this from sibling Bluetooth configuration tools, but the verb+resource combination is specific enough for basic understanding.
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 like cmw_bt_configure or cmw_bt_set_ble_mode. There is no mention of prerequisites (e.g., connection state) or conditions under which this setting should be changed, leaving the agent without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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, but it fails to explain what triggering entails, whether it blocks, what side effects occur, or what the output/result is. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded with the verb, but it is too sparse to be considered well-structured. It lacks essential detail, making it under-specified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is insufficiently complete. It does not explain the tool's role, return values, or any dependent steps, leaving a major gap in understanding for a complex measurement system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters. Schema coverage is only 33%, with host and port undocumented, and the description adds no meaning to the parameters, leaving the agent without sufficient context to set them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Trigger') and the resource ('Bluetooth multi-evaluation measurement'), making the core purpose apparent. However, it does not differentiate this from sibling tools like cmw_meas_trigger or cmw_wlan_trigger, so it falls short of a full 5.
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, prerequisites, or steps like configuration or connection. The description offers no contextual cues about its place in the Bluetooth measurement workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says 'Trigger... measurement' with no information about blocking behavior, side effects, required prior configuration, or how results are returned. This is effectively no transparency beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is under-specified for a tool with two parameters and no additional context. It is not overly verbose, but it lacks necessary substance, making it borderline between efficient and inadequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is far too minimal for the tool's role in a likely measurement workflow. It does not mention the need to configure measurements first, the fetch operations that retrieve results, or any relationship to sibling tools. Even with low complexity, the context is almost completely missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and no parameters are described in the schema or the description. The parameters 'host' and 'port' are present but their meaning or role in triggering the measurement is entirely unexplained. The description offers no compensation for the complete lack of parameter documentation.
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 identifies the verb ('Trigger') and the resource ('LTE multi-evaluation measurement'), distinguishing it from generic measurement triggers like cmw_meas_trigger and other technology-specific triggers. However, it does not explicitly contrast with siblings, so it stops short of a 5.
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, nor does it mention prerequisites or typical workflows. Context signals show sibling tools like cmw_lte_meas_configure and fetch tools, but the description gives no hint of how this trigger fits into the larger measurement sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only says 'Configure', giving no information about side effects, required state, reversibility, or safety. For a configuration tool that may alter instrument settings, this is a critical omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, making it concise and front-loaded. However, it is under-specified and does not earn its place by adding meaningful information beyond the tool name. It could be expanded with key details without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description is severely inadequate. It does not explain the effect of configuration, return values, prerequisites, or how it fits into the measurement workflow. This is insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific meaning beyond the input schema. Schema coverage is 60%, with host and port lacking descriptions, and the tool description does not compensate. Other parameters like repetition and meas_length_s have schema descriptions, but the tool description itself provides no guidance.
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 it configures GPRF power measurement parameters, using a specific verb ('Configure') and resource ('GPRF power measurement parameters'). It partially distinguishes from sibling tools like cmw_meas_configure_spectrum by focusing on power, but does not clarify what specific parameters are set or how it differs from cmw_meas_set_power_filter.
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 offers no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions. Usage is only implied by the tool's name and generic description.
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?
There are no annotations, so the description carries the full burden of disclosing side effects. It merely says 'apply' without mentioning what settings change, whether the operation is reversible, or what happens if no template is loaded. The mutation-like nature is implied but not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words, so it is concise. However, it is under-specified and lacks any structural elements like separate purpose, prerequisites, or effects, making it only minimally acceptable.
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 two parameters, no output schema, and numerous related tools (cmw_connect, cmw_load_template), the description is incomplete. It does not explain when a template is considered 'currently loaded,' what applying accomplishes, or how host/port relate to the operation, leaving critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines only host (string) and port (integer) with zero descriptions, and schema description coverage is 0%. The description does not mention these parameters at all, providing no clue as to their purpose (presumably connection details) or format, making it impossible to fill them correctly.
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 uses the verb 'apply' and specifies the resource as 'currently loaded template' targeted at the CMW500. It distinguishes itself from sibling cmw_load_template by implying an existing loaded template. However, it does not clarify what 'apply' entails, so it stops short of being fully specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as cmw_load_template, cmw_load_state, or direct configuration tools. It also omits prerequisites like having a template loaded or a connection established, leaving the agent without orientation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It implies a read-only operation via 'Get', but does not mention whether an active connection is required, what specific status fields are returned, or how errors are handled. This minimal disclosure is insufficient for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it omits essential details and is under-specified. While not verbose, it does not effectively structure information for an agent, as it lacks any elaboration or sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is incomplete. It does not explain the return value, dependencies, or how this tool fits into the broader CMW workflow, making it inadequate for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines two parameters (host and port) with no descriptions, and the tool description does not mention them at all. With 0% schema description coverage, the description fails to compensate, leaving the agent to guess the meaning and requirements of these parameters.
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 uses a specific verb 'Get' and identifies the resource as 'CMW500 connection and configuration status', making the primary purpose clear. However, it does not differentiate from the sibling tool 'cmw_get_full_state', which likely overlaps in functionality, so it falls short of a top score.
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, prerequisites, or alternatives. It simply states the action without contextualizing it among the many related CMW tools, leaving the agent without sufficient direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must disclose behavioral impact, but it only states the action without mentioning side effects, reversibility, required state, or consequences for ongoing measurements. An agent cannot infer whether this is safe or catastrophic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At only four words, it is too sparse rather than concise. It lacks essential context that could be added without significant length, so the brevity is under-specification, not effective compression.
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?
The tool description is a fragment. It does not explain return values, errors, or preconditions, and the lack of any structured metadata (no annotations, no output schema) leaves the agent with insufficient information to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The two parameters (host, port) have no descriptions in the schema and the tool description does not explain their meaning or format. Schema coverage is 0%, and the description fails to compensate, leaving parameter semantics entirely undocumented.
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 a single action ('Turn off') applied to a specific resource ('LTE cell'), which distinguishes it from the sibling 'cmw_lte_cell_on'. Despite brevity, the verb+resource format is unambiguous within the CMW context.
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 information is provided about when to use this tool versus alternatives like cmw_lte_cell_on or cmw_system_all_off. The description offers no usage scenarios, 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?
No annotations are provided, so the description carries the full burden. It only states the tool 'gets' information, which implies a read operation, but it does not disclose return format, whether a connection is required, or any other behavioral traits. Minimal detail beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, making it concise and easy to parse. However, it is too sparse to be fully informative, though the structure itself is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no parameter documentation, and no usage context, the description is severely incomplete. It fails to explain what UE information is returned, what host/port parameters do, or how this tool fits among many LTE-related siblings. An agent cannot reliably invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (host, port) with zero description coverage, and the description does not mention either parameter. The description adds no meaning to the parameters, leaving the agent to guess how host and port are used.
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 retrieves UE information and explicitly mentions connection state, giving a specific verb and resource. It does not explicitly distinguish from the sibling cmw_lte_get_connection_state, but the broader scope is implied by 'including connection state'.
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 like cmw_lte_get_connection_state. There is no mention of prerequisites, typical scenarios, or situations where another tool would be more appropriate.
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?
There are no annotations to convey safety or side-effect information, so the description must carry the burden. 'Trigger' alone does not disclose whether the operation blocks, performs a single-shot or continuous measurement, resets previous state, or returns any value, which is inadequate for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, which is efficient, but it is under-specified to the point of not fulfilling its informative role. It earns credit for being brief, but the brevity hurts clarity.
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?
Without annotations, an output schema, or parameter details, the description does not cover the tool's expected behavior, return format, or relationship to measurement configuration and fetch tools. For a trigger action among many related tools, this is insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists host and port with no descriptions, and the description mentions neither parameter. With 0% schema description coverage, the description should explain their purpose and the need for them, but it does not, providing no semantic value.
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 uses the specific verb 'Trigger' and identifies the target as 'GPRF power measurement,' making the tool's action clear. It distinguishes from sibling trigger tools like cmw_bt_trigger and cmw_wlan_trigger by specifying GPRF, though the acronym is not expanded.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as cmw_meas_set_trigger or cmw_meas_fetch_power. It does not mention prerequisites like prior configuration or how triggering relates to subsequent measurement fetching, leaving the usage context ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states only that results are fetched, but does not mention whether a measurement must be triggered beforehand, whether it is a read-only operation, or what happens if no measurement is available. The description lacks any behavioral context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple fetch tool, though it sacrifices substance for brevity. It earns a high score for structure but not a 5 because it skips valuable context that could be added without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should compensate by explaining what the EVM measurement results contain, any dependencies on other tools (e.g., cmw_lte_meas_trigger), or typical usage context. It does none of this, leaving the tool functionally ambiguous for an agent trying to decide how to interact with it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists 'host' and 'port' with only basic types and no descriptions, and schema description coverage is 0%. The description does not mention these parameters at all, so it adds no meaning about their purpose or format. The agent receives no help beyond the parameter names, which could be ambiguous in a network measurement context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and a clear resource 'LTE EVM (Error Vector Magnitude) measurement results', which distinguishes it from sibling fetch tools like cmw_lte_meas_fetch_power or cmw_lte_meas_fetch_aclr. It is not as explicit as a tool that explicitly names alternatives, but the resource is specific enough to make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 the many sibling fetch tools (e.g., cmw_lte_meas_fetch_all, cmw_lte_meas_fetch_power). The description gives no context about prerequisites such as triggering a measurement first or specific use cases, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'fetch results', implying a read operation, but omits any side effects, return format, or dependency on prior setup/trigger actions.
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 one concise sentence with no wasted words. It is front-loaded with the core action, though the lack of any structured additional context keeps it from being perfect.
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?
The tool has no annotations, no output schema, and only two opaque parameters. The description does not explain prerequisites, return values, or how this tool fits into the LTE measurement workflow, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning for the two parameters (host, port). It does not explain what these parameters are for, leaving the agent without any semantic information beyond the parameter names and types.
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 'Fetch LTE TX power measurement results' with a specific verb and resource. It distinguishes from other LTE measurement fetches (EVM, ACLR, etc.) by specifying 'power', but does not differentiate from the generic cmw_meas_fetch_power sibling.
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 prerequisites like configuring or triggering the LTE measurement, nor does it compare itself to similar tools like cmw_meas_fetch_power.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden, but only implies a read-only fetch. It does not disclose whether a prior measurement setup is required, what happens if no results exist, or any errors or side effects. 'Fetch' weakly signals non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the key action and object front-loaded. There is no wasted text, though it is minimal to the point of being under-specified in other dimensions.
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 measurement fetch tool with no output schema and no annotations, the description lacks critical context: expected return format, dependency on prior trigger/configuration, and relationship to sibling measurement tools. It is not complete enough for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no meaning for the host and port parameters. The parameter names hint at network address/port, but the tool does not compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and identifies the resource ('GPRF spectrum measurement results'), distinguishing it from sibling fetch tools like cmw_meas_fetch_power. However, it does not explicitly contrast with alternatives or describe the nature of the returned spectrum data.
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, nor any prerequisites such as configuring the measurement (cmw_meas_configure_spectrum) or triggering before fetching. The description simply states the action.
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. 'Query' implies a read-only operation, but the description does not state whether it requires a prior connection, what the response contains, or whether it has any 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundancy. However, it is so brief that it borders on under-specification, which prevents a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description leaves many gaps: it does not explain the returned data, the meaning of host and port, or the operational context. This is incomplete for a tool with two parameters and no structured documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (host, port) with 0% description coverage, and the description does not mention these parameters at all. The description adds no meaning beyond the raw schema, leaving the agent without any hints about parameter formats, defaults, or required values.
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 uses a specific verb ('Query') and a clear resource ('installed hardware and software options'), making the tool's purpose understandable. It is distinct enough from siblings like get_status or get_capabilities, though it does not explicitly differentiate from potentially overlapping tools.
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, nor does it mention any prerequisites (e.g., whether a connection must be established first). No context or exclusions 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Fetch... results', which implies a read operation but does not describe the return format, whether a measurement must be triggered beforehand, or any side effects. This is very minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the core action. It does not waste words, but it is under-specifying relative to the tool's complexity. Still, for brevity alone, it earns a solid score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema parameter coverage, the description needed to provide much more context. It does not mention measurement triggering, what a 'frequency error' result entails, or how the parameters relate to the operation. This is inadequate for a tool in a measurement suite with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no information about the parameters (host, port, meas_instance). Schema description coverage is only 33% (only meas_instance has a description), so the description needed to compensate for host and port but did not. The tool description is silent on all three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and the resource ('WLAN frequency error measurement results'), making the tool's purpose immediately understandable. While it does not explicitly distinguish itself from sibling tools like cmw_wlan_fetch_evm or cmw_wlan_fetch_power, the resource name is specific enough to avoid major ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites such as triggering a measurement first or configuring a WLAN connection. This is a significant gap for a tool that likely depends on a measurement setup sequence.
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 behavior. It only says 'fetch', implying a read operation, but does not explain whether triggering is required beforehand, what data structure is returned, or any side effects. This is minimal transparency for a measurement tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. However, the brevity comes at the cost of essential details, making it under-specified rather than efficiently complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and sparse description, the tool is not sufficiently contextualized. It does not mention return values, required instrument state, or how this relates to the WLAN measurement flow, leaving agents with too little information to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only 33% coverage (only meas_instance has a description), and the tool description does not elaborate on host, port, or meas_instance usage. The description adds no parameter-level semantics, leaving most parameters underspecified.
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 fetches WLAN TX power measurement results, using a specific verb and resource. However, it does not differentiate it from sibling tools like cmw_wlan_fetch_all or cmw_meas_fetch_power, which have overlapping purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of alternatives such as the generic cmw_meas_fetch_power or the comprehensive cmw_wlan_fetch_all. The description does not mention any prerequisites, setup steps, 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 only states that the tool triggers a measurement without describing side effects, asynchronous behavior, required prior state, or whether it returns results. This is a significant gap for a tool that likely starts a measurement process.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, front-loading the key verb and object. However, its brevity comes at the cost of missing important behavioral and usage context, so it does not fully earn its place. It is concise but under-specified.
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?
The tool has three parameters, no output schema, and no annotations. Given this complexity, the description is far from complete. It does not explain what the trigger does beyond the name, what happens after triggering, whether there are return values, or how the parameters relate to the measurement. It needs substantially more context to be useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only meas_instance has a description). The tool description does not mention any parameters, so it adds no value beyond the schema. Host and port remain completely undocumented, and the meaning of meas_instance is left to the schema's minimal note. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Trigger') and a specific resource ('WLAN multi-evaluation measurement'), which distinguishes it from generic measurement triggers and other technology-specific triggers (e.g., cmw_meas_trigger, cmw_lte_meas_trigger). However, 'multi-evaluation measurement' is somewhat ambiguous and does not clarify what is being evaluated, making it slightly less clear than a fully specified description.
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 such as cmw_wlan_set_trigger or cmw_wlan_trigger_catalog. It does not mention prerequisites (e.g., configuration steps) or whether this tool should be followed by fetch operations. The context is implied by the tool name and sibling list, but not explicitly stated.
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 only states that it sets a frequency, but does not disclose whether this is a write operation, whether it requires a connection, or whether it has side effects on other measurement settings. This is minimal for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words, making it concise and easy to parse. However, it is very terse and omits necessary context, sacrificing informational completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, no output schema, and no annotations, the description is inadequate. It does not state the expected workflow (e.g., configure BT first, then set frequency, then trigger), explain host/port, or note any constraints. The presence of many sibling frequency setters makes this even more important.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has descriptions for frequency_hz and meas_instance, and the description merely repeats the unit in Hz without adding new meaning. Host and port parameters lack schema descriptions, and the description does not explain them either. Thus, the description adds no value beyond the schema.
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 'Set Bluetooth measurement frequency in Hz' uses a specific verb ('Set') and resource ('Bluetooth measurement frequency'), with 'Bluetooth' clearly distinguishing it from sibling tools like cmw_gen_set_frequency and cmw_wlan_set_frequency. However, it does not explicitly contrast with cmw_meas_set_frequency, so it is clear but not fully differentiating.
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 such as cmw_bt_configure or cmw_meas_set_frequency, nor does it mention prerequisites or exclusions. The only implicit hint is the 'Bluetooth' in the name/description, which is not enough to guide selection among the many similar frequency-setting 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 must carry the full burden of behavioral disclosure. It only restates the tool's action without explaining what 'full configuration state' includes, whether the response is large, what format it takes, or whether it requires prior connection or has 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, front-loaded sentence with no filler or redundant information. It earns its place by stating exactly what the tool does in the fewest words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that retrieves 'full configuration state', the description is too sparse. It does not mention return value structure, output size, or any caveats such as connection requirements, making it inadequate given the lack of an output schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the 'host' and 'port' parameters. It does not explain whether port is the SCPI port, whether host is an IP or hostname, or whether a default port exists, leaving the parameters semantically opaque.
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 uses a specific verb ('Get') and resource ('current CMW500 full configuration state'), making the tool's purpose clear. It is distinct from siblings like cmw_get_status and cmw_get_capabilities by focusing on 'full configuration state', though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as cmw_get_status, cmw_get_capabilities, or cmw_query_options. There are no usage scenarios, exclusions, or notes about prerequisites like an active connection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states that it retrieves the connection state. It does not explain read-only behavior, potential side effects (e.g., triggering a measurement), or what happens if no UE is connected. The bare 'get' verb implies read-only, but no additional traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is concise and to the point. It avoids unnecessary verbosity, but it could benefit from including parameter context without becoming bloated, so it earns near-perfect marks for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no output schema, and no annotations, the description is severely under-specified. It lacks any context about the host/port parameters, what the returned state looks like, and how this relates to other LTE tools. The minimal statement is insufficient for an agent to confidently invoke the tool in a broader workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (host, port) with no descriptions, and the description provides zero explanation of how these parameters affect the operation. Since schema coverage is 0%, the description was expected to compensate, but it does not mention host or port at all, leaving the agent without any semantic understanding of these fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('Get'), the resource ('LTE UE connection state'), and provides concrete examples of the state values (ATT, CONN, IDLE), making the tool's purpose unmistakable. It distinguishes itself from broader tools like cmw_get_status or cmw_get_full_state by focusing on the LTE UE connection state specifically.
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?
There is no guidance on when to use this tool versus alternatives such as cmw_lte_get_ue_info or cmw_get_status. The description only states what it does, without mentioning prerequisites, typical scenarios, or exclusions, leaving the agent without direction on tool 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?
With no annotations, the description carries the full burden, but it only says 'Fetch' without disclosing whether it returns cached results, performs a new measurement, or requires prior setup. This leaves the agent uncertain about side effects and data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundant words, front-loaded with the verb and resource. It is concise and easy to scan, though it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and parameter descriptions, this sparse one-liner is far from adequate. It omits essential context about measurement prerequisites, return values, and how this tool fits into the LTE measurement workflow, making it nearly impossible to invoke correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not mention the two parameters (host, port) at all. Since there is no parameter explanation in the schema or description, the agent has no semantic understanding of how to supply these values correctly.
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 'Fetch' and resource 'LTE frequency error measurement results', which clearly distinguishes it from sibling tools like cmw_lte_meas_fetch_power or cmw_wlan_fetch_frequency_error. The purpose is unmistakable.
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 no guidance on when to use this tool, prerequisites such as prior configuration or triggering, or alternatives like cmw_lte_meas_fetch_all. It merely states the action without any contextual direction.
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 for behavioral disclosure. It only says 'fetch results' without revealing potential side effects, required setup, whether a measurement must be active, or what happens if no results are available. The description adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the primary action and object. It is not verbose, but it is also somewhat under-specified. It earns its place but could be expanded with additional useful context without becoming unwieldy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no output schema, and no annotations, this description is insufficiently complete. It does not explain return values, parameter dependencies, or how this tool fits into the measurement workflow. The complexity of the schema and the presence of many similar sibling tools call for more context than this one-liner provides.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: statistic and all_statistics have descriptions, but host and port do not. The tool description does not compensate for the undocumented host and port parameters, nor does it add meaning to the parameters beyond what the schema already states. The mention of current/average/max/min mirrors the enum values without explaining them further.
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 fetches GPRF power measurement results and lists the statistics available (current, average, max, min). This is a specific verb-resource pairing, but it does not explicitly contrast with sibling fetch tools (e.g., cmw_bt_fetch_power) to distinguish when this should be used for GPRF vs other technologies, though the GPRF label provides some distinction.
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, nor does it mention any prerequisites such as configuring or triggering a power measurement. Usage is only implied by the tool's name and description, with no explicit 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, the description must disclose side effects and behavior. It only says 'Set' and gives no indication of whether the setting persists, whether it applies to both generator and analyzer ports, or what side effects occur on invocation. This 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and every word contributes to the meaning. It is appropriately concise for a simple setter, though it lacks any structural breakdown of parameters.
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?
There is no output schema and no annotations, so the description must carry the full contextual burden. It gives no workflow guidance, no return behavior, and no relation to sibling tools like cmw_rf_route_set or cmw_set_signal_path. For a 4-parameter tool, this is barely above a minimal stub.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%, describing analyzer_port and generator_port but leaving host and port undocumented. The description adds no meaning for host/port and does not explain how the parameters map to the RF port connector, failing to compensate for the coverage gap.
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 uses a specific verb ('Set') and identifies the resource ('GPRF generator/analyzer RF port connector'), making the basic action clear. However, it does not differentiate from sibling tools like cmw_rf_route_set or cmw_set_signal_path, so an agent might not know which tool to pick.
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, nor any workflow context such as prerequisites or typical placement before measurements. The description consists solely of a statement of action.
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 carry the full burden of behavioral disclosure. It only states the action "disconnect" without revealing side effects, prerequisites (e.g., active connection), cleanup behavior, or impact on ongoing operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. However, it is arguably under-specified for a tool with parameters and behavioral context, though that is penalized in other dimensions.
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?
This is a simple tool with two parameters and no output schema, but the description omits context such as how to identify the connection (host/port), whether disconnection is global or connection-specific, or any relationship to cmw_connect. It is minimally functional but lacks necessary completion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the host and port parameters. The schema provides only types and no descriptions, so the agent cannot determine what values to supply or whether they are optional in practice.
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 "Disconnect" and names the resource "CMW500", clearly distinguishing it from sibling tools like cmw_connect and cmw_discover. It unambiguously states the tool's function.
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, such as after cmw_connect or when ending a test session. No alternative tools or exclusions are mentioned, leaving usage context entirely unstated.
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 full burden. It does not disclose side effects, whether it overwrites existing settings, requires an active connection, or what it returns. The description is purely functional.
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 that directly states the action and key parameters. It is front-loaded and contains no filler, making it efficient and easy to parse.
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 configuration tool with no annotations or output schema, this description is sparse. It does not explain the setup flow (e.g., use with cmw_lte_meas_trigger and fetch tools), requirements, or effects. Essential operational context is missing.
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 50% (repetition and stat_count have descriptions). The description names these two parameters but adds no additional meaning beyond the schema. The host and port parameters are completely unexplained, and no usage details are provided for any parameter.
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 uses the specific verb 'Configure' and identifies the resource as 'LTE multi-evaluation measurement', listing key parameters (subframe count, repetition). It clearly distinguishes this from sibling trigger/fetch tools, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool, prerequisites, or alternatives. It does not mention that configuration is typically followed by trigger and fetch operations, nor any 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 only states 'Fetch' without explaining whether a measurement must be triggered first, whether it is read-only, or what happens with stale data. Minimal transparency beyond the action itself.
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?
Single sentence with no redundant wording, front-loads the key action and measurement type. However, it omits needed context, so conciseness is good but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's role in a measurement workflow, the description doesn't mention the need for prior configuration/trigger or any connection details. It is minimally viable but lacks operational context to be used correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes host and port with zero descriptions, and the description does not explain their purpose. With 0% schema coverage, the description fails to compensate for the missing parameter semantics, leaving the agent without any meaning for the two 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?
Description uses specific verb 'Fetch' with resource 'LTE ACLR measurement results', clearly distinguishing it from sibling fetch tools for other measurements (power, EVM, SEM, etc.). The acronym expansion further clarifies the measurement type.
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 on when to use this tool versus alternatives like cmw_lte_meas_fetch_all or other measurement fetches. No mention of prerequisites such as configuring and triggering the ACLR measurement first, which is critical in a measurement workflow.
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 full burden. It merely restates the action implied by the name ('Fetch') without disclosing behavior such as whether the tool triggers a measurement, returns previously captured results, or requires prior setup. No added behavioral context beyond a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no wasted words. It is front-loaded and effectively communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and undocumented parameters. The description is too minimal to enable correct invocation; it omits connection semantics, return format, and any measurement workflow context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (host, port) with 0% schema description coverage, and the description provides no explanation of their meaning. The agent is left without any information about what host/port refer to, how they are used, or their formats.
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 'Fetch' and identifies a precise resource: 'LTE SEM (Spectrum Emission Mask) measurement results.' This clearly distinguishes it from sibling fetch tools like power, EVM, or ACLR.
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?
There is no guidance on when to use this tool versus alternatives, such as cmw_lte_meas_fetch_all or cmw_meas_fetch_spectrum. The description does not mention prerequisites like previous configuration or triggering, nor does it exclude other 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?
With no annotations, the description is the sole source of behavioral disclosure. It indicates a mutation ('Set') but does not mention side effects, persistence, connection requirements, or whether the margin resets measurements. The operation's impact on analyzer state is entirely unspecified.
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 waste. Every word contributes to the core meaning, and the verb is placed first. It is appropriately concise for a simple setter operation.
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?
The tool is simple, but the description lacks essential context such as how host and port are used, whether a prior connection is required, or what happens once the margin is set. With no annotations and no output schema, the description does not provide enough information for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, and the description adds no meaning beyond the schema. margin_db is documented as 'User margin in dB', but host and port are left unexplained. The description merely repeats the unit information already present in the schema, failing to compensate for the undocumented parameters.
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 uses a specific verb ('Set') with a clear resource ('GPRF analyzer user margin') and unit ('dB'), distinguishing it from other cmw_meas_set_* tools. It does not elaborate on what the margin affects, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as cmw_meas_set_trigger or cmw_meas_set_power_filter. The description does not mention prerequisites, contexts, or exclusions, leaving the tool to be selected by name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not state whether a prior trigger is required, how missing measurements are handled, or the format of returned results. This is insufficient for a fetch operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, fully front-loaded. It states the purpose efficiently, though it could be more detailed without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and low parameter documentation. The description does not explain the measurement workflow, result format, or prerequisites. This is inadequate for a 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics. Schema coverage is only 33% (only meas_instance has a description), and host/port are undocumented. Since coverage is below 50%, the description should compensate but does not.
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 action (Fetch) and the resource (WLAN spectrum flatness measurement results). It distinguishes this tool from siblings like cmw_wlan_fetch_power or cmw_meas_fetch_spectrum by specifically naming 'spectrum flatness'.
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, nor does it mention prerequisites such as prior configuration or triggering a measurement. It is a bare statement with no usage 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It simply says 'Configure' without stating whether this is a mutating operation, whether it requires an active connection, what happens on conflicting parameters, or how it interacts with the measurement instance. This is a significant transparency gap for a configuration 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, concise sentence that directly states the tool's purpose. There is zero waste or redundancy, and the key action and target are immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no annotations, no output schema), the description is too minimal. It lacks context about return values, prerequisite states, relationship to sibling setter tools, and potential side effects. This makes it incomplete for an agent to understand the full scope of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 75%, with 6 of 8 parameters having descriptions in the schema. The tool description adds no extra parameter semantics beyond what the schema already provides. Host and port lack descriptions, but the overall coverage is high enough that the description need not compensate extensively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Configure' and the resource 'Bluetooth/BLE non-signaling measurement', which is specific. However, it does not explicitly differentiate from sibling tools like cmw_bt_set_technology or cmw_bt_set_frequency, so it lacks distinction from those more granular alternatives.
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 aggregate configuration tool versus the individual cmw_bt_set_* commands. The description does not mention any alternatives, exclusions, or prerequisites, leaving the agent to infer 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states 'Fetch' without mentioning prerequisites (e.g., connection/configuration required), whether a measurement must be triggered first, or what happens if no results exist. No behavioral traits are exposed beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and resource. It is efficient and easy to parse, though it lacks any additional explanatory structure. This is appropriately sized for the small amount of information conveyed.
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?
There is no output schema, no annotations, and only minimal schema descriptions. For a measurement fetch tool, the description should explain return values or preconditions, but it only gives a terse statement. Compared to siblings with richer descriptions, this one is incomplete for guiding proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only meas_instance has a description). The description adds no meaning for host or port, failing to compensate for the low coverage. It does not explain how these parameters are used or their relationships, leaving the agent guessing.
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 ('Fetch') and resource ('Bluetooth frequency measurement results'), which is specific and distinguishes it from sibling tools like cmw_bt_fetch_power or cmw_bt_fetch_modulation. It directly communicates what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as cmw_bt_fetch_all or cmw_meas_fetch_frequency. The description lacks any contextual cues or exclusions, leaving the agent without direction on selecting this tool appropriately.
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 only says 'Fetch' without mentioning side effects, error conditions, or dependencies such as requiring an active connection or prior trigger. The read-only nature is implied 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly states the action. It is front-loaded and waste-free, though it lacks any supporting details or structure.
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 fetch tool with no output schema and no annotations, the description is minimal. It does not describe the return format, units, or prerequisite steps such as triggering a measurement, making it incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (meas_instance has a description), and the tool description does not explain host, port, or how meas_instance selects the measurement instance. The description adds no parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and clearly identifies the resource as 'Bluetooth modulation (DEVM) measurement results.' This distinguishes it from sibling tools like cmw_bt_fetch_power and cmw_bt_fetch_frequency, which fetch other measurement types.
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, whether a measurement must be triggered first, or any alternatives. It simply states the action without context 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, the description must carry the full burden of behavioral disclosure. It only says 'fetch ... results', but doesn't mention side effects, required setup, whether results are reset, or any return format details. Minimal 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 with no unnecessary words. It immediately conveys the action and object, making it highly concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 3 parameters, no annotations, and no output schema, the description is too sparse to be contextually complete. It does not explain host/port, the meaning of meas_instance beyond a default, or how this relates to other Bluetooth tools. A more detailed description is needed for adequate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only meas_instance has a description), and the description itself adds no parameter meaning. Host and port are left unexplained, and meas_instance is merely restated in the schema without elaboration. The description fails to compensate for the low schema 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 a specific verb and resource: 'Fetch Bluetooth TX power measurement results'. It distinguishes from siblings like cmw_bt_fetch_modulation and cmw_bt_fetch_frequency by specifying the exact measurement type.
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. There is no mention of prerequisites (e.g., prior configuration/trigger) or differentiation from cmw_meas_fetch_power, which also fetches power results.
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 carry the full burden of disclosing behavioral traits. 'Check' implies a read-only validation, but the description does not state whether the tool returns a pass/fail result, throws errors for undefined limits, or if it has side effects. It also does not clarify what 'defined limits' means in practice or how violations are reported. This lack of behavioral detail leaves significant uncertainty.
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 with no redundant words. It is front-loaded with the verb 'Check' and immediately conveys the tool's core function. Every word earns its place, and there is no padding or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description does not fully explain the tool's behavior or return format. The one-parameter input is simple, but the absence of any information about the result (e.g., boolean pass/fail, list of violated limits, error behavior) makes the tool incomplete for an agent that needs to know what to expect after invocation. The sibling tools for defining limits are not referenced, so the operational context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with a single 'measurements' parameter described as 'Dictionary of parameter:value pairs to check'. The description adds no additional parameter-level detail beyond the schema, so the baseline score of 3 applies. The schema's description is adequate, though it does not specify the expected value types or how limits are matched to parameters.
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 'Check measurement values against defined limits' clearly states the action (check) and resource (measurement values against defined limits). It distinguishes itself from sibling tools like cmw_define_limit and cmw_list_limits by focusing on the checking action rather than defining or listing limits. However, it does not specify what the check returns (pass/fail, exceptions), leaving some ambiguity about the tool's exact purpose.
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 offers no guidance on when to use this tool versus alternatives. It implies that limits must already be defined (since it checks against 'defined limits'), but it does not explicitly mention prerequisite steps like using cmw_define_limit first, nor does it describe scenarios where this tool is preferred over fetching raw measurements directly. No exclusions or alternative tool references are provided.
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 transparency. It only states the intent to define a limit, but does not mention whether defining overwrites existing limits, whether ranges are validated, or any side effects. This is minimal for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly conveys the core purpose without wasted words. It is appropriately sized, though it is on the minimal side and could include a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters and no annotations or output schema, the description is quite incomplete. It does not explain how limits are used, how they relate to the sibling check/list/clear operations, or what happens after defining a limit. The limited context leaves the agent under-informed for proper tool selection and invocation.
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% description coverage for all five parameters, so the schema already documents each parameter. The description does not add any extra meaning beyond what the schema provides, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Define') and resource ('pass/fail limit') with a clear purpose ('for measurement checking'). It distinguishes from sibling limit tools like cmw_check_limits, cmw_clear_limits, and cmw_list_limits because 'define' is unique. However, it could be more specific about creating named limits with min/max values.
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 does not provide any guidance on when to use this tool versus alternatives such as cmw_check_limits or cmw_clear_limits. It implies a use case for measurement checking but gives no explicit context, 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, the description carries the full burden of behavioral disclosure. It only states the action and mode values, but does not mention whether the change takes effect immediately, requires a trigger, or impacts current waveform playback, which are relevant operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler. It is front-loaded with the verb and resource, and the parenthetical enumeration adds immediate 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 configuration tool with no output schema and only one meaningful enum parameter, the description is minimally viable. However, it omits any mention of host/port semantics, prerequisites, or behavioral effects, so it falls short of fully equipping an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (1 of 3 parameters). The description adds the enumeration 'continuous/single' for the repetition parameter, but host and port are entirely undocumented in both schema and description. The low coverage is not compensated.
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 configures ARB waveform playback mode and lists the two possible modes (continuous/single). It identifies a specific verb and resource, and the sibling tools like cmw_gen_load_arb and cmw_gen_output_on/off are distinct enough in name and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as cmw_gen_load_arb or cmw_gen_output_on/off. The context of needing a loaded ARB waveform or output state is not mentioned, leaving the agent to infer 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, the description carries the full burden for behavioral disclosure. It only implies a read operation via 'Get' but does not disclose side effects, prerequisites (e.g., connection), return format, or any operational caveats. For a simple getter, more context could be expected.
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 front-loads the core action. There is no redundancy or extraneous information, making it well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema or annotations, the description is minimal. It does not explain the meaning of 'signal path scenario', what the return value represents, or how host/port are used. While the brevity matches a getter, it leaves significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention the 'host' or 'port' parameters. Their purpose (likely connection settings) is not explained, leaving the agent with no semantic guidance beyond bare type names. The description adds no value for parameter understanding.
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 'Get current GPRF signal path scenario' clearly states the verb ('Get') and resource ('current GPRF signal path scenario'), distinguishing it from sibling tools like cmw_set_signal_path (setter) and cmw_get_full_state (broader state). It is 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 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 simply states what it does without mentioning prerequisites, exclusions, or related tools. The description does not help the agent choose between this and similar getters like cmw_rf_route_get.
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 only says 'Configure' without disclosing side effects, whether a connection is required, what host/port are used for, or if changes are reversible. This leaves substantial behavioral ambiguity for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise in length. However, it is under-specified: essential information like host/port semantics and usage context is missing. It is short but not efficiently complete, so it earns a middle score.
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 4 parameters, no output schema, and no annotations, the description is inadequate. It does not explain host/port, the role of NAS parameters in the broader LTE workflow, or the expected outcome. Given the large sibling set, more contextual detail is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: mcc and mnc are described, but host and port are not. The description only repeats the two named parameters and offers no explanation of the undocumented ones, nor additional constraints or relationships. It fails to compensate for the coverage 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 uses the specific verb 'Configure' and the resource 'LTE NAS parameters' with the scope '(MCC, MNC)'. This clearly distinguishes it from sibling tools like cmw_lte_configure_cell or cmw_lte_configure_bearer, which target different LTE aspects.
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. There is no mention of prerequisites, use cases, or exclusions. The description is too minimal to communicate any usage context beyond the obvious naming.
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 does not mention whether this is a configuration change, whether it triggers a measurement, or if it requires an established connection. No side effects or state changes are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately sized for the tool's simple purpose.
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?
The tool has no output schema, no annotations, and two undocumented optional parameters. The description fails to explain the role of host/port, whether a connection is required, or how this setting fits into the broader measurement workflow. It is too sparse for an agent to use it confidently without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only frequency_hz is described). The description adds no meaning for host and port parameters, which are left completely undocumented. It merely repeats the 'Hz' unit already present in the schema for frequency_hz.
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 uses a specific verb ('Set') and resource ('GPRF analyzer measurement frequency') with units ('Hz'). It distinguishes from sibling tools like cmw_gen_set_frequency by specifying the analyzer measurement context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description only states the action, leaving the agent to infer usage context from the name and sibling 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 of disclosing behavioral traits. It only states that it sets trigger values, but does not mention side effects, whether a connection is required, if settings persist, or how invalid inputs are handled. Minimal transparency for a configuration mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb 'Set'. It is efficient and free of fluff, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no annotations, and no output schema, the description is too sparse. It omits when to use the tool, any state requirements, side effects, and return behavior, leaving the agent with insufficient context to invoke it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, with host and port lacking descriptions. The description names 'source and threshold' but adds no meaning beyond the schema's own field descriptions. It does not compensate for the undocumented parameters or clarify allowed values or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Set' with a clear resource 'GPRF measurement trigger' and names the attributes 'source and threshold'. It clearly distinguishes from sibling tool 'cmw_meas_trigger' by emphasizing configuration rather than triggering a measurement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no mention of prerequisites. It simply states the action, leaving the agent to infer usage context from the name and schema.
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 full responsibility for behavioral disclosure. It implies a reset to default state but does not mention potential side effects (e.g., losing unsaved settings), whether a connection is assumed, or whether it affects only the specified host/port or all instruments.
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 conveys the essential purpose without superfluous words. It is concise and well-structured for a simple reset operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the absence of output schema or annotations, the description is minimally complete but lacks important context about when to use it, what happens to the instrument, and how host/port affect the operation. It leaves the agent to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes two parameters (host and port) with zero description coverage. The tool description does not explain their purpose, how they relate to the reset operation, or why they are optional. No additional meaning is provided 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 (Reset) and target (CMW500) with a specific detail (*RST), making it unambiguous and distinguishing it from similar tools like cmw_preset. The verb-resource pair is specific and the scope is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as cmw_preset, cmw_system_all_off, or cmw_clear_limits. It lacks context about prerequisites or situations where a reset is appropriate.
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 only says 'send query and return response' and does not disclose connection requirements, response format, error behavior, or the fact that queries are typically side-effect-free.
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 one concise sentence with no fluff, which is appropriately sized for the limited information it provides. However, it lacks necessary detail, making it under-specified rather than optimally concise.
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, no annotations, and low parameter coverage, the description is incomplete. The existence of the very similar sibling cmw_scpi_send is not referenced, and there is no explanation of return format or connection requirements, leaving the tool under-contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'command' is described). The description text adds no parameter info beyond the schema, merely repeating 'SCPI query'. Host and port semantics remain undocumented, and the description does not compensate for this 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 'Send SCPI query and return response' clearly states the action (send), the resource (SCPI query), and the outcome (return response). It distinguishes from the sibling cmw_scpi_send by explicitly mentioning 'query' and 'return response', which implies a read operation.
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 cmw_scpi_send. It does not mention prerequisites (e.g., connection) or exclude any use cases, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of disclosing behavioral traits. It only says 'Set... scenario' without mentioning that it changes instrument state, persists settings, requires a connection, or has any side effects. The term 'combined' is ambiguous relative to the enum value 'cspath,' adding confusion rather than clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the core action and target. However, it uses 'combined' while the schema uses 'cspath,' which may confuse and reduce the efficiency of the concise phrasing. Minor waste but mostly well-structured.
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?
The tool is a setter with no output schema and no annotations, so the description needs to explain the effect and context. It fails to describe what the signal path scenario does, how it impacts measurements, or what the arguments (host/port) mean. Sibling tools like cmw_get_signal_path exist but are not referenced, leaving the 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 low (33%). The description partially clarifies the 'scenario' parameter by mapping 'standalone or combined' to the enum values, but it does not explain 'cspath' explicitly. More importantly, 'host' and 'port' are not described at all in either the schema or the description, leaving the agent without guidance on these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the target resource ('GPRF measurement signal path scenario'), and distinguishes it from sibling tools like cmw_get_signal_path which retrieves the path. The addition of '(standalone or combined)' specifies the key parameter's possible values, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as cmw_get_signal_path or cmw_rf_route_set. There are no prerequisites, side effects, or context about setup steps. The only implied usage is from the verb 'set,' but the description does not explicitly state when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It states the action (turn off) but does not explain side effects (e.g., whether settings are preserved, whether it is reversible, or if it affects all RF paths). This is a significant gap for a system-wide operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action efficiently. Every word is relevant, with no filler or repetition.
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 simple tool with two parameters and no output schema, the description is minimal but lacks important context. It does not explain the scope of 'all generators and measurements' (e.g., does it include all signal paths? does it reset configurations?), nor does it mention safety implications beyond the vague 'safe state'. The absence of annotations makes this more incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the parameters (host, port) or their purpose. The agent receives no help in understanding that these likely identify the CMW instrument connection. The description fails to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (Turn off) targeting a specific resource (all generators and measurements), with an added note about safe state. This distinguishes it from sibling tools like cmw_gen_output_off which affects a single generator.
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. The term 'safe state' implies an emergency or shutdown scenario, but there is no explicit instruction or comparison to other tools such as cmw_reset or cmw_preset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Configure' implies a write operation, but it doesn't state whether it requires an active connection, whether it resets other settings, or whether it triggers a measurement. This is a significant transparency 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?
One short sentence, front-loaded with verb and object. It wastes no words and quickly conveys the core functionality.
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 7-parameter configuration tool with no annotations and no output schema, the description is too minimal. It doesn't explain host/port usage, return behavior, or how this tool relates to trigger/fetch operations. An agent might know it configures something, but not enough to invoke it correctly in a broader workflow.
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 documents 5 of 7 parameters with descriptions. The description mentions 'standard, BW, freq, power' but adds no new information beyond the schema. Host, port, and meas_instance are not covered in the description, and host/port also lack schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Configure' and identifies the resource 'WLAN non-signaling measurement' with the key configurable aspects (standard, BW, freq, power). This distinguishes it from sibling set_* commands, though it doesn't explicitly state that it combines multiple settings in one call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus individual setters like cmw_wlan_set_standard or cmw_wlan_set_frequency. It doesn't mention batching, ordering, or prerequisites, leaving the agent to infer usage context from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Fetch,' which is a weak indicator of read-only behavior. It does not disclose return format, whether a prior trigger is required, or any potential 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff, but it is too minimal to be considered appropriately sized. For a tool with three parameters and no annotations, the description omits essential context, so brevity is not a virtue here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and the presence of related measurement setup tools, the description does not explain the WLAN measurement lifecycle or return behavior. It is incomplete for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only meas_instance has a description), and the tool description does not explain host or port. The description adds no parameter meaning beyond the schema, failing to compensate for the low 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 uses the specific verb 'Fetch' and names the resource 'WLAN EVM (Error Vector Magnitude) measurement results,' clearly distinguishing it from sibling tools like cmw_wlan_fetch_power or cmw_wlan_fetch_frequency_error. The WLAN prefix differentiates it from the LTE EVM fetch tool.
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 like cmw_wlan_fetch_all, nor any prerequisites such as configuring a WLAN standard, setting frequency, or triggering a measurement before fetching. The description implies usage but gives no 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Set', implying a mutation, but does not disclose side effects, required setup, whether the value persists, or what happens if the instrument is not in the right state. This is a significant gap for a state-changing 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 concise, front-loaded sentence that directly states the action and target. It contains no redundant or extraneous words.
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 having 4 parameters, no output schema, and no annotations, the description provides minimal context. It does not clarify the role of host, port, meas_instance, or the expected behavior or side effects. An agent would lack enough guidance to use this tool correctly in a larger workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes 'power_dbm' as 'Expected power in dBm', so the description's 'in dBm' adds no new meaning. Host, port, and meas_instance semantics are not explained in the description, and schema coverage is only 50%, leaving those parameters under-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Set'), a specific resource ('Bluetooth expected input power'), and the unit ('in dBm'). This distinguishes it from sibling tools like cmw_wlan_set_expected_power or cmw_meas_set_expected_power by naming the Bluetooth context.
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 no guidance on when to use this tool versus alternatives, such as cmw_meas_set_expected_power or cmw_wlan_set_expected_power. It also does not mention prerequisites like configuring Bluetooth measurement or making a connection.
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?
There are no annotations, so the description must carry the behavioral disclosure burden. It merely states 'Load ARB waveform file' without explaining side effects, error conditions, or whether it overwrites existing waveforms. No details about success/failure responses are provided.
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 is direct and front-loaded. Every word is meaningful, with no filler or 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?
The tool has no annotations, no output schema, and a minimal 3-parameter schema, yet the description only gives a one-line summary. It lacks context about prerequisites, side effects, or relationship to other generator setup tools, making it incomplete for an agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only file_path is described). The tool description does not explain any parameters, including the ambiguous host and port. It adds no meaning beyond the schema and fails to compensate for the low 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 action 'Load' the specific resource 'ARB waveform file' and the target 'CMW500 generator'. It is distinct from sibling tools like cmw_gen_configure_arb, which implies configuration rather than loading.
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 or prerequisites. There is no mention of required prior steps (e.g., connection) or how it relates to other generator tools like cmw_gen_configure_arb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure, but it only restates the action. It does not disclose effects such as whether output turns on immediately, any needed prior setup, or how to disable. No behavioral detail is added beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, front-loading the action. It is concise and well-structured, though under-specified.
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?
The description is minimal and lacks context for a new agent: no usage timing, no parameter explanation, no relation to related generator tools like cmw_gen_set_frequency or cmw_gen_output_off. Although the tool is simple, the missing guidance makes it 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?
The schema has no descriptions for host and port, and the description does not mention them at all. With 0% schema coverage, the agent receives no semantic guidance. Host/port are self-explanatory to some extent, but the description fails to clarify their role (e.g., connection target) or optionality.
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 ('Enable') and resource ('GPRF generator RF output'), clearly distinguishing it from sibling cmw_gen_output_off. It states exactly what the tool does with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., configuring frequency or level first) or that cmw_gen_output_off is the inverse. Usage context is only implied by the name.
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 only states the action ('Set frequency') but does not clarify whether a connection is required, what happens on out-of-range frequencies, whether the change affects current output, or what the tool returns. 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, direct sentence with no wasted words. Every word contributes to the core meaning, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is extremely bare. It omits necessary context about connection prerequisites, the role of host/port, expected return values, and potential side effects. The description is minimally viable but clearly incomplete for an agent to invoke the tool correctly in varied situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 33% (only frequency_hz is described). The description merely repeats 'frequency in Hz' which is already in the schema, and it says nothing about 'host' or 'port' parameters. It adds no meaningful semantic value beyond what the schema already provides.
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 uses a specific verb ('Set') and a specific resource ('GPRF generator output frequency') with units ('Hz'). It is unambiguous and distinguishes itself from sibling tools like cmw_gen_set_level (sets level) and cmw_gen_output_on/off (controls output).
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. It does not mention any relationship to other generator setup tools (e.g., setting frequency before enabling output) or any prerequisites. The usage context must be inferred entirely from the tool name.
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 fully disclose behavior. It only states the action without mentioning side effects, prerequisites, reversibility, or what state changes occur. There is no information about whether the operation is safe, requires prior setup, or has any impact on other tools.
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 with a helpful parenthetical clarification. It is front-loaded with the core action and contains no unnecessary words or structure.
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 is insufficient for a mutation tool. It fails to explain parameters, return behavior, preconditions, or consequences, leaving critical gaps for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (host, port) with zero description coverage, and the description does not mention them at all. The agent receives no guidance on what values to provide or their purpose, making parameter handling entirely opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Turn on LTE cell' and clarifies with '(start base station emulation)', making the specific action and resource unambiguous. It naturally distinguishes itself from siblings like cmw_lte_cell_off and cmw_lte_configure_cell.
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 by indicating it starts base station emulation, but it provides no explicit guidance on when to use it versus alternatives or what preconditions exist (e.g., needing configuration first). It lacks any when-not-to-use or alternative references.
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 communicate behavioral traits. It only says 'Configure', indicating a mutation, but gives no details about side effects, required prior setup (e.g., LTE cell must be on), or whether changes are reversible. It also omits any mention of return values or errors, leaving the agent uncertain about the operational impact.
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 immediately conveys the core action and objects ('Configure default EPS bearer (APN and IP version)'). It contains no filler or redundant details, making it highly efficient and front-loaded.
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?
The tool has four parameters, no output schema, and no annotations, yet the description provides only a minimal overview. It does not explain the purpose of host and port, specify expected outcomes, or describe any operational constraints. For a configuration tool with this complexity, the description is insufficiently complete to guide correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'APN and IP version', which maps to the apn and ip_version schema parameters, but these already have descriptions in the schema. The host and port parameters have no descriptions in either the schema or the tool description, and the description does not clarify their role or relationship to the bearer configuration. With 50% schema coverage and no compensating explanation, the semantics for half the parameters remain ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Configure' and the specific resource 'default EPS bearer', while explicitly listing 'APN and IP version' as the configurable aspects. This distinguishes it from sibling LTE tools like cmw_lte_configure_cell (cell configuration) and cmw_lte_configure_nas (NAS configuration), which address different configuration targets.
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 usage guidance is provided. The description does not state when to use this tool versus alternatives, nor does it mention any prerequisites, exclusions, or typical scenarios. The only hint is the tool name and the phrase 'default EPS bearer', which implies a specific context but offers no actionable direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'Configure ... enable/disable', which implies a write operation but does not disclose side effects, required instrument state, error behavior, or whether the change is persisted across sessions or only applied temporarily.
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 filler. Every word contributes to stating the tool's core operation, making it appropriately concise.
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 configuration tool with three parameters, no annotations, and no output schema, the description is too sparse. It omits host/port semantics, usage prerequisites, expected return values, and interactions with other LTE tools, leaving significant gaps for an agent to resolve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, with only 'enabled' having a description. The description adds minimal meaning for 'enabled' via 'enable/disable' but provides no context for the undocumented 'host' and 'port' parameters, which are likely connection details the agent would need to understand to invoke the tool correctly.
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 'Configure' and clearly identifies the resource 'Connected DRX (C-DRX)' with the scope 'enable/disable'. It distinguishes this tool from sibling LTE configuration tools like cmw_lte_configure_cell, cmw_lte_configure_nas, and cmw_lte_configure_bearer by noting the unique C-DRX resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, nor any prerequisites such as needing an active LTE connection or cell configuration. The description merely states the operation, leaving the agent to infer usage context from the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 lists the data to be fetched (power, EVM, ACLR, SEM) but does not mention any prerequisites (e.g., measurement configuration/trigger), return format, or error behavior. The description adds minimal context beyond the basic fetch action.
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 immediately communicates the tool's function and scope. There is no redundant wording, and the key information is front-loaded, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no parameter descriptions, the description needs to provide comprehensive context. It only covers the basic purpose and leaves out parameter semantics, usage conditions, and result details, making it insufficient for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters. The description does not mention 'host' or 'port' at all, leaving these parameters entirely undefined. This is a critical gap for an agent to understand how to invoke the tool.
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 action ('Fetch') and the resource ('all LTE measurement results'), and it enumerates the measurement types (power, EVM, ACLR, SEM). This distinguishes it from sibling tools like cmw_lte_meas_fetch_power, cmw_lte_meas_fetch_evm, etc., making the purpose highly clear.
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 use case is implied by the word 'all' – this is for retrieving all LTE measurement types in one call. However, there is no explicit guidance on when to prefer this over individual fetch tools, nor any exclusions or prerequisites. The guidance is inferred rather than stated.
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 of behavioral disclosure. It only states the action 'Set' and provides no context about side effects, required prior setup, valid frequency ranges, or whether the change is reversible. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the core action. It contains no filler or redundant elaboration, making it appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters and no output schema, the description is too sparse to fully contextualize the operation. It does not explain whether this sets the RF carrier frequency for WLAN measurement, whether it depends on other settings like standard or bandwidth, or what the tool returns after execution. The complexity of the domain and sibling toolset demands more.
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 50%, but the description adds no meaning for the undocumented 'host' and 'port' parameters. It merely restates the unit 'Hz' that already appears in the frequency_hz parameter description, and does not clarify the semantics of 'measurement frequency' or the role of meas_instance.
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 'Set WLAN measurement frequency in Hz' uses a specific verb ('Set'), specifies the resource ('WLAN measurement frequency'), and includes the unit. It is clear and distinguishes from siblings like cmw_meas_set_frequency by the WLAN qualifier.
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 such as cmw_meas_set_frequency or cmw_gen_set_frequency. It does not mention prerequisites, exclusions, or that it is the WLAN-specific configuration path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits, but it only states the action. It does not disclose side effects (e.g., whether setting the standard resets existing measurements, requires a connection, or takes effect immediately), leaving the agent without crucial operational 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 a single, efficient sentence with no filler. It front-loads the action and resource, and every word adds value.
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 mutation tool with no output schema and minimal annotations, the description is too sparse. It lacks any mention of when the standard can be changed, whether it affects other WLAN settings, or what success/error responses look like. Contextual details are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% (standard and meas_instance have descriptions; host and port do not). The description lists the enum values, but the schema already does that, and it adds no explanation for host/port or their roles, failing to compensate for the coverage 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 uses the specific verb 'Set' and identifies the exact resource ('WLAN 802.11 standard') with the accepted values (A/B/G/N/AC/AX). This clearly differentiates it from sibling tools like cmw_wlan_set_bandwidth or cmw_wlan_set_frequency.
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 prerequisites, interdependencies with other WLAN settings, or scenarios where a different tool (e.g., cmw_wlan_configure) would be more appropriate.
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 only says what data is fetched, but does not disclose whether measurement must be triggered first, whether results are cached, what happens if no measurement data exists, or any side effects. The description is minimal and does not provide meaningful behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. It is appropriately sized for a simple fetch tool, though it omits potentially useful context. No word is wasted, but the brevity becomes a drawback in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and the presence of sibling tools that provide detailed measurement fetches, the description is incomplete. It does not explain return value structure, prerequisites for calling this tool, or how errors are handled. The tool appears to aggregate multiple measurements, but the description does not elaborate on the combined result format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 33%, with host and port lacking any description. The tool description does not compensate for this, providing no details about what host and port refer to or how meas_instance is used. The description adds no parameter semantics beyond what the schema already offers.
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 fetches all Bluetooth measurement results and explicitly enumerates the types (power, modulation, frequency). This distinguishes it from sibling tools like cmw_bt_fetch_power, which only fetch individual measurement types.
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 context by mentioning 'all' results, which contrasts with sibling tools for individual measurements. However, it does not explicitly state when to prefer this tool over the individual fetch functions, nor does it mention any prerequisites or conditions. Usage guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention side effects, reversibility, or whether this operation turns on the output. It simply says 'Set output level', leaving the agent unaware of any consequences or prerequisites.
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 fluff. It efficiently communicates the core action and resource, appropriate for a simple setter.
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 low complexity (one required parameter, no output schema), the description is adequate but minimal. It lacks information about return values, errors, or interaction with other generator states, but for a simple setter it may be sufficient. Still, no annotations or output schema increase the burden, leaving gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only level_dbm has a description). The tool description adds 'in dBm' which merely restates the schema's own description for level_dbm. It provides no additional meaning for host or port parameters, failing to compensate for the low schema 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 verb 'Set' and the resource 'GPRF generator output level', with the unit 'in dBm'. This distinguishes it from sibling tools like cmw_gen_set_frequency (frequency) and cmw_gen_output_on/off (enable/disable).
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. There is no mention of prerequisites (e.g., connected instrument, output enabled) or context like 'use after setting frequency'. The description only states the action, not the usage 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 carries the full burden of behavioral disclosure. It only says 'configure', which implies mutation, but does not disclose whether the operation is destructive, requires specific conditions, changes are immediately applied, or what side effects occur. This is a significant gap for a configuration 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 concise sentence that front-loads the verb and target, and lists the key parameter categories. Every word contributes to clarity, with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the one-line description is insufficient. It does not explain the expected behavior, return values, prerequisites, or how it fits into the broader LTE workflow (e.g., need for cell on/off). Many sibling tools exist, and this description does not provide enough context for an agent to select and use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 67% of parameters with descriptions, and the description maps well to the core parameters: band, bandwidth_mhz (BW), dl_earfcn (EARFCN), and dl_level_dbm (DL level). However, host and port are left unexplained in both schema and description, and the description does not add deeper semantic detail beyond naming the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Configure') and the target resource ('LTE cell parameters'), and lists specific parameter types (band, BW, EARFCN, DL level). This distinguishes it from other LTE configuration tools like cmw_lte_configure_nas or cmw_lte_configure_bearer, which target different aspects.
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 no guidance on when to use this tool versus alternatives. While the name implies it is for configuring LTE cell parameters, there is no explicit mention of prerequisites (e.g., cell must be off), or when to prefer other configuration tools. Users are left to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects and behavioral traits. It only states that it sets a filter, but does not mention whether changes are immediate, persistent, affect ongoing measurements, or require prior connection/configuration. The 'Set' action implies mutation, but no safety or error information is provided.
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 that is direct and front-loaded with the verb and object. Every word carries meaning, with no filler or redundancy. It is appropriately concise for a simple setter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, the description is insufficient. It does not clarify valid filter_type values (e.g., 'GAUSs' case sensitivity), whether bandwidth_hz is required for certain filter types, or whether host/port refer to the instrument connection. An agent would need additional context to invoke this 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?
Schema coverage is 50%, with filter_type and bandwidth_hz described in the schema. The description adds minimal meaning by pairing the tool name's 'filter type and bandwidth' to those parameters, but host and port remain undocumented in both schema and description. The description partially compensates but does not fully clarify parameter usage, e.g., accepted filter_type values beyond the schema's partial 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 uses a specific verb 'Set' and clearly identifies the resource 'GPRF power measurement filter' plus the two attributes (type and bandwidth). This distinguishes it from sibling tools like cmw_meas_set_trigger or cmw_meas_set_frequency, 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 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, nor are any prerequisites or exclusions mentioned. The description implies it is for configuring a power measurement filter, but it does not explain the setup context (e.g., must be after configure_power) or why one would choose it over related measurement setters.
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 disclose behavioral context, but it only states the action ('Set') without detailing side effects, reversibility, or dependencies on measurement instances. It does not mention whether the change persists or affects subsequent operations, leaving significant behavioral ambiguity.
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 filler. Every word contributes to conveying the core function, making it highly efficient and easy to parse.
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 being a simple setter, the tool has four parameters and no output schema or annotations. The description only explains the primary parameter (packet_type) and ignores the host, port, and measurement instance entirely. This is incomplete for confident invocation, especially given that host/port are ambiguous and could be misinterpreted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with host and port lacking any description. The tool description adds no parameter semantics beyond the schema, merely echoing the packet type values already enumerated. It fails to compensate for the undocumented host and port parameters, which are essential for targeting the instrument.
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 action ('Set') and the resource ('Bluetooth Classic packet type'), and even enumerates examples (DH1/DH3/DH5/etc.). This distinguishes it from sibling tools like cmw_bt_set_frequency or cmw_bt_set_technology, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when configuring Bluetooth Classic packet type, but it does not explicitly state when to use this tool versus alternatives or mention any prerequisites (e.g., connection state). No exclusions or alternative tool references are provided, so guidance is only 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?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states the action without mentioning side effects, prerequisites (e.g., generator must be off), or impact on other settings. 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, focused sentence with no filler. It front-loads the verb and resource and includes example values, making it easy to scan.
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 simple setter with no output schema and no annotations, the description is minimally viable but still lacks essential context about when to use it, parameter meanings (especially host/port), and behavioral consequences. The 'etc.' hints at additional modes but does not expose the full enum or any constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'mode' has a description), and the tool description itself adds little beyond naming CW/ARB. It does not explain the 'host' and 'port' parameters, which are left undocumented in both the schema and 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 action ('Set GPRF generator baseband mode') and the specific resource (baseband mode), with examples of valid modes (CW, ARB). This distinguishes it from sibling tools like cmw_gen_set_frequency and cmw_gen_set_level, which target other settings.
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 configuring the generator's baseband mode, but provides no explicit when-to-use vs. alternatives or exclusions. It is longer than a pure tautology but lacks comparison to cmw_gen_load_arb or cmw_gen_configure_arb, which might also affect baseband behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It explicitly mentions the SCPI command (*IDN?) and the returned data, making clear this is a read-only query. It does not mention any side effects or connection requirements, but for a simple identification query this is sufficient.
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-loads the action, and efficiently packs the command plus expected output fields with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two undocumented parameters and no output schema, the description is too sparse. It does not explain how host/port should be provided, whether a connection is required, or what happens on failure. The simplicity of the operation is not enough to compensate for missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention host or port at all. The parameters are completely undocumented, and the description provides no compensation for this lack of meaning beyond what the raw names imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('CMW500 identification'), and clearly enumerates the returned fields (manufacturer, model, serial, firmware). This distinguishes it from sibling tools like cmw_get_status or cmw_query_options.
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, nor any mention of prerequisites such as an established connection. The description simply states what the tool does, leaving the agent to infer usage 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Load and restore' but does not mention that this action likely overwrites the current device state, may require an active connection, or any other side effects. For a state-modifying tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. Every word earns its place, and it is appropriately sized for the tool's simplicity.
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?
The tool has only 3 parameters and no output schema, but it is a mutation operation (loading state) with significant side effects. The description does not cover prerequisites, behavior on execution, or how the host/port parameters relate to the operation. This is incomplete for a state-restoring tool, especially given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only filename is described). The tool description does not compensate by explaining the role of 'host' and 'port' parameters, nor does it add any syntax or format details beyond the schema's filename note. The description adds no parameter-level meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Load and restore') on a specific resource ('CMW500 state') from a file. This distinguishes it from sibling tools like cmw_save_state (the inverse operation) and cmw_load_template (which loads templates, not full state).
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 restoring a previously saved state, but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It is clear enough that this is the inverse of cmw_save_state, but lacks explicit 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 carries the full burden. It states the basic save action but omits important behavioral details such as file overwrite behavior, file location, whether the .json extension is auto-added, and whether a connection to the CMW500 is required. This is a meaningful gap for a state-changing 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 filler. It is concise and readable, earning full marks for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, four parameters, and two undocumented params, the description is too terse to be complete. It does not explain the file naming convention, host/port usage, return value, or relationship to loading state, leaving critical context unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema documents only notes and filename; host and port have no descriptions. The description adds no parameter-specific guidance and does not compensate for the 50% schema coverage gap. A user/agent is left guessing the purpose of host and port.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is specific: 'Save current CMW500 state to file' clearly identifies the verb (save), resource (CMW500 state), and destination (file). It distinguishes from the sibling tool cmw_load_state, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied (use when you want to persist the current instrument state), but the description does not explicitly state when to use this tool vs. alternatives like cmw_load_state or cmw_list_templates. No exclusions or preconditions are mentioned.
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 available, so the description carries the full burden. It only states the operation and value type, but it does not disclose side effects, prerequisites (e.g., connection status or configured WLAN signal), persistence of settings, or response behavior. This 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, front-loaded sentence. It is free of redundancy and every word contributes to the core purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 no annotations and no output schema, a one-sentence description is insufficient. It leaves gaps such as prerequisites, whether the setting affects the current measurement instance or persists across calls, and how host/port are used. The description is not complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (power_dbm and meas_instance have descriptions; host and port do not). The description adds no new parameter semantics beyond repeating 'dBm' for power_dbm, and it does not clarify the roles of host/port or meas_instance. With low coverage, the description should compensate, but it does not.
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 'Set WLAN expected input power in dBm' clearly states the action (set), the resource (expected input power), and the unit (dBm). It distinguishes this tool from sibling tools like cmw_bt_set_expected_power and cmw_meas_set_expected_power via the explicit 'WLAN' qualifier.
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 WLAN-related configurations, but it does not explicitly state when to use this tool versus alternatives such as cmw_bt_set_expected_power or cmw_meas_set_expected_power. No exclusions or alternative references are provided, leaving the context as 'implied' rather than clearly guided.
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 full responsibility for behavioral disclosure. It only states the operation is a 'Set' action, without explaining side effects, persistence, prerequisites, or whether it targets a specific measurement instance. The parenthetical mode list adds detail but not 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 a single concise sentence that front-loads the action and includes the key mode alternatives. Every word adds value with no 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?
For a tool with 4 parameters, no output schema, and no annotations, the description is minimal. It omits context about targeting an instrument (host/port) and selecting a measurement instance, which are essential for effective invocation. The description only addresses the ble_mode parameter, leaving the other parameters under-explained.
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 50% (host and port lack descriptions). The description adds a plain-language mapping for ble_mode (1M, 2M, Coded S2/S8) but does not explain host, port, or meas_instance. It partially compensates for the schema gaps but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set BLE PHY mode' and specifies the allowed values (1M, 2M, Coded S2/S8). This distinguishes it from sibling tools like cmw_bt_set_frequency or cmw_bt_set_packet_type, which target different aspects of BLE configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the name and description: use when you need to configure BLE PHY mode. However, there is no explicit guidance on prerequisites, when it should be used relative to other BT setup commands, or alternatives. The description does not mention connection requirements or the need to set other parameters first.
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, permissions, or state changes. It only states the action and unit, but says nothing about whether this is a write operation (obvious from 'set'), how it affects the current measurement setup, whether it requires a prior configuration, or what the return value is. This is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the verb and target. It contains no fluff or repetition, and every word 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 is a simple setter, and the description covers the core purpose. However, it omits any details about how host/port are used, whether the measurement must be configured before setting expected power, or what the response indicates. Given the available sibling tools (e.g., cmw_meas_configure_power), a bit more context would be helpful, but this level is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (power_dbm described, host and port not). The description adds the context 'in dBm' reinforcing the power_dbm parameter, but it does not explain the host and port parameters. Given the low schema coverage, the description should compensate, but it fails to do so for the majority of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set'), the resource ('expected input power for GPRF analyzer'), and the unit ('in dBm'). This is specific enough to distinguish it from sibling tools like cmw_bt_set_expected_power and cmw_wlan_set_expected_power, which target different radios.
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 context through 'for GPRF analyzer', but it does not explicitly mention when to use this tool over alternatives, nor does it state any prerequisites or exclusions. The context is clear but the guidance is implicit rather than explicit.
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?
There are no annotations provided, so the description must disclose behavioral traits. It only states the action with no mention of side effects, dependencies, return format, or whether a connection is required. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the essential action and accepted values efficiently.
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 setter with no output schema, but the description is extremely minimal. It lacks context about prerequisites, effects, or how it fits into the WLAN configuration workflow. While it is functionally understandable, it is not fully complete for an agent seeking robust guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with host and port undocumented. The description only restates the enum values for bandwidth, adding little beyond the schema. It does not clarify the purpose of host, port, or meas_instance, so it fails to compensate for the schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Set' with a clear resource 'WLAN channel bandwidth' and enumerates the allowed values (20/40/80/160 MHz). This fully distinguishes it from sibling setters like cmw_wlan_set_frequency or cmw_wlan_set_expected_power.
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 to configure WLAN bandwidth, but it does not state when to use this versus alternatives, any prerequisites (e.g., WLAN standard configured), or when not to use it. This is implied context rather than explicit guidance.
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?
There are no annotations, so the description carries full responsibility. It indicates a mutating operation ('clear') but does not disclose side effects like irreversibility, scope (e.g., entire instrument vs. specific measurement), or any prerequisites. The minimal wording adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words. It front-loads the action verb and clearly states the object, making it extremely concise and easy to parse.
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 (no parameters, no annotations, no output schema), the description is minimally viable but lacks important context. It does not specify the scope of 'all limits' (e.g., limits for which test or mode), potential consequences of clearing, or whether it affects persistent configuration. This leaves some ambiguity for an AI agent deciding when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty (100% coverage by default). With no parameters to explain, the description cannot add parameter semantics, so the baseline of 4 for zero-parameter tools 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 a specific verb ('Clear') and resource ('all defined limits'), clearly distinguishing it from sibling tools like cmw_define_limit, cmw_check_limits, and cmw_list_limits. The action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. It simply states the action, leaving the agent to infer that it should be used when limits need to be removed, but without explicit 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 simply states 'Connect' without elaborating on side effects (e.g., whether an existing connection is replaced), error handling, or persistence of the connection. For a state-changing network operation, this is a transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It conveys the essential information in a compact form, appropriate for a simple connect operation.
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 with two parameters and no output schema, so the description is minimally adequate. However, it omits important contextual details such as the need to call this before other cmw_* commands, default connection behavior from config, and whether the connection is persistent or requires a subsequent disconnect. These gaps could leave an agent uncertain about operational flow.
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 documents both host and port with descriptions, achieving 100% schema coverage. The description's phrase 'specified host:port' adds no new meaning beyond what the schema provides, 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 (Connect), the target (CMW500), and the addressing mechanism (host:port). This distinguishes it from sibling tools like cmw_disconnect and cmw_discover, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool name and description imply it should be used to establish a connection before other cmw_* operations, but no explicit guidance is given about prerequisites, alternatives, or when not to use it. The context of sibling tools suggests usage, but the description itself does not provide explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It states the action and a behavioral outcome ('safe state'), but does not disclose side effects, idempotency, or any state changes beyond turning off RF output. The description is minimal but not misleading.
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 with no filler words. It effectively communicates the core action and context in minimal space.
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?
While the tool is simple, the description omits any details about prerequisites (e.g., connection), what happens to the generator's configured settings, or how the safe state is indicated. With no annotations or output schema, the description is not complete enough for robust tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only host and port with no descriptions, and schema description coverage is 0%. The description does not mention these parameters or explain that they identify the instrument connection, failing to compensate for the lack of parameter documentation.
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 'Disable' and resource 'GPRF generator RF output', adding 'safe state' to clarify intent. It is clearly distinct from the sibling tool cmw_gen_output_on as the inverse operation.
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 '(safe state)' implies use when a safe condition is needed, but no explicit guidance is given on when to use this tool versus cmw_gen_output_on or other tools. No exclusions or alternatives are stated, so usage is only implied.
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. It states what parameters are configured but does not disclose side effects: whether it overwrites existing settings, if it requires an active connection, whether it immediately applies, or if a trigger is needed afterward. The word 'Configure' implies a write operation but lacks critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the tool's purpose and then lists the configurable settings. Every word contributes value; there is no filler or redundancy. This is appropriately concise for a straightforward configuration tool.
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 no annotations and no output schema, so the description must cover behavioral context. It does explain the core purpose and parameters, but it omits any mention of prerequisites (e.g., connection), post-configuration steps (e.g., triggering a measurement), or default behaviors for omitted parameters. For a tool with six parameters and no required fields, this is a notable gap.
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 description coverage is 67% (4 of 6 params have descriptions). The description adds a high-level mapping of parameters by naming 'centre frequency, span, resolution and video bandwidth', which correspond to center_freq_hz, span_hz, rbw_hz, and vbw_hz. However, host and port remain undocumented in both schema and description, and no deeper semantics (e.g., constraints, dependencies) are provided.
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 'Configure' and identifies a precise resource: 'GPRF spectrum measurement'. It lists the key settings (centre frequency, span, resolution, video bandwidth), which clearly distinguishes this from sibling tools like cmw_meas_configure_power or cmw_meas_fetch_spectrum.
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 its usage context (for setting up spectrum measurements) and distinguishes it by 'GPRF spectrum', but it does not explicitly state when to use this over alternatives (e.g., cmw_meas_set_frequency for simple frequency changes) or mention prerequisites like needing a connection first. The guidance is implied but not 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It does disclose the key trait that there is no response, which is important. However, it omits other behavioral context such as whether a prior connection via cmw_connect is required, how errors are handled, or whether commands are queued synchronously.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is front-loaded with the action and resource. However, it is almost too terse, and a bit more structural detail could improve it without sacrificing conciseness.
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?
The description is incomplete for a tool with 3 parameters and no annotations or output schema. It does not mention prerequisites (e.g., connected device), whether host/port are optional with defaults, or what side effects occur. An agent would need to infer too much from the name alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only 'command' has a description). The description does not add meaningful details about 'host' or 'port' parameters, such as defaults, optionality, or format. It merely implies that the command goes to the CMW500, leaving the agent to guess how host/port are used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Send raw SCPI command') and a specific resource ('CMW500'). The parenthetical '(no response)' explicitly distinguishes it from its sibling tool cmw_scpi_query, which presumably returns a 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 phrase '(no response)' provides clear context that this tool is for fire-and-forget commands where no reply is expected. It implies a contrast with cmw_scpi_query, but does not explicitly name an alternative or state when to use one over the other.
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 only lists what data is fetched, but does not mention any operational context such as requiring a prior trigger, whether results are cached or live, or what the response structure looks like. This is a significant gap for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. Every word contributes to describing the tool's purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (no output schema, few parameters), the description is minimally adequate. However, the lack of annotations, incomplete parameter explanations, and no mention of usage prerequisites mean the agent may not have enough context to use the tool correctly in all situations. It is not completely self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only meas_instance has a description). The tool description adds no information about the parameters host, port, or meas_instance. It does not compensate for the low schema coverage, leaving the agent without clarity on how to use these parameters beyond generic connection 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 clearly states the tool fetches all WLAN results and lists specific metrics (power, EVM, spectrum flatness, freq error), making it distinguishable from sibling tools that fetch individual metrics. The verb 'Fetch' and resource 'all WLAN results' 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The name and description imply this is the comprehensive fetch tool among siblings like cmw_wlan_fetch_power and cmw_wlan_fetch_evm. However, it does not explicitly state when to use this over individual fetches, or mention any prerequisites like triggering a measurement first.
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 of disclosing behavior. The verb 'List' inherently signals a read-only operation, and 'this instrument supports' implies a query to the device. However, it does not explicitly state that no state is modified, nor does it mention any connection requirements or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is appropriately front-loaded with the action and resource, making it easy to parse quickly.
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 list operation, and the description conveys the core purpose. However, without an output schema, it does not specify the format of the returned list (e.g., names, codes, or options). Additionally, the two undocumented parameters create a gap, so the description is not fully complete for smooth invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'meas_instance' has a description). The tool description does not mention any of the parameters, leaving 'host' and 'port' completely undocumented. It fails to compensate for the low schema coverage, so the agent gains no additional parameter semantics from the 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 uses a specific verb 'List' and identifies the resource 'WLAN trigger sources' with scope 'this instrument supports'. It clearly distinguishes itself from sibling tools like 'cmw_wlan_trigger' and 'cmw_wlan_set_trigger' by focusing on discovering supported sources rather than triggering or configuring.
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 discovery role: to see which trigger sources are available before setting a trigger. However, it provides no explicit context about when to use it vs alternatives, nor does it mention any prerequisites such as needing a connection to the instrument.
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?
There are no annotations, so the description must convey behavior. It only says 'scan' and gives a port, without disclosing whether the scan is read-only, how long it might take, what side effects (if any) occur, or what the output looks like. This leaves the agent with significant ambiguity.
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 is front-loaded with the action and target. Every word adds value, with no 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?
The tool is simple, but without an output schema, the description should explain what the scan returns or how results are presented. It doesn't, leaving some uncertainty. However, the parameter schema covers the inputs well, so it's 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 schema already describes all three parameters with defaults and meanings, so the description adds little beyond confirming the port. Since coverage is 100%, a baseline of 3 is appropriate, and the description does not provide additional 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 action ('Scan'), the target ('CMW500 instruments on the network'), and a distinctive detail (port 5025), which separates it from sibling tools like cmw_connect or cmw_identify. It is 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context of scanning for instruments is evident, implying use before connecting or configuring. However, it does not explicitly mention when not to use it or alternative tools, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It explains the behavioral consequence of missing licenses and the resulting error message, which is valuable context. However, it does not mention the caching behavior (which is implied by the 'refresh' parameter) or the return format, leaving some behavioral aspects undisclosed.
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 three sentences long and front-loaded with the main purpose. The extra context about CMW500 licensing and the error message earns its place by reinforcing usage guidance. It is concise without being terse, though the chassis metaphor could be shortened without losing 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 description explains what the tool does and when to use it, but because there is no output schema, it should describe what the returned report looks like (e.g., a list of family names). It also omits mention of caching, which is relevant for understanding freshness. These gaps make it adequate but not fully complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 33% (only 'refresh' is described). The description does not compensate for the undocumented 'host' and 'port' parameters, nor does it add any meaning beyond the schema. For an agent to correctly use these parameters, it would need additional context or rely on convention.
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: 'Report which technology families this instrument can actually be asked to use, based on its installed options.' The verb 'Report' and resource 'technology families' are specific and unambiguous. It distinguishes itself from sibling tools like cmw_query_options by focusing on capability families rather than raw options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage timing: 'Call this before planning a campaign' and explains the consequence of not doing so (the '-113 Undefined header' error). It provides clear context for when to use the tool, though it does not explicitly mention alternative tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does not mention that loading a template modifies instrument state, requires a connection, or how errors are handled. The only behavioral detail (parameter key rejection) is in the schema, not the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains no redundant or filler text. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple template loader but lacks behavioral context around side effects, prerequisites, or failure modes. Since there is no output schema or annotations, more detail would be expected, but the complete parameter schema and the reference to cmw_list_templates partially compensate.
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?
All three parameters have schema descriptions, so the baseline is 3. The description reinforces that presets and valid parameter names can be found via cmw_list_templates, but this is already present in the schema. It adds no new meaning beyond what the schema provides.
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 a measurement template by name, optionally with a preset. The verb 'load' and resource 'measurement template' are specific, and the reference to cmw_list_templates helps distinguish this from sibling tools like cmw_apply_template.
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 directs users to call cmw_list_templates to discover presets and valid parameter names, which is clear contextual guidance. It does not explicitly state when not to use this tool or mention alternatives, but the guidance provided is actionable and relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses a key limitation: 'The connector and converter are not readable from the instrument, so the path is only known if it was set here.' It also implies a non-destructive read operation via 'Report', though it does not describe return format or failure modes.
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, front-loading the main purpose and adding only a relevant caveat. Every sentence earns its place; no wasted words.
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?
The tool has 4 parameters and no output schema, yet the description does not explain parameter semantics or what the returned 'routing scenario' and 'path' look like. The caveat is useful, but the description is incomplete for an agent to invoke it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description does not explain the roles of host, port, application, or meas_instance. It only says 'an application' abstractly, leaving the agent without enough information to correctly set parameters beyond the schema's type/enum constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Report') and clearly identifies the resource ('an application's routing scenario and the path this server last applied to it'). This distinguishes it from the sibling setter cmw_rf_route_set and other getters like cmw_get_signal_path.
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 this tool is used to read routing state, but offers no explicit when-to-use or when-not-to-use guidance. It mentions a caveat about the path only being known if set here, but does not compare against alternative getter tools or state preconditions.
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 available, the description carries the full burden. 'List all defined limits' clearly indicates a read-only operation, but it does not disclose edge cases (e.g., empty list), return format, or any prerequisites. For a simple zero-parameter tool, this is minimal but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no superfluous words. It communicates the operation effectively and efficiently.
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 (no params, no output schema), the description is nearly complete. The meaning of 'limits' is clarified by the sibling tools (e.g., define_limit, check_limits), and the operation is fully captured. However, it could slightly benefit from mentioning that it returns a list, but that is already implicit in 'list'.
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. There is no parameter information needed, and the description does not need to compensate for schema gaps. The schema is trivially empty and fully covered.
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 'List all defined limits' uses a specific verb (list) and resource (defined limits), clearly distinguishing it from sibling tools like define_limit, check_limits, and clear_limits. This is a focused and unambiguous purpose.
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. It does not mention that it is a read-only retrieval or that it should be used before checking or clearing limits. The usage is implicitly obvious from the name, but no explicit context or exclusions are given.
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 of behavioral disclosure. It reveals that the tool reads a 'declared' value (vs. measured), which is useful context, but it does not explicitly state that it is read-only or describe side effects or return format. The transparency 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?
The description is two short sentences that each serve a purpose: the first states what the tool does, the second gives usage guidance. It is front-loaded and contains no 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?
For a simple getter with two standard parameters and no output schema, the description effectively covers the tool's purpose and when to use it. It could be more complete by indicating the return format or units, but the current description is sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the host and port parameters at all. While they are standard connection parameters, the description adds no semantics beyond the schema, so it fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Report') and precisely identifies the resource ('external attenuation' for 'generator and analyser paths'). It is well-differentiated from the sibling setter tool 'cmw_set_external_attenuation' and other general getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: 'Check this before trusting any absolute power measurement.' This clearly indicates when to use the tool, though it does not name specific alternatives or conditions when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does reveal a key behavioral trait: routing is per-application and converters serve one application at a time, leading to conflicts. However, it omits other important behaviors such as side effects on previously set routes, error behavior in conflict situations, and any prerequisites or reversibility concerns.
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 example, followed by two essential caveats about per-application isolation and converter conflicts. Every phrase contributes meaning 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?
The description covers the core purpose and the key conflict behavior but leaves gaps: it does not mention the corresponding getter cmw_rf_route_get, does not explain what happens on a resource conflict (error? override?), and does not clarify the role of parameters like host, port, and meas_instance. Given 5 parameters, no annotations, and no output schema, the description is functional but not comprehensive.
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 documents 'path' and 'application'; the description adds a concrete example and clarifies the per-application semantic. Yet with only 40% schema description coverage, host, port, and meas_instance remain unexplained in both schema and description. The description provides some added meaning but does not fully compensate for the missing parameter documentation.
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: 'Route a measurement or generator application to a front-panel connector and internal converter', with a concrete example ('RF1C,RX1'). It also distinguishes from the sibling getter cmw_rf_route_get by emphasizing the per-application routing behavior, 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 contextual guidance by explaining that routing is per-application and that converters cause resource conflicts when shared. This implies when to use it and what to watch for. However, it does not explicitly name alternatives like cmw_rf_route_get for reading routing or cmw_set_signal_path for other path settings, so a fully explicit when/when-not comparison is missing.
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 of behavioral disclosure. 'List' implies a read-only operation, which is helpful, but it does not describe the return format, potential errors, or whether a connection is required. It adds minimal context beyond what the tool name already conveys.
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 communicates the essential purpose with no wasted words. It is appropriately brief for a tool with no parameters and a straightforward function.
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 low complexity (no parameters, no output schema, read-only listing), the description is adequate. It conveys what the tool does, and the sibling tool names indicate a template management workflow. However, a note about the return value (e.g., 'returns template names') would enhance completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully complete. There is no parameter information to add, and the description correctly avoids inventing any. The baseline for zero parameters is 4, and the description does not detract from this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available measurement templates, using the specific verb 'List' with a clear resource. This distinguishes it from sibling tools like cmw_load_template and cmw_apply_template, which operate on templates rather than listing them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose: an agent would call this to discover available templates before loading or applying one. However, there is no explicit guidance about when to use this tool versus alternatives, or any mention of workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well by disclosing a non-obvious behavior: releasing the RF converter and warning about resource conflicts. This goes beyond the simple action and adds useful operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the action, the second explains the rationale. There is no filler and every word 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 description covers purpose and a key consequence, which is adequate for tool selection. However, it does not address idempotency (e.g., calling on an already-stopped measurement) or error conditions, leaving some gaps for a simple tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only meas_instance has a description). The tool description adds no parameter meaning, leaving host and port entirely undocumented. It fails to compensate for the low schema 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 action ('Stop a running WLAN measurement') plus a unique side effect ('release its RF converter'), distinguishing it from siblings like trigger or fetch tools. It is 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong contextual guidance by explaining the resource conflict that occurs if a measurement is left in RDY, implying when to call this tool. However, it does not explicitly name alternative tools or state exclusions, so a small gap remains.
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 transparency burden. It discloses a non-obvious side effect (tightening safety clamps) and the consequence of not setting it (every absolute power reading is wrong). It also explains the per-application behavior which is a behavioral nuance 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, each earning its place: purpose, consequence, and application scope/side effect. The message is front-loaded and free of 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?
Covers purpose, usage guidance, per-application scope, and a side effect. It lacks explicit mention of whether existing attenuation values are overwritten or how to verify the setting, but for a setter with no output schema, it is relatively 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 coverage is only 40% (applications and attenuation_db have descriptions). The description reinforces these with added meaning ('pass the applications you are measuring with', path loss semantics) but does not address host, port, or meas_instance, leaving a partial gap in compensating for low 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 uses the specific verb 'Declare' and identifies the exact resource: cable and fixture loss between the CMW connector and the DUT. It clearly distinguishes this setter from the sibling getter by focusing on making power readings refer to the DUT rather than the instrument.
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 instructs the user to pass the applications being measured, warning that declaring for GPRF does nothing for WLAN or Bluetooth. This gives clear when-to-use context, though it does not name specific alternative tools (e.g., cmw_get_external_attenuation for verification).
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 transparency. It discloses that the tool waits for completion, arms the instrument, and marks results stale if settings change. Notably, it explains the pitfall of separate calls, adding behavioral nuance beyond a simple 'run measurement'. However, it does not describe timeout behavior, continuous mode, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loaded with the action, and avoids redundancy. Every sentence contributes meaning: the first defines the operation, the second explains when to use it and a key behavioral caveat.
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 complex with 7 parameters and no output schema, but the description covers the core flow and important behavioral constraints. However, it does not describe what the returned 'results' contain or any prerequisites like prior configuration. Given the lack of annotations and output schema, a bit more detail on return value and preconditions would improve completeness.
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 57%, and the description adds little parameter-specific meaning. It does contextualize timeout_s via 'wait for the instrument to report the acquisition finished' and mentions stale results, but does not explain host, port, or meas_instance beyond what the schema provides. This is adequate but not compensatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Run a complete measurement' and clearly outlines the sequence (arm, wait, fetch). It also distinguishes itself from sibling tools like cmw_meas_trigger and cmw_meas_fetch_power by explicitly recommending this over separate trigger/fetch calls.
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 states when to use this tool: 'Prefer this over separate trigger and fetch calls' and explains why (INITiate returns immediately, so a separate fetch may read the previous acquisition). This provides clear usage context and differentiates from 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, the description carries the full burden. It discloses a key behavioral trait: CONTinuous mode never reports a finished state, which is critical for understanding measurement synchronization. It also states the default behavior. This goes beyond a simple setter description and alerts the agent to a subtle consequence.
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 action, followed by crucial contextual detail. No redundant or filler content. Every sentence earns its place and the description is easy to parse quickly.
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 tool with no output schema and basic annotations, the description is nearly complete. It explains the core setting, the default, and the main gotcha (CONTinuous never finishes). It does not mention prerequisites like prior WLAN configuration, but this is likely implied by the tool suite and not necessary for basic 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 description adds meaning to the 'repetition' parameter by explaining the default and the practical implication of each mode, which the schema only hints at with 'SINGleshot for a synchronised measurement'. It does not cover host/port, but those are standard connection parameters. The added context for the key parameter compensates for the 50% schema 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 uses a specific verb+resource combination: 'Set WLAN repetition' and explicitly lists the two possible values (SINGleshot or CONTinuous). This clearly distinguishes the tool from sibling tools like cmw_wlan_set_trigger or cmw_wlan_set_frequency, which handle different settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use each value: it states the default is CONTinuous and that a synchronised measurement requires SINGleshot. This is practical guidance for choosing the correct parameter, though it does not explicitly mention alternatives or when not to use this tool (e.g., other configuration steps).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that reading the queue clears it, which is a crucial behavioral side effect. It also explains the underlying reason for the tool's existence (silent write failures). This is highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding essential information: what it does, why it's needed, and a key side effect. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description explains the tool's purpose, its necessity, and its clearing side effect. This is complete for an agent to understand when and how to invoke it, especially given the rich sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the 'host' and 'port' parameters. While they may be self-explanatory in a network instrument context, the description adds no meaning beyond the schema's bare parameter names. For a low-coverage schema, the description should compensate but does not.
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 drains the instrument's SCPI error queue and reports rejected settings. This is specific and distinguishes it from sibling tools by focusing solely on error retrieval and its role in detecting silent failures.
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 explains when to use this tool: after write commands that return no response, as the only way to learn if a setting was rejected. This provides clear context and implies it is the go-to tool for error feedback, with no ambiguity about 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, the description carries the full burden and does disclose key behaviors: the default source, threshold-crossing behavior, and timeout risk. It lacks explicit mention of immediate persistence or connection requirements, but the core behavioral context is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the purpose, followed by behavior and a pointer to the catalog. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter, it covers the main source options, default, and timeout caveat. It doesn't elaborate on meas_instance or return values, but the schema covers the default and no output schema is needed. Overall adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, with source and meas_instance described. The description adds meaning by comparing 'Free Run' and 'IF Power' beyond the schema's example. Host and port are generic and not described, but their purpose is self-evident and they are not required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Set the WLAN measurement trigger source.' It clearly distinguishes this from sibling tools like cmw_wlan_trigger (which triggers a measurement) and cmw_wlan_trigger_catalog (which lists sources).
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 explains when to use 'Free Run' versus 'IF Power', warns about timeout behavior on infrequent bursts, and directs the user to cmw_wlan_trigger_catalog for supported sources. This gives actionable guidance beyond the schema.
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:

[![mcp-rs-cmw500 MCP server](https://glama.ai/mcp/servers/RFingAdam/mcp-rs-cmw500/badges/card.svg)](https://glama.ai/mcp/servers/RFingAdam/mcp-rs-cmw500)

Score Badge

Copy to your README.md:

[![mcp-rs-cmw500 MCP server](https://glama.ai/mcp/servers/RFingAdam/mcp-rs-cmw500/badges/score.svg)](https://glama.ai/mcp/servers/RFingAdam/mcp-rs-cmw500)

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/RFingAdam/mcp-rs-cmw500'

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