copper-mountain-vna-mcp

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 a template is applied, without mentioning side effects (e.g., device state changes), required connection state (host/port), or what happens if no template is loaded.

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

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

The description is a single, front-loaded sentence that directly states the tool's purpose without verbose filler. While it is under-specified, it is appropriately concise for the minimal content it delivers.

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

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 any parameter descriptions, the description is inadequate for fully understanding the tool. It lacks information about usage flow (e.g., after loading a template), parameter roles, and potential outcomes, making it minimally viable at best.

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

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

The input schema has a 0% description coverage, and the tool description does not explain the host and port parameters. The description adds no meaning beyond the schema's bare type declarations, leaving the parameters' purpose and optionality unclear.

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

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

The description uses a specific verb ('Apply') and names the resource ('loaded template configuration') and target ('VNA'), clearly distinguishing it from sibling tools like vna_load_template and vna_list_templates. However, it does not elaborate on what 'apply' entails beyond the basic action.

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

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. It does not mention prerequisites (e.g., that a template must be loaded first) or contrast with other configuration tools, 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.

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. 'Save coefficients' implies a write operation, but the description does not state whether it overwrites existing calibration data, if it is reversible, or what side effects it has. The agent gets no insight into 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.

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

The description is a single sentence with no filler words. It is front-loaded, stating the action immediately. It is concise, though it could afford to add a bit more detail without becoming verbose.

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

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

The tool performs a calibration operation (calculating and saving coefficients), yet the description omits critical context such as prerequisites, the effect on existing calibration, or what constitutes a successful application. With no output schema and no annotations, the description is not sufficient for an agent to use the tool correctly in a workflow.

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

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

With 0% schema description coverage, the description must compensate for explaining the parameters. 'host' and 'port' are not described, and the description provides no additional meaning beyond the obvious network-related names. The agent is left without guidance on what values to supply or their purpose in the calibration context.

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

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

The description uses a specific verb 'Apply' with the resource 'calibration' and clarifies the action with 'calculate and save coefficients'. This distinguishes it from other calibration-related tools like vna_calibration_start (which likely initiates calibration) and vna_correction_on (which enables correction). The parenthetical adds useful specificity, though the exact meaning of 'apply' could still be slightly ambiguous.

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

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 vna_calibration_start, vna_calibration_measure_standard, or vna_correction_on. There is no mention of prerequisites, ordering within the calibration workflow, or situations where this tool is preferred.

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

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 the action without mentioning whether measuring a standard affects calibration state, requires an active connection, or returns any data. This could be a read-only operation or a step that modifies calibration coefficients, and the description leaves that ambiguous.

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

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

The description is a single, front-loaded sentence that directly states the core purpose. It contains zero filler or redundant phrasing, every word earning its place.

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

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

Given the tool has 4 parameters, no annotations, and no output schema, the description is too terse to provide complete context. It doesn't explain how this step fits into the overall calibration workflow, what the user should expect after execution, or whether there are side effects on the instrument state. The short description may be enough for a trivial tool, but for a calibration step, more context is needed.

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

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 in both schema and description. The description's only param-related content is listing the standard types, which duplicates the enum already in the schema. It adds no insight into the meaning or usage of the parameters beyond what is already structured.

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

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

The description clearly states the tool's action ('Measure') and resource ('calibration standard'), with the parenthetical enumerating the standard types (OPEN/SHORT/LOAD/THRU). This specific verb+resource combination distinguishes it from sibling tools like calibration_start or calibration_apply, which handle different stages of calibration.

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

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

The description implies this is used during calibration to measure standards, but it does not explicitly explain when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It provides no direct guidance for selection among the many VNA tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the automatic disabling of port extension, the reason (incorrect coefficients), and the return flag indicating whether any ports were affected. This is valuable side-effect transparency, though it does not mention other potential behaviors like clearing existing calibration data or blocking concurrent operations.

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

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

The description is three focused sentences. It leads with the core action, then explains an important side effect and its rationale, and finally notes the return flag. Every sentence adds distinct value without redundancy.

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

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

For a state-changing tool with no annotations and no output schema, the description covers key aspects but leaves gaps. It does not explain what 'start calibration' entails in terms of workflow, what the method parameter affects, or whether additional steps (measuring standards, applying calibration) are expected. It is adequate but not comprehensive.

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

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

Schema description coverage is only 33%, so the description needed to compensate by explaining parameters. It does not mention 'method', 'host', or 'port' at all. The method enum is somewhat self-documenting, but the description adds no meaning beyond the schema, leaving the required 'method' parameter under-explained.

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

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

The description uses the specific verb 'Start' with the resource 'calibration procedure', clearly distinguishing this from related calibration tools like vna_calibration_status, vna_calibration_measure_standard, and vna_calibration_apply. It also adds a key behavioral detail about disabling port extensions, reinforcing the tool's unique role.

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

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

The description clearly implies this is the initial step in a calibration workflow, but it does not explicitly state when to use this tool versus alternatives such as vna_calibration_measure_standard or vna_calibration_apply. There is no when-not-to-use guidance or mention of prerequisites like an established connection.

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

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

With no annotations, the description carries the full burden. It implies a read-only operation via 'Get', but doesn't disclose what the status output includes (e.g., valid/invalid, pass/fail), whether it requires an active connection, or if there are any side effects. There is no mention of error conditions or handling of uncalibrated states.

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

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

The description is only one sentence long, which is excessively terse. While it is front-loaded, it sacrifices critical content; it is more under-specified than concise. A useful description would include at least a brief note on the return value or parameter roles, but it provides none.

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

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 description. It lacks information about return value shape, prerequisites, or typical usage context. Given the large sibling set with overlapping functions (e.g., vna_get_status), the description is insufficient for an agent to correctly select and invoke this tool.

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

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

The schema includes two parameters (host, port) with no description coverage. The tool description does not explain how these parameters are used, whether they are optional (required parameters: 0), or what values they accept. While 'host' and 'port' are conventional, the agent lacks context on their role in the calibration status check, such as whether they specify the instrument address.

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

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

The description clearly states the tool's function: retrieving the calibration validity status. It uses a specific verb ('Get') and resource ('calibration validity status'), which differentiates it from generic operations like 'get_status' slightly, but it doesn't explicitly distinguish it from sibling calibration tools. The term 'validity' adds a bit of specificity over the raw name, so it's not a pure tautology.

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

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. It doesn't mention whether this should be called after calibration, before measurements, or if it requires a connection. The sibling list includes calibration-related tools, but no exclusions or prerequisites are provided.

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

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

With no annotations provided, the description carries full responsibility for disclosing behavior. It only states the action without noting whether it is read-only, what happens on pass/fail, whether a connection is required, or how limits are referenced. 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.

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 easy to parse and appropriately sized for a simple action, though it sacrifices important context that would make it more useful.

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

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 a tool with a required parameter, this description is severely incomplete. It doesn't describe return values, prerequisites (e.g., defined limits), side effects, or error conditions, leaving an agent without enough information to use it confidently.

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

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

Schema description coverage is only 33% (only s_param has a description). The description adds no parameter semantics beyond what the schema already provides. Host and port are left unexplained, and the description does not compensate for the low coverage or clarify how s_param relates to the 'measurement'.

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

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

The description clearly states the action ('Check') and object ('measurement against defined limits'), distinguishing it from limit-definition tools like vna_define_limit. However, it doesn't specify the outcome format (pass/fail, values) or what kind of measurement is involved, leaving some ambiguity.

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

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 vs alternatives like vna_get_s_parameter or vna_measure_return_loss. It doesn't mention prerequisites (e.g., that limits must already be defined) or how it relates to sibling limit tools.

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

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

No annotations are provided, so the description must carry the full burden. It does not disclose whether the action is destructive, if it affects saved states or only the current session, or if any confirmation is needed. The phrase 'all defined limits' could imply a broad scope that is not further explained.

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

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

The description is a single, concise sentence that fully states the tool's purpose. It is appropriately sized for a zero-parameter tool and contains no unnecessary words or repetition.

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

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

For a simple tool with no parameters and no output schema, the description is mostly complete. It clearly conveys the action and scope. The main gap is the lack of behavioral context, but given the simplicity, this is not a major deficiency.

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

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. With no parameters, the description does not need to explain parameter semantics. The baseline score of 4 is appropriate since there is nothing to compensate for.

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

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

The description clearly states the action ('Clear') and the resource ('all defined limits'). It distinguishes this tool from siblings like vna_define_limit, vna_list_limits, and vna_check_limits, which perform related but different operations.

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

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

The intended usage is implied by the name and description, but there is no explicit guidance on when to use this tool versus alternatives, such as before defining new limits or to reset a test setup. No exclusions or prerequisites are mentioned.

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

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 merely restates the named action without mentioning side effects, whether the operation is reversible, or if vna_port=0 applies to all ports (though this is in the schema). This leaves key behaviors untold.

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

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

The description is a single, concise phrase that is appropriately short for a simple tool and front-loads the action. It lacks structured detail but does not waste words, earning a strong score.

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

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 is incomplete for an agent. It omits behavioral context such as prerequisites (e.g., connection), effect on existing port extensions, and the relationship to vna_set_port_extension. With no output schema and no annotations, the description should provide more context.

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

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

Schema description coverage is only 33% (only vna_port has a description), and the tool description adds no parameter details. It does not explain 'host', 'port', or clearly map 'specified port' to a specific parameter, so 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.

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

The description 'Clear/disable port extension for specified port' provides a specific verb-resource pair and is easily distinguishable from sibling tools like vna_set_port_extension or vna_get_port_extension. However, 'specified port' is ambiguous, as it could refer to either the 'port' or 'vna_port' parameter, preventing a perfect score.

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

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 are any prerequisites or context provided. The description simply states the action without explaining scenarios where clearing/disable is appropriate.

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

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

No annotations are provided, so the description carries the full burden. While it lists the parameters to configure, it does not disclose that this is a mutating operation, whether an active connection is required, whether existing sweep settings are overwritten, or any side effects on the instrument state.

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

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

The description is a single concise sentence that front-loads the purpose and enumerates the key parameters. Every word earns its place with no redundancy or filler.

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

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

For a VNA configuration tool with 8 parameters, no annotations, and no output schema, the description is too thin. It lacks prerequisite information (e.g., connection via host/port), relationship to specialized setter tools, and any indication of what happens when the command is executed.

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

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

The input schema already provides descriptions and defaults for most parameters (75% coverage). The description adds a useful grouping ('frequency range' for start/stop) and names four categories, but it omits averaging_count and does not explain host/port parameters. It adds marginal semantic value beyond the schema.

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

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

The description clearly states the tool's action ('Configure sweep parameters') and lists the key parameters (frequency range, points, IF BW, power). It is distinguishable from siblings like vna_set_center_span or vna_set_port_power because it is a bulk configuration tool, but it does not explicitly contrast itself with those alternatives.

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

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 the specialized setters (e.g., vna_set_center_span, vna_set_averaging, vna_set_port_power). The description does not mention expected context, prerequisites, or exclusions, leaving the agent without decision support for tool selection.

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

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 merely states the action without revealing what happens on connection (e.g., whether it blocks, handles timeouts, or is idempotent). No side effects, permissions, or error conditions are mentioned.

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

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

The description is a single, front-loaded sentence with no filler. It conveys the essential action efficiently, earning its place without unnecessary detail.

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

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

Despite the tool's low complexity, the description fails to provide context within the broader VNA workflow. It does not mention that a connection is likely a prerequisite for other measurement tools, nor does it explain the connection lifecycle or expected outcomes. The absence of an output schema makes the lack of additional context more significant.

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

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

The input schema already provides 100% coverage with clear descriptions and defaults for both host and port. The description adds minimal meaning by referring to 'specified host:port' but does not elaborate beyond what the schema provides, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Connect') and resource ('VNA') with target host and port. It clearly distinguishes from sibling tools like vna_discover, vna_launch, and vna_disconnect by stating the action of establishing a connection.

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

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 prerequisites, such as launching the VNA software first, or indicate that this is a required first step for many other sibling tools. There is no explicit or implied usage context.

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

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

With no annotations, the description bears the full burden of disclosing behavior. It states the action but does not mention side effects, prerequisites (e.g., a connected instrument), whether correction data is lost, or any impact on subsequent measurements. The word 'Disable' implies a state change, but the consequences are unspecified.

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

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

The description is a single, tightly worded sentence with no filler or redundancy. It is front-loaded and every word contributes to the meaning, making it appropriately concise for a simple command.

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

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

This is a standalone command with two optional parameters, no output schema, and no annotations. The description gives only the core action; it lacks context about how to use the tool (host/port), what state changes occur, and what the expected result is. It is incomplete for an agent without domain-specific assumptions.

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

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

The input schema includes 'host' and 'port' with no descriptions, and the schema description coverage is 0%. The description does not mention these parameters at all, so it fails to compensate for the missing parameter information. The parameter names are somewhat self-explanatory as connection details, but the tool provides no guidance on optionality or behavior when omitted.

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

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 ('error correction'), making the tool's function immediately clear. It also implicitly distinguishes itself from the sibling tool vna_correction_on, which performs the opposite action.

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

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

No when-to-use, when-not-to-use, or alternative guidance is provided. The phrase 'Disable error correction' merely restates the action without explaining when it should be invoked or how it relates to other VNA tools like vna_correction_on or vna_calibration_status.

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

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

With no annotations available, the description carries the full burden for behavioral disclosure. It only states 'Enable error correction' but does not mention side effects, whether it requires a connection, if it affects measurements, or how it relates to calibration state. The tool mutates state, yet no behavioral details 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.

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

The description is extremely short, which could be seen as concise, but it is under-specified rather than appropriately compact. It lacks critical information about parameters and behavior, so its brevity is a deficiency, not a strength. The single sentence does not earn its place by providing adequate value.

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

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

For a tool with 2 parameters, no annotations, no output schema, and related siblings (vna_correction_off, calibration tools), this description is incomplete. It does not place the tool in a workflow, explain how to use host/port, or clarify what 'error correction' means in this context. The simplicity of the operation doesn't excuse the missing prerequisites and parameter semantics.

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

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

The schema has 2 parameters (host, port) with 0% description coverage. The description does not explain what 'host' and 'port' mean for this operation or why they are needed. Since the schema provides no descriptions, the tool description must compensate but completely fails to do so.

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

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

The description clearly states the action ('enable') and the resource ('error correction'), which is a specific VNA operation. It distinguishes from sibling vna_correction_off by virtue of the opposite action, though it doesn't explicitly describe the scope or prerequisites. It is concise and non-misleading.

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

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 vna_correction_off or vna_calibration_apply. There is no mention of prerequisites (e.g., needing a valid calibration) or typical workflow placement. The description simply states the action without context.

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

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It only says 'Define pass/fail limit' without explaining whether existing limits are overwritten, whether the limit persists across sessions, what happens on validation errors, or any side effects on measurement workflows. This is a significant gap 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.

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

The description is a single, direct sentence: 'Define pass/fail limit for measurements.' It is front-loaded with the verb, contains no filler, and every word earns its place. It is an example of appropriate conciseness.

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

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

Given that this tool has five required parameters, an enum, no output schema, and no annotations, the description is insufficient. It does not explain what the tool returns after success, whether limits are cleared or overwritten, or how it interacts with other limit-related tools. The minimal description relies entirely on the schema, leaving important context gaps.

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

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

Schema description coverage is 100%, with each of the five parameters having a basic description (e.g., 'Limit value in dB', 'Type of limit'). The tool description adds no additional semantic meaning beyond the term 'pass/fail limit', but since the schema already documents all parameter names and purposes, the baseline of 3 is appropriate. It does not clarify relationships like start frequency must be below stop frequency, but this is not required for a passing score.

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

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

The description uses the specific verb 'Define' and identifies the resource as 'pass/fail limit for measurements', making its core purpose clear and distinguishing it from sibling tools like vna_check_limits, vna_clear_limits, and vna_list_limits. However, 'define' is slightly ambiguous—it could mean create, set, or configure—but in context it is reasonably precise.

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

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 vna_check_limits or vna_clear_limits, nor does it mention any prerequisites, exclusions, or scenarios where another tool would be more appropriate. It simply states what the tool does without addressing usage context.

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

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 omits any details about side effects, idempotency, error conditions, or whether a connection must exist. This is minimally transparent for a state-changing operation.

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

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

The description is a single, concise sentence with no unnecessary words. It is perfectly front-loaded and contains zero waste.

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

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

The tool is simple with only two optional parameters and no output schema, so a one-sentence description is almost sufficient. However, it lacks context about when to disconnect or what happens if not connected, leaving minor gaps given the absence of annotations.

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

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

Schema coverage is 100%, and the schema fully describes both parameters (host and port) with defaults. The description adds no parameter information, but the baseline score of 3 is appropriate because the schema already provides complete semantics.

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

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

The description 'Disconnect from VNA' uses a specific verb ('Disconnect') and resource ('VNA'), clearly stating the action. It distinguishes itself from sibling tools like vna_connect and vna_launch, making its purpose unambiguous.

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

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 mention when to use this tool (e.g., after vna_connect) or how it relates to alternatives. It simply states the action without any context.

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

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 says 'Scan ports' but does not disclose what the output will be (e.g., list of instances, addresses), whether it is non-destructive (though scanning is typically safe), or any potential side effects such as network delays. This lack of detail 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.

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

The description is a single concise sentence that immediately conveys the tool's purpose. Every word contributes value, and there is no redundant or filler content. This is highly efficient.

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

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

Despite the tool's apparent simplicity, the description is incomplete because there is no output schema, so it should explain what the tool returns or how results are presented. It also lacks guidance on when to use the tool relative to other VNA operations. The description only covers the basic scan action, leaving context and outcome unspecified.

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

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

Schema coverage is 100%, with all three parameters (host, start_port, end_port) having descriptions and defaults. The description's mention of ports 5025-5035 aligns with the schema's defaults, but it does not add additional semantic meaning beyond what the schema already provides. Therefore, 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.

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

The description clearly states the tool's function: 'Scan ports 5025-5035 for running VNA instances'. The verb 'scan' indicates a discovery action, and the resource (ports) and outcome (finding VNA instances) are explicit. This distinguishes it from siblings like vna_connect or vna_launch, which perform different actions.

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

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

The description implies usage when you need to find VNA instances on a host, but it does not explicitly state when to use this tool versus alternatives such as vna_connect or vna_identify. No exclusions or prerequisites are mentioned, so guidance is only implied rather than clear.

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

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

With no annotations, the description must carry the behavioral disclosure burden. It implies a read-only operation via 'get' and mentions JSON output, but does not disclose whether a connection is required, the size or complexity of the returned state, or any side effects (which are likely none).

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

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 but sacrifices useful context that might be expected for a network-bound tool.

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

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

Given the lack of annotations, output schema, and parameter details, the description is incomplete. It does not explain the host/port parameters, whether a connection must already exist, or what 'complete state' includes as JSON. This makes it insufficient for an agent to use effectively.

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

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

The input schema provides no descriptions for host and port, and schema coverage is 0%. The description does not explain what these parameters mean or how they are used, leaving the agent without essential information.

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

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

The description clearly states the action (get), the resource (complete VNA configuration state), and the return format (JSON). It distinguishes from siblings like vna_get_status (status only) and vna_save_state (saving to a file).

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

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 vna_get_status or vna_save_state. The description does not mention prerequisites, connection requirements, or suitable contexts.

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

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

There are no annotations, so the description carries the full burden. It merely says 'Get' without disclosing prerequisites (e.g., existing connection, marker must be set), return format, or side effects. The read-only nature is implied but not explicitly stated.

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

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

A single, front-loaded sentence with no waste. It efficiently conveys the core purpose.

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

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

For a tool with 3 parameters, no output schema, and no annotations, the description is minimal. It doesn't explain connection requirements (host/port), marker selection, or what the returned values look like. While the tool is simple, the description leaves important gaps 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.

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

Schema description coverage is only 33% (only marker_num has a description). The tool description does not mention host, port, or marker_num, nor add meaning beyond the schema. It 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.

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

The description clearly states the action ('Get') and the resource ('marker value'), with specific detail about what is retrieved (frequency, magnitude, phase). This distinguishes it from siblings like vna_set_marker and vna_marker_search_min/max.

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

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

No explicit guidance on when to use this tool vs alternatives, but the verb 'Get' implies it is for reading existing marker values. Usage context is implied by the name and sibling tools (e.g., vna_set_marker), but no exclusions or alternative recommendations are provided.

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

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

The description adds the behavioral detail that port extension settings include delay and loss compensation, giving insight into the return content. However, without annotations, it does not explicitly state that this is a read-only operation, whether it requires an active connection, or any side effects. The verb 'Get' implies read-only, but more explicit disclosure would be better.

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

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

Single concise sentence that is front-loaded with the operative verb and resource. No wasted words, and the parenthetical adds necessary specificity about the settings without verbosity.

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

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 incomplete parameter descriptions. The description only states what the tool retrieves but does not explain host/port parameters, prerequisites, return format, or error conditions. For a getter tool, more context about the connection and result structure is needed.

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

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

Schema description coverage is only 33% (only vna_port has a description). The tool description does not add meaning for host or port parameters, and only indirectly relates to vna_port via the 'delay and loss compensation' detail. 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.

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

The description 'Get port extension settings (delay and loss compensation)' uses a specific verb 'Get' and names the exact resource (port extension settings) with detail on what they include. This clearly distinguishes it from sibling tools like vna_set_port_extension and vna_clear_port_extension.

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

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, connection state, or situations where this tool would be preferred over other getter tools.

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

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

With no annotations provided, the description must disclose behavioral traits. It reveals that the tool returns frequencies, magnitude, and phase, which is helpful, but it omits any side effects (e.g., triggering a sweep), prerequisites (e.g., connected instrument), or limitations (e.g., only current sweep data). This is a minimal disclosure insufficient for safe invocation.

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

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

The description is a single short sentence, which is concise, but it under-specifies critical information. It front-loads the main action but lacks structure or additional details, making it closer to under-specification than effective conciseness. Compare to well-structured descriptions that combine brevity with completeness.

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

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, no annotations, and operates in a complex VNA environment, this description is inadequate. It doesn't explain return format, units, prerequisites, or potential errors. The only context given is the data types (frequencies, magnitude, phase), which is a tiny fraction of what an AI agent would need.

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

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

Schema description coverage is only 33% (only 's_param' is described). The description adds no meaning for 'host' and 'port', which are likely connection parameters. It only repeats the concept of 'S-parameter' without elaborating on the enum values or the role of the optional parameters. This 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.

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 ('S-parameter data'), and clarifies the data content with '(frequencies, magnitude, phase)'. This distinguishes it from sibling tools like vna_get_marker or vna_get_status, which target different data. However, it doesn't explicitly contrast with measurement tools like vna_measure_return_loss, so it's clear but not fully differentiated.

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

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 description does not mention whether it requires a configured sweep or connection, nor does it reference sibling tools such as vna_configure_sweep or vna_get_marker. Users are left 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.

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. 'Get' implies a read-only operation, but the description does not state that no state changes occur, nor does it mention requirements like an active connection, potential side effects, or the format of the returned status. It only names the general content of the response.

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

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

The description is a single, concise sentence that front-loads the verb and directly states the resource. There is no filler or redundant wording, making it easy to parse quickly.

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

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

Given the absence of an output schema and annotations, and the presence of two undocumented parameters, the description is under-specified. It omits what the status payload includes, whether host/port are optional or default to a local connection, and how connection or configuration errors are handled.

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

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

The input schema provides two parameters (host, port) with no descriptions, and the tool description does not mention them at all. With 0% schema description coverage, the agent has no information about whether these parameters are required, how they are used, or what defaults apply. 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.

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

The description clearly states the tool's action ('Get') and resource ('VNA connection and configuration status'). This distinguishes it from siblings like vna_calibration_status (focused on calibration) and vna_connect (establishes a connection). The verb+resource pattern makes the purpose immediately clear.

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

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 prerequisites (e.g., an active connection), exclusions, or alternative tools such as vna_get_full_state or vna_calibration_status. This leaves the agent to infer usage solely from the name.

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

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

No annotations are provided, so the description carries full responsibility. It states the operation is a query and lists the return fields, but it does not disclose whether a connection is required, what happens on error, or any side effects. The read-only nature is only implied by 'Get', not explicitly stated.

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

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

The description is a single sentence that front-loads the action and includes essential details (return fields, SCPI command). Every word earns its place; there is no waste or redundancy.

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

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

For a simple query tool, the description covers the basic purpose and return values, but it omits important operational context such as connection requirements, error handling, or any setup steps. Given the lack of annotations and output schema, this leaves the agent with limited guidance for robust invocation.

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

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 host or port parameters at all. While these may be self-explanatory, the description adds no meaning beyond the schema, so it 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.

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

The description clearly identifies the action ('Get') and the resource ('VNA identification'), and lists the specific return data ('manufacturer, model, serial, firmware'). It also includes the SCPI command (*IDN?), which unambiguously distinguishes it from sibling tools that involve measurement, configuration, or state management.

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

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

The usage context is implied: use this tool when you need to identify the instrument. However, there is no explicit guidance on when to use this instead of alternatives like vna_get_status or vna_connect, nor any mention of prerequisites such as an existing connection.

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

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

With no annotations, the description bears the full burden. It discloses that the software is launched and a socket server is enabled, but does not describe side effects like process creation, potential installation requirements, or what happens if the software is already running. The 'wait_for_ready' and 'timeout' parameters hint at behavior, but the description itself stays at a high level.

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

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

The description is a single sentence, front-loaded with the action and key qualifiers. It is concise and avoids unnecessary detail, ensuring the core purpose is immediately clear.

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

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

Given the tool is a launcher with no output schema and five parameters, the description provides the essential idea but lacks context about return behavior, error conditions, or relationship to sibling tools like vna_connect or vna_discover. However, the parameter defaults and descriptions fill much of the operational context, making it minimally viable.

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

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

The input schema provides 100% coverage with descriptions for all five parameters, including defaults. The description adds minimal extra semantic value, only mentioning the socket server enabled concept which loosely relates to the 'port' parameter. This meets the baseline for schema-covered parameters.

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

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

The description clearly states the verb 'Launch' and the resource 'VNA software', with a specific qualifier 'with socket server enabled' and a platform constraint 'Windows only'. This distinguishes it from sibling tools like vna_connect or vna_discover, which are about connecting/discovering rather than launching.

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

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

No explicit guidance is given on when to use this tool versus alternatives. The only usage hint is the 'Windows only' platform restriction. There is no mention of using it before other VNA tools or prerequisites, so the agent is left to infer timing and context.

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

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

With no annotations and no output schema, the description carries the full burden of behavioral disclosure. It only states 'List all defined limits' without mentioning whether the operation is read-only, what the return format is, or any device connection requirements. This is a bare statement with no added 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.

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

The description is a single, front-loaded sentence with no wasted words. It perfectly captures the essence of the tool in minimum space.

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

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

For a tool with no annotations, no output schema, and a very short description, the context is incomplete. It does not clarify what 'limits' refers to (e.g., frequency limits, amplitude limits), what the output structure might be, or any preconditions. The description is minimal but under-specified for a tool that has no structured metadata to rely on.

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

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

The tool has zero parameters, and the input schema is empty, so there is nothing to explain. According to the rubric, 0 parameters receives a baseline score of 4. The description correctly implies that no parameters are needed.

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

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

The description uses a specific verb 'List' with a clear resource 'all defined limits', which precisely distinguishes it from sibling tools like vna_define_limit, vna_check_limits, and vna_clear_limits. It clearly communicates the operation's scope (listing, not checking or defining).

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

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 lacks context such as 'use this to retrieve current limit definitions' or any exclusions or prerequisites. The description merely states the action without situational advice.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It implies a read-only operation via 'List', but does not mention return format, whether a device connection is required, or potential errors. It adds only minimal context 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.

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

The description is a single, short phrase that front-loads the action ('List') and the object ('available measurement template presets'). Every word earns its place, with no filler or redundancy.

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

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

For a zero-parameter, simple listing tool with no output schema, the description is adequate. It conveys what the tool does clearly. While it could explicitly state the return value (e.g., 'returns a list of template names'), the verb 'List' sufficiently implies it.

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

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

The tool has zero parameters, so the description does not need to elaborate on parameter semantics. The baseline score for no parameters is 4, and the description appropriately avoids adding irrelevant detail.

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

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 as 'available measurement template presets'. This clearly distinguishes it from sibling tools like vna_load_template and vna_apply_template, which deal with loading/applying 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.

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

The context of listing templates before loading/applying is implicit and clear from the sibling tool names, but the description does not explicitly state when to use this tool versus alternatives. It lacks exclusionary guidance but the intended use is obvious.

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

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

With no annotations, the description carries full burden for behavioral disclosure. It only states that configuration is loaded/restored, but does not reveal whether this overwrites current settings, requires any specific device state, or has side effects. For a mutating operation, this lack of detail 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.

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

The description is a single concise sentence with no filler. It front-loads the core purpose clearly and efficiently, earning its place with zero redundancy.

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

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

Given the tool's complexity (restoring state, multiple siblings, no output schema, no annotations), the description is highly incomplete. It omits file format expectations, restore behavior, and relationship to save_state, leaving the agent with insufficient context to invoke confidently.

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

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

Schema coverage is only 33% (only filepath has a description) and the description does not compensate by explaining host or port. The description adds no parameter-level meaning beyond the schema's 'Path to state file' for filepath, leaving host and port semantically undocumented.

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

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

The description clearly states the action ('Load and restore') and the resource ('VNA configuration') with a source ('from file'). This distinguishes it from related tools like vna_save_state (save) and vna_load_template (template, not full configuration), though it does not explicitly name those alternatives.

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

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 vna_load_template, vna_apply_template, or vna_get_full_state. There is no mention of prerequisites (e.g., device connection) or scenarios where this tool is preferred.

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

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

With no annotations provided, the description must disclose behavioral traits, but it only says 'Load measurement template' without mentioning side effects (e.g., overwriting current settings), prerequisites (e.g., device connection), or whether this is a read-only or mutating operation. 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.

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

The description is a single concise phrase with no redundant words, and it leads with the verb. It is appropriately short, though it could benefit from additional context; the brevity is not penalized heavily.

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

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

The tool has 3 parameters, no output schema, and no annotations, so the description carries the burden of explaining the operation's full context. It only mentions loading a template and leaves out details about custom template behavior (center/span), return values, and prerequisites, making it incomplete.

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

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

The input schema already has 100% coverage with descriptions for all parameters, so the baseline is 3. The description adds minimal value by restating that template can be a preset name or file path, but it does not clarify the optional span_hz and center_freq_hz parameters beyond what the schema already explains.

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

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

The description clearly identifies the action ('Load') and the resource ('measurement template'), and adds specificity by noting it can be a preset name or file path. It is distinct enough from siblings like vna_apply_template, 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.

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 (e.g., vna_apply_template for applying templates or vna_load_state for loading full states). It merely states what it does, leaving the agent to infer context.

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

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

No annotations are provided, so the description carries the full burden. The description only restates the purpose and gives a vague 'around peak' behavior. It does not disclose whether it modifies marker state, requires a connection, what it returns, or any side effects. Minimal behavioral insight 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.

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

A single, concise sentence that is front-loaded with the key action and default value. No filler or redundancy; every word is meaningful.

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

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

The tool is simple but still lacks essential context: it does not state what the tool returns (e.g., a bandwidth value), whether it uses an existing marker or searches for the peak, or the required setup. With no output schema and no annotations, the description should provide more context 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.

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

Schema coverage is 50%: marker_num and bandwidth_level_db have descriptions, while host and port are not described (though likely standard connection params). The description adds slight context via 'or specified', indicating that bandwidth_level_db is customizable. Overall, it adds marginal value over the schema.

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

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

The description explicitly states the tool finds -3dB (or specified) bandwidth around a peak, using a specific verb ('find') and resource ('bandwidth'). It clearly distinguishes itself from sibling tools like vna_marker_search_min/max, which locate minima/maxima, and vna_get_marker, which reads marker values.

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

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

Usage is implied: one would use this when needing bandwidth information. However, there is no explicit guidance on when to use this versus alternative marker tools, no prerequisites (e.g., setting a marker or finding a peak first), and no mention of exclusions. It relies on the user's inference 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.

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

With no annotations, the description carries the full responsibility for behavioral disclosure. It only states the action of searching for a maximum value but does not describe side effects (e.g., moving a marker), requirements (e.g., existing marker), or return behavior.

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

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

The description is a single sentence lacking any structural detail. While concise, it is under-specified similar to the 'Process' example, failing to convey important context in an efficiently structured way.

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

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 description. It does not explain what 'search' entails (e.g., frequency/amplitude), how the search is initiated, or what the return value is. Given the presence of many sibling tools, more context is needed for appropriate selection.

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

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

Schema description coverage is only 33% (only marker_num has a description). The description adds no parameter explanation for host, port, or marker_num, and does not compensate for the missing schema documentation. No semantic value is added beyond the schema.

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

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

The description 'Search for maximum value in sweep' states a specific verb and resource, and the word 'maximum' distinguishes from sibling tool vna_marker_search_min. However, it is vague about what exactly is being searched (e.g., marker maximum) and lacks detail on the context.

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

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 vna_marker_search_min or vna_set_marker. No prerequisites or use cases are mentioned.

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

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 without mentioning side effects (e.g., marker movement), required state (e.g., a sweep already present), or output/return format. This is a minimal, non-explanatory statement.

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

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

The description is a single sentence and front-loaded with the key action, but it is under-specified, sacrificing necessary context for brevity. It is not as sparse as a tautology, but it could be more informative.

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

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 a sparse description, the tool's complete behavior is unclear. The description does not explain what 'minimum value' refers to, whether the marker is moved, or what the user will receive, leaving significant gaps.

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

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

Schema description coverage is only 33% (only marker_num has a description), and host/port are undocumented. The description itself does not mention any parameters, so it fails to compensate for the low coverage or add clarity beyond the schema.

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

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

The description uses a specific verb 'Search' with a resource ('minimum value in sweep') and the 'minimum' keyword distinguishes it from the sibling vna_marker_search_max. However, it omits that it operates on a marker (despite the name/parameter) and does not clarify what the search returns, preventing a 5.

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

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 vna_marker_search_max or other marker tools. No context is given about prerequisites such as an active sweep, a connected device, or the meaning of the return value, leaving the agent to guess.

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

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 the basic measurement action. It does not reveal whether the tool mutates state, requires prior setup, triggers a sweep, or what response format to expect.

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

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

The description is a single, short sentence that is front-loaded with the key action and target. It is concise without being padded, though it could potentially include a bit more context without losing its efficiency.

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

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

The tool has 3 parameters, no annotations, and no output schema, yet the description provides only a minimal one-line statement. Given the complexity of the VNA toolset and the presence of many related siblings, this description is insufficient for an agent to fully understand expected behavior, return values, or setup requirements.

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

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

Schema description coverage is low (only 33% describing frequency_hz). The description adds context that frequency_hz determines the measurement frequency, but it provides no additional meaning for the 'host' or 'port' parameters, which remain undocumented in both schema and description.

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

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

The description clearly states the verb 'Measure' and the resource 'insertion loss (S21)' at a specific frequency. It distinguishes itself from sibling tools like vna_measure_return_loss and vna_measure_vswr by explicitly naming the S-parameter (S21) and 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.

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

No explicit guidance is provided on when to use this tool versus alternatives. The description implies usage for a single frequency point, but it does not mention any prerequisites (e.g., connection, calibration) or contrast with sweep-based measurements or sibling tools.

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

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

No annotations are provided, so the description carries full responsibility. It only restates the measurement action and does not disclose prerequisites (e.g., connection, calibration), side effects, or output format. This falls short of the rubric's requirement for behavioral disclosure.

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

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

A single, front-loaded sentence with no filler. Every word earns its place, conveying the essential action and key parameter in a compact space.

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

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

The tool has no output schema and only partial parameter documentation. The description does not explain the return value, connection requirements, or any constraints on frequency. This is insufficient for an agent to confidently invoke the tool in a real context.

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

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

Schema coverage is only 33% (only frequency_hz has a description). The description adds 'specific frequency' but says nothing about host or port, which are 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.

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

Clearly states a specific action ('Measure') on a specific resource ('return loss (S11)') with a specific condition ('at specific frequency'). This distinguishes it from sibling tools like vna_measure_vswr and vna_measure_insertion_loss.

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

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

The description provides clear context for when to use the tool (measuring return loss at a specific frequency) and implicitly differentiates from alternatives by naming S11. It lacks explicit exclusionary guidance, but the context is sufficient for selection.

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

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

No annotations are provided, so the description carries the full burden. It only states the basic action and does not disclose whether the tool is read-only, requires an active connection, or alters the VNA state (e.g., sweeping or setting frequency). This is similar to the 'update_drive' example where insufficient behavioral context was given.

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

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

The description is a single concise sentence with no fluff or redundancy. Every word adds meaning, and it is front-loaded with the action.

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

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

For a simple measurement tool with no output schema and sparse parameter documentation, the description lacks essential context such as return value format, prerequisites, or how it relates to other measurement tools. It is minimally viable but leaves significant gaps 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.

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 documented). The description adds no explanation for host or port parameters, and does not compensate for the low schema coverage. The description does not mention any parameters at all.

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

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

The description clearly states the tool's action: 'Measure VSWR at specific frequency', which is a specific verb+resource combination. It distinguishes itself from sibling tools like vna_measure_return_loss and vna_measure_insertion_loss by focusing on VSWR.

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

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 vna_get_s_parameter or vna_measure_return_loss. The description does not mention prerequisites (like being connected) or context (e.g., single-frequency vs sweep).

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

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

With no annotations, the description carries the full burden. It states the action (disable RF output) and calls it 'safe state', but does not disclose side effects, reversibility, prerequisites, or impact on ongoing operations. This adds minimal value 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.

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

The description is a single, front-loaded phrase with zero wasted words. It sacrifices detail for brevity, but for the action it conveys, it is appropriately concise, though it omits any discussion of parameters or edge cases.

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

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 annotations, this description is incomplete. It does not explain what host and port refer to, what 'safe state' means, or what happens after disabling. The absence of output schema details further limits context.

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

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

The schema has 0% description coverage for the host and port parameters, and the description does not mention them at all. This leaves agents without any guidance on what values to supply, offering no compensation for the schema gaps.

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

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 'RF output', clearly distinguishing it from the sibling tool vna_output_on. The parenthetical '(safe state)' adds context that this is a deliberate safety action.

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

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

No explicit when-to-use guidance or alternatives are provided. While the name and 'safe state' hint at safety contexts, the description does not explain when to prefer this over vna_output_on or other tools.

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

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

There are no annotations to fall back on, so the description carries full responsibility. It discloses no side effects, safety concerns, or behavior when the output is already enabled. This is a critical gap for a hardware-affecting operation.

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

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

The description is a single, concise sentence, but it is overly terse and lacks any additional structure or context. While it is not verbose, the brevity comes at the expense of necessary information, making it merely adequate.

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

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

Given the tool affects RF output and has two connection parameters, the description should at least mention that a connection is required or describe the effect on the instrument. With no output schema and no extra context, an agent cannot reasonably infer safe and correct usage.

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

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

The input schema has two parameters (host and port) with zero description coverage. The description does not mention these parameters or their purpose, leaving the agent without any semantic understanding of what values to provide.

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

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

The description 'Enable RF output' clearly states a specific action with a resource, and the verb 'enable' distinguishes it from its sibling vna_output_off. However, it does not elaborate on what 'RF output' encompasses in the VNA context, 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.

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 needing an active connection or that it should be used before measurements, nor does it reference the sibling vna_output_off.

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

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 side effects, but it only says 'Preset VNA' without explaining what that entails (e.g., resetting all instrument settings, interrupting measurements). The SCPI command confirms it's a preset, but the behavioral impact is unexplained.

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

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

The description is exceptionally brief — a single phrase plus the SCPI command — with no wasted words. For a simple command-like tool, this is appropriately sized, although it lacks structure that could aid comprehension.

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

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 is missing critical context: no parameter explanations, no side-effect disclosure, and no mention of required state (e.g., connection). With no output schema, the description alone is insufficient for an agent to confidently invoke it.

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

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

The input schema shows two parameters (host and port) with zero descriptions, and the description provides no additional meaning for either parameter. With 0% schema coverage, the description completely fails to compensate for the lack of parameter clarity.

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

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

The description states the action clearly ('Preset VNA') and even includes the underlying SCPI command 'SYST:PRES' for precision. However, it does not differentiate from the sibling tool 'vna_reset', so there's some ambiguity about the exact scope of the preset operation.

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

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 like 'vna_reset' or 'vna_launch'. There is no mention of prerequisites or typical use cases, leaving the agent to infer when a preset is appropriate.

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

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

With no annotations, the description must carry the full transparency burden. It discloses the action is a reset to default state and adds the *RST SCPI command detail, but it does not mention side effects like clearing calibration, losing settings, or requiring a connection. This 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.

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

The description is a single, front-loaded sentence that conveys the purpose immediately. Every word earns its place, and there is no redundancy.

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

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: no mention of return values (no output schema exists), behavioral consequences, or parameter requirements. For a reset operation, it is unclear whether it affects the current connection or requires one. The minimalism leaves gaps for an agent.

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

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' or 'port'. While these parameter names are somewhat self-explanatory, the description adds no meaning about their role, optionality, or default values. The tool has 2 params and the description 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.

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

The description uses a specific verb 'Reset' with a clear resource 'VNA' and state 'default state (*RST)'. It is immediately clear what the tool does and differentiates it from siblings like vna_marker_* or vna_calibration_*, though it may overlap with vna_preset.

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

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 vna_preset or vna_calibration_start. It does not state prerequisites (e.g., connection) or exclusions. The context signal shows a sibling vna_preset, but no differentiation is made.

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

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 restates the tool's name. It omits details about file overwriting behavior, required permissions, or whether a connection is needed, leaving the agent uninformed about 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.

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

The description is a single, efficient clause with no redundant words. It is appropriately sized for a straightforward screenshot operation, though the brevity sacrifices informative content.

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

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

Given the simple operation but multiple parameters and no annotations or output schema, the description is too sparse. It fails to mention that host and port are likely connection parameters, and does not specify behavior on existing files or errors, making it incomplete for reliable invocation.

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

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

Schema coverage is only 33% (only filepath is described). The description adds no additional meaning for host or port parameters, and does not elaborate on filepath beyond the schema's '.png' note. With low coverage and no compensatory explanation, parameter semantics are weak.

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

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

The description 'Save VNA display screenshot' uses a specific verb ('save') and resource ('display screenshot'), clearly differentiating it from sibling tools like vna_save_touchstone (data file) and vna_save_state (state file). This makes the tool's purpose immediately apparent.

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

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 indicate when to use this tool versus vna_save_touchstone or vna_save_state, nor does it mention any prerequisites like connection requirements.

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

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

With no annotations, the description must fully convey behavior. It only states the action without disclosing side effects (e.g., file overwrite), connection requirements, or error behavior. This is insufficient for a write operation.

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

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

A single concise sentence that is front-loaded and contains no fluff. It efficiently states the core action without redundancy.

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

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 output schema or annotations, the description is too sparse. It lacks information about return values, prerequisites (e.g., connected VNA), file format expectations, and overwrite behavior.

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

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

Schema description coverage is 50% (filepath and notes have descriptions), but host and port are bare and unexplained. The description adds no parameter details, leaving essential connection parameters ambiguous.

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

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

The description 'Save current VNA configuration to file' uses a specific verb (Save) and resource (current VNA configuration) with a clear destination (file). It distinguishes itself from siblings like vna_save_touchstone (S-parameter data) and vna_save_screenshot (image output).

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

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 like vna_save_touchstone or vna_save_screenshot. The description implies usage for configuration state persistence but does not state exclusions or prerequisites.

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

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

No annotations are provided, and the description fails to disclose side effects such as file overwriting, required instrument state, or whether it exports all traces/channels. It only states the action without deeper 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.

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

Single concise sentence with no redundancy, highly scannable and front-loaded with the core action.

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

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

The tool has no output schema or annotations, and the description omits usage context (connection requirement, source of S-parameters, overwrite semantics), 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.

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

Schema covers only filepath (33% coverage) with a 'Output file path' description. The description adds file extensions but does not clarify the host and port parameters, which are left ambiguous.

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

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

The description clearly states the verb 'Export', the resource 'S-parameter data', and the target format 'Touchstone file (.s1p/.s2p/.s4p)', distinguishing it from sibling save tools like vna_save_screenshot and vna_save_state.

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

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

No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., active measurement, connection) or contrast with other save/export tools.

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

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 'send and return response' without mentioning timeouts, error handling, network requirements, or the nature of the response. This is minimal and does not add 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.

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 sized for a simple tool and easy to parse.

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

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

With no output schema and no annotations, the description should at least mention the response format or error behavior, but it only says 'return response' without specifics. For a network-based SCPI tool, this leaves important context missing, making the description minimally adequate at best.

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

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

Schema description coverage is only 33%, with only 'command' having a description. The description does not explain 'host' or 'port' defaults, validation, or their role, and it adds little beyond what the schema already states. It fails to compensate for the missing parameter documentation.

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

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

The description states a specific verb ('Send') and resource ('SCPI query') and notes the return response, which clearly distinguishes it from sibling vna_scpi_send. It is specific and action-oriented, though it doesn't explicitly name the alternative.

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

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 vs. alternatives like vna_scpi_send, and there are no exclusionary or contextual hints. The description implies it is for queries that expect a response, but this is not explicitly stated.

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

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 discloses the '(no response)' return behavior, which is useful, but omits other behavioral context such as connection requirements, potential side effects of sending raw commands, or error handling. This is a minimal level of transparency.

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

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

The description is a single, concise sentence with no filler. It front-loads the core action and includes the essential response behavior. Every word contributes to comprehension, making it highly efficient.

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

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

For a raw command tool with no annotations, output schema, or additional context, the description is under-specified. It lacks usage guidance, parameter elaboration, and safety/connection caveats that would be expected for a raw SCPI sender, leaving the agent without sufficient context to invoke it confidently in diverse scenarios.

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

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

Schema description coverage is only 33% (only 'command' has a description), and the description does not add any parameter-level details. The roles of 'host' and 'port' are left unexplained, and the format of 'command' is not elaborated, leaving notable ambiguity for an agent.

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

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 and resource: 'Send raw SCPI command' and explicitly notes '(no response)', which distinguishes it from sibling vna_scpi_query. This makes the purpose unambiguous and differentiates it from similar tools.

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

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

The '(no response)' qualifier implies when to use it (when a response is not needed) and indirectly points to vna_scpi_query for queries, but it does not explicitly name alternatives or provide exclusion criteria. The usage context is implied rather than directly stated.

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

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

Because there are no annotations, the description carries the full burden of behavioral disclosure. It merely states 'Configure sweep averaging' without explaining side effects, whether it overwrites existing averaging settings, if it requires an active connection, or any other behavioral traits. This is insufficient for a configuration action.

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

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

The description is extremely concise—one short phrase—which makes it easy to parse. However, it is borderline under-specified; it reads more like a label than a full description. It is not as tautological as 'Process', but it lacks the supportive detail expected for a functional description.

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

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

Given there are no annotations, no output schema, and incomplete parameter coverage, the description needs to provide more context. It does not mention connection requirements, default behavior, or how averaging affects measurements. The single sentence is too sparse to be considered complete for a configuration tool.

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

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

Schema description coverage is only 33% (only 'count' has a description). The tool description adds no additional meaning for 'host' or 'port', which remain entirely undocumented. While 'count' is described in the schema as 'Number of averages (1 = off)', the description itself does not explain how it relates to the sweep averaging behavior.

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

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

The description 'Configure sweep averaging' uses a specific verb ('configure') and identifies the resource ('sweep averaging'), clearly indicating the tool's function. However, it does not distinguish it from the sibling 'vna_configure_sweep', which might also be seen as configuring sweep-related settings, so it loses a point for lack of differentiation.

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

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 like 'vna_configure_sweep' or other sweep settings. There is no mention of prerequisites (e.g., needing a connected instrument) or context such as setting averaging before a measurement.

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

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 'Configure frequency via center and span' and does not mention any side effects, required state (e.g., connection), error conditions, or whether this is a write operation beyond the verb 'configure'.

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

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

The description is a single concise sentence that is front-loaded with the key action. There is no wasted wording, and every word earns its place.

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

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 is too thin for an agent to invoke the tool confidently. It omits information about how host and port are used, what the expected behavior is when parameters are out of range, and what the tool returns. For a simple setter, it is still incomplete because host and port are undocumented.

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

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

The schema already describes center_freq_hz and span_hz with basic descriptions. The tool description adds no extra meaning for these parameters and completely ignores the host and port parameters, which have no schema descriptions. At 50% schema description coverage, the description does not compensate for the missing parameter information.

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

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

The description 'Configure frequency via center and span' clearly states the action (configure frequency) and the method (center and span). It is specific enough to indicate the tool's role, though it does not explicitly distinguish it from sibling tools like vna_configure_sweep.

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

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 vna_configure_sweep. There is no mention of prerequisites, exclusions, or scenarios where another tool is more appropriate.

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

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 core action without disclosing whether this is a mutating operation, requires prior connection, or affects the instrument's display. There is no mention of side effects 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.

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

The description is a single, front-loaded sentence with no waste. However, it is under-specified, missing important contextual information. It is concise but not sufficiently informative for a standalone description.

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

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 far from complete. It fails to provide context about connection requirements, return values, or how the marker positioning relates to the sweep. The description only covers the minimal idea, leaving significant gaps for an agent to invoke the tool correctly.

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

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

Schema coverage is 50%, with host and port lacking descriptions. The description adds no meaning beyond what the schema already provides for frequency_hz and marker_num. It does not explain the purpose of host and port, leaving these parameters under-specified.

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

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

The description uses a specific verb 'Position' and resource 'marker', making it clear that this tool sets the marker's frequency. It distinguishes itself from sibling tools like vna_get_marker (read) and marker search tools (which find min/max). However, it could be slightly more explicit about the 'set' action.

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

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 vna_marker_search_min or vna_get_marker. There is no mention of prerequisites like being connected to a VNA or needing an active sweep. The usage context is only implied.

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

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

With no annotations, the description carries the burden. It explains the effect (compensating for delay and/or loss) but does not disclose potential side effects like overwriting existing port extension settings or that it affects subsequent measurements. It also doesn't mention the vna_port parameter, though the schema does. This is acceptable 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.

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

The description is a single, concise sentence that front-loads the action and purpose. It contains no filler and every word contributes to understanding the tool's function.

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

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

For a parameterized setter with a schema and sibling tools, the description is adequately complete. It covers the essential purpose and main input semantics. It doesn't explain return values (none expected) or prerequisites, but these are implicitly handled by the surrounding tool context and connection tools. Minor gap: no mention of the specific VNA port, though the schema covers it.

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

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

Schema coverage is 60%, so the description needs to add some meaning. It highlights the key parameters 'delay and/or loss', mapping to delay_s and loss_db_per_ghz. However, it doesn't clarify host, port, or vna_port beyond what the schema already provides. Overall, it adds moderate value over the schema.

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

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

The description states the specific action 'Set port extension' and its purpose 'to compensate for cables/fixtures (delay and/or loss)'. This clearly distinguishes it from siblings like vna_get_port_extension and vna_clear_port_extension, making the tool's role unambiguous.

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

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

The description implies when to use the tool (when needing to compensate for cables/fixtures) but does not explicitly address alternatives or when not to use it. No mention of sibling tools or prerequisites, so while the context is present, direct exclusions are missing.

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

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

With no annotations, the description must disclose behavioral traits, but it only states the action. It does not mention whether the output is turned on, whether changes are immediate or require a sweep, any side effects on existing settings, or valid power ranges. This provides no transparency into the tool's behavior.

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

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

The description is a single short sentence, which is concise and front-loaded. However, it is under-specified and lacks structure to convey usage or context, so while there is no wasted text, it is not appropriately sized for a tool with 4 parameters and no annotations.

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

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 annotations, and no output schema, the description is severely incomplete. It does not explain units, valid ranges, connection requirements, return behavior, or how the port parameter interacts with the VNA. This is inadequate for an agent to use effectively.

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

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

Schema description coverage is 75%, with descriptions for tcp_port, vna_port, and power_dbm. The description adds no additional parameter meaning beyond what the schema already provides; 'per port' aligns with vna_port, but this is already stated in the schema. Baseline of 3 is appropriate.

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

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

The description 'Set power level per port' clearly identifies the action (set) and the target (power level) with scope (per port). It distinguishes itself from sibling tools like output_on/off and measurement tools, though it could be more explicit about it being RF output power in dBm.

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

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., connection required), context for use (e.g., before measurements), or situations where this tool is not appropriate.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure, but it only states the bare action. It does not mention side effects, whether a connection is required, persistence of the hidden state, or how to reverse it.

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

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

The description is maximally concise and front-loaded with the verb 'Hide', containing no wasted words. However, it is under-specified, but conciseness itself is acceptable because every word contributes to the minimal meaning.

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

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

The tool has parameters, no output schema, and no annotations; the description provides no contextual information about prerequisites, expected behavior, return values, or how it fits into the larger VNA workflow. It is incomplete for an agent to use correctly.

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

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. The agent receives no guidance on what these parameters mean, whether they are required, or what values are expected.

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

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

The description clearly states the action (hide) and the resource (VNA software UI), distinguishing it from the sibling tool vna_software_show and other VNA tools. It is specific and unambiguous, even though it is brief.

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

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, no prerequisites, no exclusions, and no mention of the show counterpart. An agent has no context for when this should be invoked.

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

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 'Show' without explaining whether the application must already be running, whether it opens or brings to front, or what side effects occur. 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.

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

The description is a single concise sentence with no unnecessary words. It is front-loaded and efficient, though so brief that it edges toward under-specification. Still, it earns its place by conveying the basic action.

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

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 two undocumented parameters, the description leaves major gaps. The agent would not know how host and port are used, whether software must be running, or what the expected result is. It is insufficient for a complete understanding.

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

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

The schema has two parameters (host, port) with no descriptions and 0% schema coverage. The description does not mention these parameters at all, so the agent has no hint about their meaning or how they affect the tool's behavior.

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

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

The description uses a clear verb 'Show' and a specific resource 'VNA software UI', which distinguishes it from the sibling vna_software_hide. However, it does not clarify whether it launches the UI or brings an existing window to the foreground, so it is not fully precise.

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

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. The existence of vna_software_hide suggests a show/hide pair, but the description gives no context on appropriate usage or prerequisites.

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

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

No annotations are present, so the description carries the burden. It does disclose the key behavior of triggering and waiting for completion, but it lacks details on error handling, return value, or side effects. This is minimally adequate but not comprehensive.

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

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

One concise, front-loaded sentence with no redundant words. It is appropriately sized for the simplicity of the action, and every word adds value.

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

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

The tool has no output schema or annotations, and the description is sparse. It does not explain what happens after completion (e.g., where results are stored), how it relates to data retrieval tools, or the behavior when timeout is exceeded. For an AI agent, this context is insufficient.

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

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

Schema description coverage is only 33% (only timeout has a description). The tool description does not elaborate on host, port, or timeout semantics, beyond what the schema already provides. Given the low coverage, the description should compensate but does not, leaving host/port meaning ambiguous.

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

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

The description uses a specific verb 'trigger' and resource 'single sweep', clearly distinguishing it from sibling tools like vna_configure_sweep or vna_get_s_parameter. The added 'wait for completion' states the blocking 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.

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, no mention of prerequisites (e.g., connection, configured sweep), and no reference to sibling tools. It simply states what it 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.