siglent-sdg-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource or action: connection management, identification, output control, basic wave, modulation, sweep, burst, arbitrary wave, reset, channel copy, sync, phase, and raw SCPI. The get/configure pairs are clearly separated by waveform function, and the two SCPI tools are explicit escape hatches.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern with get_ and configure_ pairs (e.g., get_output/configure_output, get_sweep/configure_sweep). Minor deviations include set_arbitrary_wave instead of configure_arbitrary_wave, and equal_phase/copy_channel which don't follow the get/configure convention.
Tool Count4/5
At 21 tools, the server is slightly above the ideal 3-15 range but remains reasonable given the feature-rich scope of a waveform generator (connection, output, multiple wave modes, arbitrary waves, sync, phase, SCPI). Some redundancy exists (identify vs connect returning IDN), but each tool covers a distinct capability.
Completeness5/5
The tool set provides comprehensive coverage of the waveform generator's core lifecycle: connection, identification, output configuration, basic wave, modulation, sweep, burst, arbitrary wave selection, synchronization, phase alignment, and reset. The inclusion of scpi_query and scpi_command as escape hatches ensures any unmodeled functionality is still accessible.
Average 3.9/5 across 21 of 21 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=false indicates a write operation, but the description adds no further behavioral context. It does not explain side effects, reversibility, or how parameters affect behavior (e.g., state ON/OFF enables/disables the sync output). The description essentially restates the tool's name without disclosing additional traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is short and to the point. It is appropriately sized for the simplicity of the tool, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description and schema together give a basic understanding of the tool's purpose and parameters, but the description lacks usage context and behavioral nuance. For a simple configuration tool with a rich schema, this is minimally complete but leaves gaps around when to use it and what happens when invoked.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: each parameter has a clear description (type, state, channel). The tool description adds no extra parameter semantics, so the baseline score of 3 is appropriate as the schema fully documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action and resource: 'Configure the sync output signal for a channel.' This distinguishes it from other configure tools like configure_output or configure_modulation, though it does not explicitly contrast them. The verb and resource are specific enough for basic purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not provide context such as typical use cases, prerequisites, or exclusions. Given the presence of sibling tools like configure_sweep and configure_burst, the lack of usage direction is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=false indicates a mutation, but the description only restates the action ('synchronize') without disclosing side effects, prerequisites, reversibility, or whether the operation is destructive. It adds no behavioral context beyond what the name and annotation already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences, front-loaded with the primary action. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool, the description adequately explains the core purpose. However, it fails to clarify how this differs from the related sibling 'configure_sync' or to mention any prerequisites or consequences of use. This could lead to confusion for an agent deciding between tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description does not need to explain parameter meanings. The baseline of 4 is appropriate since the tool's operation is clear from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Synchronize'/'Aligns') and the resource (phase of channels C1/C2). It identifies the operation without ambiguity, but it does not explicitly differentiate from the sibling tool 'configure_sync', which might also deal with synchronization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when phase alignment between C1 and C2 is needed), but it provides no explicit guidance about when not to use it or what alternatives exist. No exclusions or comparison with related tools like 'configure_sync' are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, confirming a write operation. The description aligns with this and adds the specific configurable aspects (state, load, polarity). However, it does not disclose side effects, prerequisites, or persistence, so it adds only moderate behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main action and specific options. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with 4 parameters and a comprehensive schema. The description explains the core function but omits usage context (e.g., when to configure, interaction with connect/disconnect) and return behavior. It is minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 4 parameters. The description summarizes the three main parameters (state, load, polarity) but does not add any new meaning beyond what the schema already documents. Baseline 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Configure the output of a channel' and lists specific capabilities (turn output on/off, set load impedance, set polarity). This is a specific verb+resource combination that distinguishes it from sibling tools like configure_basic_wave or get_output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no scenarios. It simply states what the tool does, without any contextual cues for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=false already indicates a mutation operation, and the description adds no further behavioral context. It does not mention side effects (e.g., overwriting the existing waveform), prerequisites, or persistence. The description essentially restates the tool's function without exposing additional behavioral traits beyond what the annotation provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and followed by concise usage examples. Every sentence adds value, with no redundant filler. It is exceptionally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters with only channel required. The description explains the two methods (index/name) but does not clarify that at least one of them must be provided or whether they are mutually exclusive. This is a significant gap because the schema allows omitting both, which would lead to an invalid call. The description otherwise covers the main usage well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter with descriptions and examples. The tool description repeats some examples (2=StairUp, 18=Sinc, 26=Cardiac) and adds the index/name distinction, but this information is already present in the schema. The description adds marginal value, aligning with the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Set the arbitrary waveform for a channel by index number or by name.' It names the resource (arbitrary waveform), the target (channel), and the two selection methods. While it doesn't explicitly differentiate from sibling tools like configure_basic_wave, the purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: 'Use index for built-in waveforms ... or name for user-defined waveforms.' This tells the agent exactly when to use each parameter. It doesn't discuss alternatives like get_arbitrary_wave, but it gives clear context for using this tool effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint:false, so the description carries the burden for behavioral disclosure. It adds context about building a single BSWV command, hinting at atomicity/efficiency, but doesn't mention prerequisites (e.g., setting waveform_type), validation of parameter combinations, or side effects beyond the mutation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief overall, but the second and third sentences ('Multiple parameters can be set in a single call' and 'builds a single BSWV command with all specified parameters') are redundant, repeating the same idea. It is front-loaded but could be tightened without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 18 parameters, no output schema, and minimal annotations, the description is under-specified. It doesn't explain parameter dependencies (e.g., some params are only valid for specific waveform types), mutual exclusivity (frequency vs. period), or the need to set waveform_type first. The schema describes each parameter individually, but the description fails to synthesize this into a coherent usage model.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema itself documents each parameter's meaning and constraints. The description adds little beyond noting that multiple parameters can be set at once, which doesn't deepen understanding of individual parameter semantics or relationships like mutual exclusivity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Configure the basic waveform parameters of a channel' with a specific verb and resource. It distinguishes itself from sibling tools like configure_modulation, configure_sweep, and configure_output by focusing on basic waveform parameters, and the name reinforces this scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it doesn't explicitly name alternatives, the context is clear: it is for basic waveform parameters and supports batching multiple parameters in a single call. This implies when to use it (for basic wave settings) but lacks explicit exclusions or comparisons to siblings like configure_modulation or configure_sweep.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'Returns device identification on success' and specifies TCP, but it does not disclose that the connection is persistent or that it should be terminated with 'disconnect'. Annotations provide openWorldHint=true but do not cover connection lifecycle. The description is adequate but not rich in behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the primary action and mention the success return value. No redundant or vague wording; every sentence contributes valuable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple connection tool, the description covers the essential aspects: connection address, protocol, and return value. It is slightly incomplete by not stating that the connection persists or that 'disconnect' should be used, but the sibling tool list makes this inferable. Overall, it is well-rounded for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with host and port both having descriptions including defaults and environment variable fallback. The description adds no new parameter-specific semantics beyond mentioning TCP, which is already implied by the port default of 5025. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's function: 'Connect to a Siglent SDG waveform generator over TCP.' It uses a specific verb (Connect), identifies the resource (Siglent SDG waveform generator), and specifies the protocol (TCP), making it distinct from siblings like 'disconnect' and 'identify'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool should be used before other operations (as it establishes a connection), but it does not explicitly say 'use before sending commands' or mention alternatives. There is no exclusion guidance, but the purpose is self-evident given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=false already signals that this tool changes state. The description adds no extra behavioral context beyond that, e.g., whether it is idempotent, what side effects occur on the device, or whether it closes sockets gracefully.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence that is front-loaded and contains no superfluous words. It earns its place by stating the exact action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no params, no output schema, simple action), the description is essentially complete. It could optionally mention that it is the inverse of 'connect', but that is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so no additional parameter explanation is needed. The baseline of 4 applies because the schema fully covers the (nonexistent) parameter surface.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Disconnect') and resource ('waveform generator'), clearly stating the action. It distinguishes itself from siblings like 'connect' and 'reset' by naming the operation directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: it is the counterpart to 'connect'. However, there is no explicit guidance on when to use it vs alternatives like 'reset' or 'idle', nor any mention of prerequisites or post-conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares the operation is safe, and the description matches with 'Get'. The description adds value by listing the specific parameters included, but does not disclose return format, error behavior, or any side effects. Given the annotation covers the main safety concern, a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and resource. It avoids fluff and provides a useful list of example parameters, earning its place without excess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with a readOnlyHint, the description plus schema is mostly complete. It identifies the purpose, the target channel, and key parameters. It lacks return format, but the absence of an output schema lowers this need; still, a brief mention of what the response includes would have made it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter 'channel' has a clear description and enum of C1/C2. The tool description does not add anything beyond the schema, so it relies on the schema for parameter meaning. Baseline 3 is warranted due to full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets basic waveform parameters (type, frequency, amplitude, etc.) from a channel. The verb 'Get' plus resource 'basic waveform parameters' is specific and distinguishes it from sibling get_* tools like get_modulation and get_sweep.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: the tool is for reading basic waveform settings, contrasting with configuration tools like configure_basic_wave. However, there is no explicit guidance on when to choose this over other get_* tools or what to do if the channel is invalid. The 'etc.' at the end leaves scope slightly ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a safe read operation. The description adds value by listing the sweep parameters returned, which is helpful given there is no output schema. However, it does not elaborate on possible error conditions, exact return format, or any other behavioral details beyond the field list, so it is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core purpose ('Get the sweep parameters of a channel') and then lists the specific parameters. It contains no filler, redundancy, or irrelevant information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is only one parameter and no output schema, the description gives a good overview of what will be returned by enumerating the sweep parameter fields. It could be more explicit about the return structure or units, but for a straightforward read-only getter, it is sufficiently complete for an agent to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single 'channel' parameter with an enum and a clear description ('Channel to query'), so the schema description coverage is 100%. The tool description does not need to add parameter details, and the baseline of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('sweep parameters of a channel'), and enumerates the major fields included (state, frequencies, mode, direction, trigger source, etc.). This makes it easily distinguishable from sibling tools like configure_sweep (set) and other get_* tools (which target different resources).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, such as configuring sweep with configure_sweep. The usage is implied by the 'get' verb and the presence of a corresponding configure tool, but no explicit comparison or exclusion is provided. This falls under implied usage, which aligns with a score of 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false, indicating a mutation. The description beyond that reveals the SCPI command and that it resets to factory defaults, but does not mention potential side effects such as losing current settings or affecting all channels. Since annotations are minimal, the description carries the burden, yet it adds limited behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the purpose including the SCPI command. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no parameters and no output schema, the description covers the basic function. It could mention side effects like all settings being overwritten, but for a simple reset command it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the input schema is empty. The baseline is 4 because no parameter documentation is needed. The description appropriately omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'reset', the target 'waveform generator', and the result 'to factory default settings'. It also includes the SCPI command (*RST) for precision. This is distinct from any sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description simply states what it does without context on preferability or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a useful behavioral detail: it 'Builds a single BTWV command with all specified parameters.' This goes beyond the basic readOnlyHint annotation by revealing the command construction. However, it does not disclose whether the command is actually sent, how errors are handled, or whether parameters are validated, which is significant for a tool with 19 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no redundant information. It front-loads the purpose and includes an essential usage note, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a complex tool with 19 parameters and no output schema, the description covers the key prerequisite but omits details about execution behavior, validation, and possible error states. The rich schema descriptions compensate for some gaps, but the description alone leaves important context unclear, such as whether the BTWV command is immediately applied or merely built.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% description coverage for all 19 parameters, so the baseline is 3. The description adds the important cross-parameter dependency that 'State must be set to ON before other parameters,' which is not fully captured in the schema. This is valuable but minimal, as all individual parameter meanings are already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Configure burst mode'), the target resource ('on a channel'), and the implementation approach ('Builds a single BTWV command'). This distinguishes it from sibling tools like configure_modulation or configure_sweep, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit ordering guideline: 'State must be set to ON before other parameters.' This is a key usage condition. It does not explicitly name alternatives or exclusions, but the focus on burst mode and the mention of BTWV command imply when it should be used relative to other configuration tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate this is not read-only, and the description adds that all parameters are copied. However, it does not disclose edge cases like source and destination being the same channel or explicitly state that the destination's existing settings are overwritten.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It front-loads the action and identifies the operand immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two well-described enum parameters and no output schema, this description is largely complete. It could mention overwrite behavior, but that is not essential given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with clear descriptions and enumerations, so the description adds little beyond the schema. This matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('copy') and identifies the exact resource ('all parameters from one channel to another'). It clearly distinguishes this tool from the surrounding get_/configure_ siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use it to duplicate all parameters between channels. It does not explicitly mention alternatives or when not to use it, but the purpose is self-evident from the sibling tool set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description reinforces this with 'Get'. The description adds value by listing the specific attributes returned, which helps the agent understand the tool's output scope. It does not contradict annotations, and the added context goes beyond the minimal read-only hint, though it stops short of providing return format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose ('Get the burst wave parameters of a channel') and then lists the included parameters without unnecessary words. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only query tool with one fully documented parameter, the description adequately covers purpose and return content. No output schema exists, so the description carries the burden of explaining return values, which it does by listing them. It lacks explicit return format or error conditions, but the simplicity of the tool makes this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single 'channel' parameter completely with type, enum (C1/C2), and description 'Channel to query'. The description's phrase 'of a channel' adds no new semantic meaning beyond the schema. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies a get operation for 'burst wave parameters of a channel' and enumerates the exact parameters covered (state, period, trigger source, burst mode, cycle count, carrier settings, delay). This distinguishes it from sibling get_* tools like get_basic_wave or get_modulation, and from configure_burst which is the write counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying burst settings but does not explicitly state when to use this tool versus configure_burst or other get_* tools. There is no mention of alternatives or conditions for use, so it earns an average score for implied but not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, which sets the safety baseline. The description adds a valuable behavioral detail by noting CHDR is OFF, so responses contain only values without headers. However, it does not mention potential errors from malformed arbitrary commands or timeout behavior, which is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: purpose, usage, and an important response-format caveat. It is front-loaded and free of redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the essential aspects: what it does, when to use it, and a key response-format nuance. With readOnlyHint and full schema coverage, it is fairly complete for an escape-hatch tool, though it could mention error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both command and timeout_ms documented with examples. The description does not add further parameter-specific details beyond what the schema provides, so a baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send an arbitrary SCPI query to the waveform generator and return the response,' specifying the verb, resource, and action. It distinguishes itself from siblings by positioning itself as an escape hatch for commands not covered by other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this as an escape hatch for commands not covered by other tools, providing clear when-to-use context. It does not explicitly name alternatives like scpi_command for write commands, so it's not fully exhaustive but still offers solid guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds meaningful behavioral context by explicitly stating what is returned (waveform index and name), going beyond the bare annotation. It does not contradict the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the action and resource, and every word is necessary. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one enum parameter and no output schema, the description fully covers what the tool does and what it returns. The readOnlyHint annotation supplies the safety context, and the schema covers the parameter, making the description complete for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the channel parameter fully documented via enum and description. The tool description does not add further semantic detail beyond repeating 'channel,' so it meets but does not exceed the baseline expected when the schema carries the parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb 'Get' and identifies the exact resource: 'current arbitrary waveform selection for a channel.' It also states the return value (waveform index and name), which differentiates this getter from siblings like get_basic_wave or get_modulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use when querying the current arbitrary waveform selection, but it does not explicitly state when to use this tool versus alternatives or mention the sibling set_arbitrary_wave. The usage context is implied rather than directly expressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to cover safety. It adds value by listing the specific fields returned, but does not detail return format, error behavior, or other behavioral aspects. This aligns with a baseline of 3 for tools with annotations and partial added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and object, with no wasted words. It conveys the necessary information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only, no output schema), the description is complete. It specifies what is returned and the scope (channel). The annotations cover the read-only nature, and the schema covers parameter details, so no further information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a 100% description coverage for the single parameter 'channel', with a clear description and enum values. The tool description adds no further semantic meaning beyond what the schema already provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Get'), the resource ('output state of a channel'), and the specific attributes returned (on/off status, load impedance, polarity). It is easily distinguished from sibling tools like configure_output, which would set these values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for reading the current output state of a channel, which is clear given the name and the sibling tool 'configure_output' for writing. However, it does not explicitly state when to use this instead of other getters or mention exclusions, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include readOnlyHint: false, indicating mutation. The description adds meaningful behavioral context by revealing the SWWV command construction and the dependency on state being ON first, which goes beyond the minimal annotation. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. The purpose is front-loaded ('Configure sweep on a channel') and the second sentence delivers a critical usage constraint. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 24 parameters and no output schema, the description covers the most important non-obvious behaviors: the state ordering prerequisite and the command-building approach. The schema fully handles parameter details. Could potentially mention defaults or what gets overwritten, but overall sufficient for a configuration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with individual parameter descriptions, so baseline is 3. The description's phrase 'all specified parameters' adds no new parameter-specific meaning; the schema already documents each field thoroughly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Configure sweep on a channel' with a specific verb and resource, distinguishing it from sibling tools like get_sweep (read) and other configure_* tools. The second sentence about building a single SWWV command adds useful implementation-specific detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly gives a usage ordering requirement: 'State must be set to ON before other parameters.' This is a clear directive for correct invocation. It does not explicitly name alternatives, but the tool's name and sibling set imply this is for configuring sweeps versus reading them via get_sweep.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description only needs to add context about behavior. It does so by listing what settings are returned ('type, source, frequency, depth/deviation, and carrier parameters'), which goes beyond the annotation. No contradictions or missing safety information are apparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the purpose and then provides a concise list of returned content. Every clause adds value, and there is no redundant or extraneous language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with a provided readOnly annotation, the description is sufficiently complete: it specifies the resource, the channel parameter, and the categories of returned settings. No output schema exists, but the description gives an adequate high-level overview of the return value, which is all that is needed for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'channel' parameter is described as 'Channel to query'), so the baseline is 3. The description does not add additional parameter semantics beyond restating 'channel', so it earns the baseline without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('modulation parameters of a channel'), making the tool's function unambiguous. It also enumerates the exact settings returned (type, source, frequency, depth/deviation, carrier), which further distinguishes it from sibling getters like get_basic_wave or get_sweep.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for reading modulation settings, and given the sibling list includes configure_modulation (the write counterpart), the use case is clear. It does not explicitly state 'when to use' or alternatives, but there are no alternative read tools for modulation, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations only providing readOnlyHint=false, the description adds valuable behavioral context: 'no response expected' clarifies the tool returns nothing, and 'arbitrary SCPI command' implies potential side effects. It doesn't warn about safety, but the readOnlyHint already signals mutation. This is solid transparency beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every clause earns its place. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers the essential context: what it does, when to use it, and the lack of response. The schema covers input format, so the description is fully sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the only parameter 'command' with examples (100% coverage). The description adds no additional parameter meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Send') and resource ('arbitrary SCPI command to the waveform generator'), clearly stating the tool's action. It also distinguishes itself from siblings by explicitly noting 'no response expected' and framing as an escape hatch for commands not covered by other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use this as an escape hatch for commands not covered by other tools.' It also implies when-not-to-use by noting 'no response expected,' distinguishing it from scpi_query. However, it does not name the alternative sibling explicitly, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint:false annotation, the description discloses the sequential execution behavior: state, then type, then type-specific parameters, then carrier parameters. This adds valuable insight into the tool's operation, though it does not cover error handling or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three sentences, front-loaded with the purpose and then the key usage sequence. Every sentence contributes essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 15 parameters and no output schema, but the schema fully documents each parameter. The description adds the crucial state-first prerequisite and command sequencing, which are essential for correct invocation. It could be more explicit about which parameters apply to which modulation types, but that is partially hinted at with 'type-specific parameters' and covered by enum descriptions in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the ordering and dependency of parameters (state first, type before type-specific parameters), which is not captured in the schema itself. This helps the agent understand how parameters interrelate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Configure modulation on a channel.' This clearly distinguishes it from sibling tools like configure_output or configure_basic_wave. The purpose is unambiguous and action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear procedural context: 'Set state first (ON), then type and parameters' and explains the sequential command ordering. While it does not explicitly mention alternatives or when-not-to-use, the ordering guidance is a strong usage guideline for this complex tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates this is a safe read operation. The description adds value by specifying the exact return fields (manufacturer, model, serial, firmware) and the SCPI command, providing context beyond the annotation. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and includes essential details (SCPI command and return data). Every word contributes value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, read-only, no output schema), the description fully covers what the tool does and what it returns. It is complete for an agent to select and invoke this tool correctly, even among many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100% (empty schema matches no-parameter invocation). Per the baseline for zero-parameter tools, a score of 4 is appropriate, as there is nothing additional to explain about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool performs a query for waveform generator identification using the *IDN? command, which clearly distinguishes it from sibling tools like get_output or configure_output. It also lists the specific data returned (manufacturer, model, serial, firmware), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it queries identification, which is clearly the tool for retrieving device identity. While it does not explicitly mention alternatives or exclusions, no sibling tool serves this purpose, so the context is clear and no additional guidance is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![siglent-sdg-mcp MCP server](https://glama.ai/mcp/servers/MagnusJohansson/siglent-sdg-mcp/badges/card.svg)](https://glama.ai/mcp/servers/MagnusJohansson/siglent-sdg-mcp)

Score Badge

Copy to your README.md:

[![siglent-sdg-mcp MCP server](https://glama.ai/mcp/servers/MagnusJohansson/siglent-sdg-mcp/badges/score.svg)](https://glama.ai/mcp/servers/MagnusJohansson/siglent-sdg-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MagnusJohansson/siglent-sdg-mcp'

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