MHS-5200A MCP Server

by NaoNaoMe

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
All 16 tools have distinct, clearly defined purposes with no overlap. Each tool addresses a specific function (e.g., connect, set_frequency, upload_arb_waveform) with unique parameters.
Naming Consistency5/5
Tool names consistently follow the 'mhs5200_verb_noun' pattern in snake_case. Variations like 'upload_arb_waveform' (verb_adj_noun) are minor and still predictable.
Tool Count5/5
16 tools provide comprehensive coverage for a signal generator's typical operations without being excessive. The scope is well-scoped for the domain.
Completeness4/5
Covers most expected operations (connection, waveform, frequency, amplitude, etc.), but lacks per-channel output control (only global) and possibly impedance or reset functions.
Average 4.1/5 across 16 of 16 tools scored. Lowest: 3.5/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
- Last stable release on February 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, idempotent, and non-destructive behavior. The description adds value by stating that attenuation is automatically adjusted for optimal output, which is a behavioral trait not captured in annotations. It also describes the return format (JSON confirmation). No contradictions detected.
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 concise, using four brief sentences plus a structured 'Args' section. It front-loads the main purpose and avoids unnecessary details. The structure is clean and easy to scan.
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 behavior: setting amplitude, automatic attenuation, and return format. Annotations fill in safety and idempotency. However, it does not mention that the device must be connected or any other prerequisites, which would enhance completeness for a new user.
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 description includes an 'Args' section listing channel and vpp with types and ranges, but this largely mirrors the input schema's property descriptions. Since the schema already provides detailed descriptions, the description adds minimal new semantic information. However, the description does present the information in a clear, consolidated manner.
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 purpose: 'Set the peak-to-peak voltage for a channel.' It uses a specific verb and resource, and the mention of automatic attenuation adjustment adds specificity. However, it does not explicitly differentiate itself from sibling tools, which all set different parameters.
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 like mhs5200_set_frequency or mhs5200_set_waveform. It does not mention prerequisites (e.g., device must be connected) or contexts where this tool is inappropriate. Users are left to infer from the name and siblings.
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?
While annotations indicate the tool is not read-only, the description contains an internal contradiction: it states this tool only sets parameters, but the Returns section says 'JSON confirming sweep configuration and start.' This implies the tool might start the sweep, conflicting with the instruction to use `mhs5200_set_sweep` for start/stop. Such inconsistency lowers transparency.
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 concise, front-loaded with the purpose, and includes structured `Args` and `Returns` sections. However, the contradiction in the Returns section detracts from clarity, preventing a perfect score.
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 provides enough context to use the tool alongside its siblings, but it omits details about error handling, parameter validation, or behavior when sweep is already configured. The internal contradiction also reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for each parameter. The tool description's `Args` block repeats this information without adding significant new meaning (e.g., constraints like min/max are already in schema). Therefore, the description offers marginal extra value beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Set sweep parameters for a channel' with a specific verb and resource. It explicitly distinguishes from the sibling tool `mhs5200_set_sweep`, which is used to start/stop the sweep, making the tool's role clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use mhs5200_set_sweep to start/stop the configured sweep.' This tells the agent when to use this tool (for configuration) and when to use an alternative (for execution), fulfilling the dimension well.
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 provide idempotentHint=true and destructiveHint=false. The description adds that it returns JSON confirming the setting, but does not disclose error conditions, required permissions, or side effects (e.g., disables sweep?). Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a one-line purpose, clear parameter list, and return statement. No wasted words, front-loaded with the main 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 tool's simplicity and the annotations, the description is nearly complete. It covers the key parameter semantics and return value. However, it could mention that the frequency must be within the model's supported range and that setting frequency might affect sweep settings if active.
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?
Despite 0% schema description coverage, the description adds meaning beyond the schema: it mentions the frequency range '0.01 to max supported by model' and that channel is '1 or 2', which aligns with the schema but provides additional context on the range limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'output frequency for a channel', distinguishing it from sibling tools like set_amplitude or set_duty_cycle.
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 (e.g., set_sweep or configure_sweep). The description only states what it does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds context about device memory and confirmation, but no new behavioral traits beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear paragraphs and bullet points, but the Args/Returns section is somewhat redundant with the schema and output schema, adding slight verbosity.
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?
Despite the tool's moderate complexity, the description thoroughly covers data requirements, file formats, and return value, leaving no major gaps given the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already includes descriptions for both parameters (arb_index and filepath). The description adds the mapping to ARB00-ARB15 and the 2048 midpoint value, but this is marginal additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('upload') and resource ('custom arbitrary waveform data to device memory'), distinguishing itself from sibling tools like mhs5200_set_waveform which likely handle preset waveforms.
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 provides detailed data requirements (2048 samples, 0-4095 range) and file formats, but does not explicitly contrast with alternatives or specify when to upload custom waveforms vs using other functions like set_waveform.
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 indicate the tool is mutating but idempotent and non-destructive. The description adds no additional behavioral context beyond the annotations, such as side effects or authentication requirements. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with an Args section and Returns note. It avoids unnecessary words, though the front-loaded purpose sentence could be slightly more prominent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description adequately covers the tool's behavior and parameters. It clearly explains the allowed waveform values and channel range, making it easy for an agent to use.
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 description lists the two parameters (channel and waveform) and their allowed values, which mirrors the information already present in the input schema descriptions. Given that schema description coverage is 0% (though schema actually includes descriptions), the description adds no new semantic value beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set the waveform type for a channel,' using a specific verb ('set') and resource ('waveform type for a channel'). This uniquely identifies the tool's function and distinguishes it from sibling tools like mhs5200_set_amplitude or mhs5200_set_frequency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool—specifically for setting the waveform type on a channel. However, it does not explicitly mention when not to use it or suggest alternatives, which would improve 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 already indicate idempotentHint=true and destructiveHint=false. The description adds that the setting primarily affects square waves, which is useful. However, it does not elaborate on side effects, required permissions, or behavior on invalid inputs beyond the schema's constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a brief Args/Returns layout. Every sentence carries essential information, and the primary action is stated upfront. 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?
The description is adequate for a simple tool with a single nested parameter. It covers the action, effect, and return type. The annotations provide safety guarantees. Minor omission: no mention that the channel defaults to 1, though that is 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?
The input schema already describes both parameters with titles and ranges. The tool description adds the crucial context that the duty cycle primarily affects square waves, which is beyond the schema's generic description. This extra semantic adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set the duty cycle for a channel'. It specifies the primary effect on square waves, which adds precision and distinguishes it from other set_ tools like set_amplitude or set_frequency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, such as when changing square wave duty cycle is appropriate. The usage is implied by the function name and context, but no when-not or alternative conditions are mentioned.
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 provide non-readOnlyHint (false), destructiveHint (false), and idempotentHint (true). The description confirms it is a write operation that returns a JSON confirmation, adding minimal extra behavioral context. No contradictions exist, but the description does not disclose additional traits like authorization or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for the core action, then a clear 'Args' and 'Returns' section. Every sentence serves a purpose, no fluff. It is front-loaded with the key verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with an output schema (mentioned as returning JSON) and good annotations, the description covers the main action, parameters, and return type. It does not mention prerequisites like a prior connection (handled by sibling mhs5200_connect) or error handling, but these are reasonable gaps 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 contains descriptions for both 'channel' and 'inverted' (e.g., 'True to invert (flip vertically) the waveform output'). The description's 'Args' section mirrors this, adding 'False for normal' for inverted. Since schema coverage appears high (descriptions present), the description adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Invert (flip vertically) the waveform output for a channel.' This is a specific verb (invert) on a clear resource (waveform output for a channel), and the context of siblings (e.g., set_amplitude, set_waveform) makes it distinct. The description also details the purpose via parameter explanation, leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/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, but its narrow purpose (inverting/flipping waveform) clearly distinguishes it from siblings like mhs5200_set_waveform or mhs5200_set_amplitude. The context is clear, but no exclusions or when-not-to-use guidance is provided.
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 description correctly indicates it enables or disables outputs, and annotations confirm idempotency and non-destructiveness. The return type ('JSON confirming the output state') is stated. No side effects or hidden behaviors are omitted, though additional context about state persistence would be beneficial.
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 concise, using a single sentence for purpose and a clear list for parameters and return value. It avoids unnecessary fluff. However, the args section could be integrated into the main description to reduce redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple boolean toggle with an output schema (though not provided in detail), the description gives enough context. It mentions the return type, and the tool's scope ('all signal outputs') is clear. The annotations fill in safety and behavior gaps. It is adequate but could include a note on effect on other settings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a detailed description for the 'enabled' parameter ('True to enable all outputs, False to disable'), and the description's repetition adds minimal extra value. With 0% schema coverage as per context, the description does partially compensate, but it merely echoes the schema without deeper semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Enable or disable all signal outputs.' It uses a specific verb ('Enable or disable') and specifies the resource ('all signal outputs'). This distinguishes it from sibling tools like mhs5200_set_amplitude or mhs5200_set_frequency, which control individual parameters.
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 for global output control without explicit when-to or when-not-to guidance. However, the purpose is straightforward and the differentiation from siblings is clear due to the focus on 'all signal outputs.' A small mention of alternatives or prerequisites would improve it.
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?
Description adds sign convention (positive = CH2 leads) beyond annotations. idempotentHint and destructiveHint are already covered. Could mention prerequisites like connection state.
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?
Concise but includes Args and Returns sections which are unnecessary given schema and output schema. Still compact and front-loaded with key 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?
Adequate for a simple setter with output schema. Could mention that it modifies device state or requires connection. Given sibling tools, completeness is reasonable.
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?
Adds meaning beyond schema by explaining positive/negative lead/lag relationship. Schema also has description, but this reinforces it. Helpful for correct agent usage.
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 'Set the phase offset of CH2 relative to CH1' with specific verb and resource. Distinguishes from siblings like set_frequency or set_amplitude.
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?
No explicit guidance on when to use this tool versus alternatives. It is implied for phase adjustment but lacks context on prerequisites or conflicts with other settings.
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 indicate idempotentHint=true and destructiveHint=false, which the description does not contradict. The description adds that the tool returns a JSON confirmation of the power amp state and notes model dependency, providing context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, structured with a note and args/returns breakdown, every sentence adds value, and no information is redundant or missing.
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 tool with output schema (returns JSON), the description covers purpose, parameter, return, and a model caveat. It is complete enough 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists the 'enabled' parameter and its type/meaning, but the input schema already describes the same parameter. With schema description coverage stated as 0%, the description partially compensates by restating the parameter semantics, but adds no new 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?
Description clearly states the tool enables or disables the internal power amplifier, a specific action on a specific resource. It distinguishes itself from sibling tools like set_amplitude or set_frequency by focusing solely on power amp control.
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 includes a note about model dependency ('Not all MHS-5200A models have this feature'), which is helpful but does not explicitly indicate when to use this tool over alternatives or provide exclusion criteria. Usage guidance is minimal.
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?
Description explains the behavioral effect (CH2 follows CH1) and confirms return value, adding useful context beyond annotations which only hint at idempotency and non-destructiveness.
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?
Extremely concise with front-loaded purpose, clear explanation, parameter description, and return value. No wasted words.
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 toggle tool, the description covers all necessary aspects: purpose, behavior, single parameter, and return. The presence of an output schema reduces the need to explain return format.
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 already provides a clear description of the enabled parameter; the tool description merely restates it. No additional semantic value beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool enables or disables frequency tracking mode and explains that CH2 follows CH1. This distinguishes it from sibling tools which handle other device settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for controlling tracking mode, but does not explicitly guide when to enable versus disable or mention prerequisites or alternatives.
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 provide idempotentHint=true and destructiveHint=false. Description confirms safety and return format, adding slight value but not essential beyond 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?
Extremely concise: three short sentences covering purpose, safety, and return value. No unnecessary words.
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?
Fully complete for a disconnect tool: purpose, safety note, and return format are all stated. Zero parameters and output schema present, so no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, schema coverage 100%. Baseline 4 applies as description adds nothing needed for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'disconnect' and specific resource 'MHS-5200A signal generator' exactly describe the tool's action. Distinguishes from sibling tools like mhs5200_connect.
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?
Explicitly states 'Safe to call even if not connected', providing clear context for when it is appropriate to use. Does not specify when not to use, but the safety guarantee reduces ambiguity.
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 provide readOnlyHint, idempotentHint, and destructiveHint false. The description adds value by detailing the returned JSON structure, including channel and global settings, which helps the agent understand the tool's output beyond the safety profile.
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: one sentence for purpose and a bulleted list for return details. Front-loaded with main action, no wasted words.
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 no parameters and the presence of an output schema, the description fully covers the tool's behavior by listing all returned fields. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema coverage 100%), and the description explains what is returned. Baseline 4 is appropriate as it adds no ambiguity.
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 it retrieves 'complete status of all channels and device settings', specifying the scope and differentiating it from sibling tools that are all configuration-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?
While not explicit about when to use versus alternatives, the description implies it is the primary read tool for full status, and siblings are for individual settings. A small improvement would be to explicitly state it as the recommended tool for reading overall device state.
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 indicate idempotent and non-destructive behavior. Description adds that it controls sweep state and returns confirmation, consistent with annotations. No contradiction.
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?
Four concise sentences: purpose, prerequisite, parameter, return value. Front-loaded with key action.
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 start/stop tool with one parameter and clear prerequisites, the description covers all necessary information.
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 description repeats the parameter explanation already present in the input schema. Since schema coverage is high (nested object has description), baseline 3 applies; description adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts or stops a frequency sweep. It distinguishes from sibling tool mhs5200_configure_sweep by noting that configuration should happen first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use mhs5200_configure_sweep first, then this tool, providing clear sequencing and preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral context: explains formula, percentage interpretation, and return type (JSON confirmation). Annotations already hint idempotency and non-destructiveness; description reinforces without contradiction.
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?
Concise but includes necessary details like formula and examples. Well-structured with bullet points, though slightly verbose for a simple set operation.
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?
Covers purpose, parameter details, formula, range, and return value. Output schema is present but description still mentions return format, making it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite schema description coverage reported as 0%, the description extensively explains offset_percent with examples and formula, greatly adding meaning beyond the schema's basic range and default.
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?
Clearly states 'Set the DC offset for a channel.' Identifies verb (set) and resource (DC offset for a channel). Distinct from sibling tools which handle other parameters.
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?
Explicitly explains when to use (to adjust DC offset). Implicitly excludes other sibling tools by focusing on offset specific details, but lacks explicit 'when not to use' or direct comparisons.
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 provide idempotentHint=true and destructiveHint=false. The description adds the behavioral detail that an existing connection is closed first, which is not obvious from annotations alone. This adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (approximately 6 lines) and well-structured with separate sections for purpose, usage, args, and returns. Every sentence serves a purpose with no fluff.
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 low complexity (1 parameter), rich annotations, and presence of output schema (provided in description as JSON format with fields status, model, serial), the description is complete and leaves no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema itself lacks parameter descriptions. The description fully compensates by documenting the 'port' parameter with examples and context (e.g., 'COM3', '/dev/ttyUSB0'), making it meaningful for the agent.
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 'Connect to MHS-5200A signal generator via serial port.' It uses a specific verb and resource, and distinguishes from siblings (e.g., configure, disconnect) by establishing this as the prerequisite connection step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'This must be called before using any other mhs5200_* tools.' and 'If already connected, the existing connection is closed first.' This provides clear when-to-use and behavior on reconnection.
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:

[![mhs5200a-mcp MCP server](https://glama.ai/mcp/servers/NaoNaoMe/mhs5200a-mcp/badges/card.svg)](https://glama.ai/mcp/servers/NaoNaoMe/mhs5200a-mcp)

Score Badge

Copy to your README.md:

[![mhs5200a-mcp MCP server](https://glama.ai/mcp/servers/NaoNaoMe/mhs5200a-mcp/badges/score.svg)](https://glama.ai/mcp/servers/NaoNaoMe/mhs5200a-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/NaoNaoMe/mhs5200a-mcp'

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