mcp-kr-controller

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
Several tools have overlapping purposes, especially auto_discover and scan_devices which both handle device discovery and registration, and various relay control tools (all_relays_off, group_disconnect, set_relays_by_mask) that can achieve similar outcomes with different scopes. This makes it difficult for an agent to reliably choose the correct tool.
Naming Consistency2/5
Naming patterns are inconsistent: some use verb_noun (setup_connection, scan_devices), others use noun_verb (group_disconnect, all_relays_off), and several are compound or non-standard (momentary_off_on_single, ping_pong). The verb placement and naming style vary considerably.
Tool Count3/5
With 24 tools, the count falls in the heavy 16-25 range. While many tools cover distinct relay control features, some convenience wrappers (e.g., all_relays_off, group_disconnect) could likely be consolidated without losing functionality.
Completeness4/5
The tool surface covers connection management, device discovery, status reading, and a broad range of relay operations (single, group, all, mask, momentary, blink, animation, DI-trigger). Minor gaps exist, such as no dedicated device removal or connection update, but core workflows are well covered.
Average 3.9/5 across 24 of 24 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- No stable releases found
- 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must explain behavior. It attempts to detail the mask mapping but gives an incorrect interpretation: the schema says 0=保持原状 (maintain state) while the description claims 0=断开 (de-energize). This misrepresents the tool's actual behavior, potentially leading to unintended relay states. It also fails to mention the address parameter's role.
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 very brief, one sentence plus an example, and gets to the point quickly. No excessive wording. The example is helpful in principle, though inaccurate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should cover more. It explains the mask concept but omits the address parameter, the effects of broadcast (255), and any prerequisites. The contradictory bit semantics also make it incomplete for safe usage. Given the complexity of relay control and the number of siblings, a more thorough description is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so a baseline of 3 is warranted. However, the description adds incorrect semantics for the mask parameter ('1=吸合, 0=断开') that contradicts the schema's '1=操作, 0=保持原状'. The example mask=0x000F is thus misleading. The address parameter is not mentioned in the description at all.
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 '按 16 位掩码批量设置继电器状态' (batch set relay states by 16-bit mask), clearly identifying the verb and resource. However, the bit semantics described ('0=断开') contradict the schema's '0=保持原状', making the purpose somewhat misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It doesn't mention that this is for multi-relay control, nor contrasts with single-relay tools like connect_relay or all_relays_on. Lacks any 'use this when' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral details beyond the query purpose. With no annotations, it does not state whether the operation is read-only, the return format, or error conditions. The verb '查询' implies a read, but explicit disclosure is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose without extraneous content.
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 single-parameter read tool, the description covers the core purpose but omits the return format and does not clarify why the address parameter is optional. These gaps are significant in the absence 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 fully documents the address parameter, including range and discovery methods, so schema coverage is 100%. The tool description adds no additional parameter semantics, so the baseline of 3 applies.
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 queries whether specific functional modules (storage, RTC clock) exist on a specified device. It uses a specific verb ('查询') and identifies a concrete resource, but does not explicitly contrast it with sibling tools like read_status.
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 or when to prefer alternatives. It lacks any mention of prerequisites, typical scenarios, or exclusions. The schema later mentions scan_devices/list_devices, but that is not in the tool description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full responsibility for disclosing behavioral traits. It only states that the relay is set to ON, but does not explain whether the state is latched, requires a connection, or has any side effects. This is insufficient for a control tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a parameter list, front-loaded with the action. Every word earns its place, with no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but without annotations or an output schema, the description needs to provide more context. It omits prerequisites (like connection setup), the nature of the relay action (momentary vs. latching), and any indication of how this compares to alternative tools, leaving the agent under-informed.
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% coverage with detailed descriptions for both parameters (address and channel). The description merely repeats the parameter names without adding new semantic meaning, so it adds no 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 clearly states the action: energize/activate a specified single relay channel on a specified device, with the explicit '(ON)' marker. This distinguishes it from sibling tools like all_relays_on or set_relays_by_mask, which operate on multiple relays.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It simply states the action without contextualizing it against related tools such as disconnect_relay or all_relays_on.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only mentions the action (OFF) and does not disclose prerequisites like connection setup, behavior when the device is unreachable, whether broadcast address 255 is supported, or any side effects. This leaves significant behavioral ambiguity for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the action and parameter mapping. It has no redundant content and earns its place fully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having clear parameter documentation in the schema, the description lacks usage context, prerequisites, or differentiation from many closely related sibling tools. The lack of annotations and output schema further compounds the gap—an agent cannot tell when to use this tool or what to expect beyond the basic operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%—both parameters have detailed descriptions including ranges, discovery methods, and broadcast address semantics. The description merely repeats 'address=機器地址, channel=回路號' without adding any new 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 clearly states it '断開指定設備指定一路繼電器（OFF）'—disconnecting (turning off) a specific relay on a specific device. This uses a specific verb and resource, and distinguishes it from siblings like connect_relay (ON), all_relays_off (all relays), and group_disconnect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as all_relays_off or connect_relay. The description only states what it does without any contextual selection criteria, exclusions, or references to 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?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the core periodic on/off behavior without detailing whether the blink continues indefinitely, the effect of time=0 (though covered in schema), potential state overrides, or what the return value signifies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It front-loads the tool's primary purpose and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema provides strong parameter coverage, but the description lacks return-value information and usage context, such as how this differs from momentary toggles. For a simple control tool with no output schema, the description is somewhat incomplete but sufficient for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with each parameter described in detail. The tool description merely references '设定时间' without adding meaning beyond the schema, so it meets the baseline but does not exceed 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 clearly states the tool blinks a single relay channel with periodic on/off based on a set time. The term '单路' (single-channel) explicitly distinguishes it from sibling tools like blink_multi, providing a specific verb-resource pairing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as blink_multi or momentary variants. There is no mention of prerequisites, exclusions, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses the core behavior (auto-off after a time) and the bitwise selection mechanism, but it does not mention side effects, idempotency, or interaction with other groups. The schema covers some parameter-specific semantics, but the description alone is somewhat minimal.
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 effectively communicates the tool's purpose. It is front-loaded with the key action and adds necessary detail about the auto-off behavior. No extraneous 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?
The tool has 4 parameters, all well-documented in the schema, so the description doesn't need to repeat them. The description provides the essential high-level behavior, and given the absence of an output schema, it adequately explains what the tool does. It could be slightly more detailed about return values or error conditions, but overall it is sufficient for a domain-aware agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific meaning beyond the schema, though the '按位' reference aligns with the mask parameter. No additional value is provided for time or group 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: it performs a multi-channel momentary ON→OFF operation, turning on specified relays and automatically turning them off after a specified time. The phrase '按位' and '多路' distinguish it from single-channel and blink siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that this is suitable for multi-relay operations or that single-channel variants exist. Users must infer usage from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the core behavior (relay auto-disconnects after time) and gives an equivalence ('延时关闭'). However, it omits edge cases like time=0 (disabled) and broadcast address behavior, which are present in the schema but not in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with a parameter list. The first sentence front-loads the core function; the second adds an equivalence. The parameter list is redundant but not 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?
For a simple relay control tool with full schema coverage, the description adequately explains the main behavior but lacks edge-case and return-value context. Without annotations, some behavioral transparency is missing, but the tool is simple enough that the description is nearly 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?
Schema covers all parameters with descriptions (100%). The description repeats param names and provides a brief mapping (channel=回路号, time=延时时间), which adds minimal semantic reinforcement but does not exceed schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs single-channel momentary ON→OFF: the relay engages and automatically disconnects after a specified delay. This directly distinguishes it from sibling tools like momentary_off_on_single and multi-channel variants.
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 context that it is a delayed shutdown for a single channel, but does not explicitly state when to use this over alternatives or mention exclusions. It relies on the name and sibling differences for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It reveals one key behavior: '其余通道保持原状态不变' (other channels retain their original state), which is valuable. However, it does not disclose potential side effects, error conditions, or return values, and does not mention the optional address parameter's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the tool's purpose and includes a critical behavioral qualifier. 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?
For a simple 2-parameter tool with no output schema, the description plus schema provide sufficient context to use the tool. It explains the core action and the key non-effect, though it does not mention prerequisites like setting up a connection, which are handled by sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are fully documented in the schema. The description adds no extra semantic detail beyond what the schema already provides, such as the mask bit mapping or address range. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '组吸合' (group latch) and resource '继电器' (relays), and clearly states the scope: according to the mask, specified relays are latched while others remain unchanged. This distinguishes it from siblings like set_relays_by_mask which might set all relays, and group_disconnect which does the opposite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case (partial update of relay states) but does not explicitly state when to use this tool versus alternatives like set_relays_by_mask or group_toggle. No exclusions or alternative tool names 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?
No annotations are provided, so the description carries the burden. It discloses the core behavior (periodic on/off) but omits details like how to stop blinking, what happens to bits with mask=0 (though schema covers that), or whether this overrides existing configurations. Minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the tool's purpose and mode of operation without redundancy. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a control tool with no annotations, output schema, and 4 parameters, the description is adequate but lacks usage guidance, cancellation semantics, and how it interacts with other functions like group or address. The schema provides parameter details, but the description alone is somewhat sparse for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with rich descriptions for mask, time, group, and address. The description adds no additional parameter meaning beyond mentioning 'by bit' and 'multi-channel', so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'blink' multiple relay channels periodically by bit mask ('多路闪烁（按位）...周期性通断'). It implicitly distinguishes from single-channel blinking (blink_single) and momentary operations, with a clear verb+resource+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?
The description gives clear context: for periodic multi-channel toggling using a bit mask. It does not explicitly state when not to use it, but the context is sufficient to infer appropriate use relative to sibling tools like blink_single and momentary variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly explains the state transition for each channel and that non-masked channels remain unaffected. However, it does not mention return value, error behavior, or prerequisite conditions such as needing an established connection, which are minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a clear structure: operation, mask-based targeting, and the constraint that other channels remain unchanged. It is front-loaded and every part adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters, full schema coverage, and no output schema, the description covers the core behavior and parameter semantics adequately. It does not explain return values or connection requirements, but these are not critical for a straightforward toggle action and are likely covered by sibling tools or environment context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the 2 parameters (mask and address), so the baseline is 3. The description adds some meaning by connecting the mask to the toggle operation, but it does not provide additional details beyond what the schema already explains, such as the binary bit semantics or address range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('翻转' - toggle) and resource (指定继电器状态 - specified relay states), and explicitly defines the behavior: 断开→吸合, 吸合→断开, with other channels unchanged. This clearly distinguishes group_toggle from sibling tools like set_relays_by_mask or all_relays_on which set states rather than invert them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you need to flip selected relays while leaving others untouched. It does not explicitly mention alternatives or contrast with sibling tools like group_connect/group_disconnect, nor does it state when not to use it. The context is clear but no direct 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?
With no annotations, the description carries the burden and discloses the key behavior: selected relays engage for a specified time then auto-disconnect, while unselected bits remain unchanged. It does not cover edge cases like time=0 or error handling, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the main action front-loaded. It contains no filler and efficiently conveys the tool's purpose and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters and no output schema, the description combined with the schema gives adequate understanding of the operation. Minor gaps include lack of mention about return values or the meaning of time=0, but these are covered in the schema and not critical for a simple control command.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are fully described in the schema (100% coverage), so the baseline is 3. The description adds directional context (OFF→ON) and ties the mask to relay selection, but it does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a multi-channel momentary OFF→ON operation with bitwise selection, and relays automatically disconnect after a specified time. This distinguishes it from single-channel and ON→OFF variants like momentary_on_off_single and momentary_on_off_multi.
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 controlling multiple relays with a timed OFF→ON action, and the name suggests it is the multi-channel counterpart to momentary_off_on_single. However, it does not explicitly state when to use this tool over alternatives or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the polling mechanism (poll READ_STATUS), the trigger condition (no input→has input), and that it executes the action and returns a result. It also implies blocking behavior via the timeout parameter. However, it doesn't detail the exact return value format or potential side effects of executing relay actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured logically: main behavior, parameter summary, and natural language examples. It is slightly redundant with the schema (repeating parameter names and defaults), but the examples and behavioral overview earn their place. Each section is concise and the overall length is appropriate for a tool with 9 parameters.
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 provides a comprehensive overview of the tool's purpose, behavior, and parameters, along with natural language mappings. However, there is no output schema or mention of the return value structure, leaving some ambiguity about what 'returns result' means. Given the complexity and sibling tools, it's mostly complete but could benefit from a brief note on the expected response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description lists all parameters and their defaults, but the schema already provides detailed descriptions for each. The description groups start/end/count/delay as 'ping_pong action parameters', adding marginal value by clarifying their purpose, but it doesn't go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool monitors a DI channel's rising edge trigger and automatically executes a specified action, with natural language examples like 'detect input trigger' and 'run light when DI1 has signal'. This distinguishes it from sibling tools like read_status (which only reads status) and ping_pong (which executes an action without waiting for a trigger).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (monitoring a DI trigger and executing an action), supported by natural language mappings. However, it does not explicitly mention alternatives or exclusion criteria, such as 'use read_status for direct status reads' or 'use ping_pong directly without waiting'.
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 discloses '发完即走不等应答，直接读状态确认' (fire-and-forget, confirm via status read), revealing non-blocking behavior. It also mentions internal use of SET_RELAY_MASK, adding implementation context. With no annotations, this behavioral information is valuable and goes beyond a basic description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with four short sentences, each serving a distinct purpose: the core action, execution model, performance advantage, and natural language mapping. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-command tool with no annotations and no output schema, the description adequately covers purpose, behavior, and usage hints. It lacks explicit details about return values or prerequisites like an active connection, 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 already provides full documentation for the optional address parameter, including range and examples. The description doesn't add any additional parameter-specific meaning, but schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states '一键断开全部继电器' (one-click disconnect all relays), with a clear verb and resource. It distinguishes from siblings like all_relays_on and disconnect_relay by indicating a bulk all-off action.
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 notes '比逐路操作快 N 倍' (N times faster than per-channel operation), implying use this for bulk disconnection instead of individual operations. It also provides natural language triggers for when a user might ask for this. It doesn't explicitly exclude alternative scenarios like partial disconnection, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides key behavioral details: it is fire-and-forget ('发完即走不等应答'), requires reading status to confirm, and internally uses a single SET_RELAY_MASK instruction. This goes beyond the schema and helps the agent set expectations, though it omits failure/error handling 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 compact and front-loaded: purpose, execution behavior, and natural language aliases are covered in three short sentences without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description sufficiently explains the operation, execution semantics, and follow-up action (reading status). It is complete enough for correct selection and invocation, though minor details like default address or multi-device behavior are left to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the address parameter is already well-documented (range, discovery methods, broadcast address). The tool description itself adds no parameter-specific semantics, which is acceptable given the schema handles it fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('一键吸合全部继电器' / one-click pull in all relays) and the resource (all relays), distinguishing it from siblings like all_relays_off and set_relays_by_mask. Natural language mappings ('全开', 'all on') reinforce the specific intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use this tool (for turning all relays on at once), advises to fire-and-forget and confirm via status read, and highlights speed advantage over per-channel operations. It does not explicitly name alternative tools but the context makes substitution clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It clearly states that only masked relays are disconnected and all other channels remain unchanged, which is the core behavioral trait. It does not cover return values, error handling, or hardware side effects, but for a simple relay command the primary behavior is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the tool name and immediately states the action and its effect. There is no filler or redundant information; 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?
Given the tool's simplicity, the description is sufficiently complete: it states the action, the scope (mask), and the preservation behavior. The schema covers the address parameter, and the absence of an output schema lowers the need for return-value documentation. It lacks some usage guidance, but that is covered in the usage_guidelines dimension, so overall context is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter coverage with detailed descriptions for both mask and address. The description adds a high-level restatement of the mask behavior ('其余通道保持原状') but does not introduce new meaning beyond the schema. Thus, 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 ('断开' / disconnect) and resource ('继电器' / relay), and clarifies the scope via mask. It explicitly states that other channels remain unchanged, which distinguishes this tool from group_connect, group_toggle, and all_relays_off. This provides a clear and distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the primary use case: disconnecting a subset of relays while preserving the rest. This contextual guidance helps an agent choose this tool over broad actions like all_relays_off. However, it does not explicitly name alternatives or provide when-not-to-use guidance, so it stops short of full alternative differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only listing operation by saying '列出' (list), but it does not explicitly state that it is non-destructive, nor does it disclose return format, pagination, or prerequisites. For a simple list tool this is adequate but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and scope. There is no redundant or filler text; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description covers the main purpose and a practical use case. However, since there is no output schema, it does not describe the exact return structure beyond 'connections and status,' and it omits edge cases like empty results. Still, it is largely complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds meaningful context about what the output will contain (connections and their status), which is sufficient given there are no parameters to document.
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 clear action verb '列出' (list) with specific scope: '当前所有通讯连接及其状态' (all current communication connections and their status). This distinguishes it from sibling tools like setup_connection, remove_connection, and list_devices by focusing on connections and their status rather than setup, removal, or device listing.
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 a concrete use case: '用于确认已添加的连接' (used to confirm added connections), which gives context for when to call this tool. However, it does not explicitly mention when not to use it or compare it with alternatives like list_devices, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is a read-only listing operation and details the output fields, which is useful. However, it does not explicitly state safety (e.g., no side effects) or any limitations, such as whether it reflects real-time connection status.
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 and front-loaded: it opens with the primary action, then lists the output details, and ends with a practical usage note. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description is complete enough: it covers what it does, what information is returned, and when to use it. It could explicitly mention that it is a safe read-only operation, but given the low complexity, the current description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema fully covers this (empty schema, 100% coverage). The baseline for 0 params is 4, and the description adds nothing needed beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all registered devices and specifies the exact information it returns (address, IO channel counts, function modules, connection type). This distinguishes it from siblings like list_connections (connections vs devices) and scan_devices (discovery vs registered).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: before controlling devices to confirm device address and available loop count. However, it does not explicitly mention when not to use it or compare against discovery tools like auto_discover/scan_devices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It clearly states this is a read operation that returns 16 input and 16 relay states, and implies non-destructiveness through the verb 'read' and the context of viewing status changes. It doesn't explicitly state read-only behavior, but the intent is unambiguous.
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: the first states the core function, the second adds a practical usage note. No redundant or irrelevant content, and it is front-loaded with the main purpose.
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 tool with one parameter and no output schema, the description adequately explains the return content (16 inputs and 16 relays, on/off states) and provides a usage scenario. It doesn't describe the exact output structure, but that is not required given the simplicity and lack of 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 schema covers 100% of the parameter's semantics (address range, discovery methods, broadcast address). The description adds no additional parameter meaning beyond simply referencing '指定设备' (specified device), so it meets the baseline without adding 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 uses a specific verb '读取' (read) and clearly identifies the resource: all inputs and relay current status of the specified device. It further specifies the scope (16 inputs + 16 relays), distinguishing it from sibling control and discovery tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating it reads current status and suggests using it after control operations to view state changes. It doesn't explicitly mention alternatives or exclusions, but the use case is clear and relevant given the sibling list of control tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly reveals the destructive side effect of removing all associated devices, which is important beyond the basic 'remove' action. It does not, however, mention irreversibility or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences. The first states the core action, the second adds a critical side effect. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool with one parameter and no output schema, the description adequately explains what it does and the key side effect. It could mention the return value or error cases, but the core context is sufficiently covered.
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 a clear description for the 'id' parameter (including how to find it via list_connections), covering 100% of the parameters. The tool description itself does not add further parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: '移除一个通讯连接' (remove a communication connection) and adds a specific side effect: '同时会移除该连接上注册的所有设备' (also removes all devices registered on that connection). This distinguishes it from sibling tools like 'disconnect_relay' or 'list_connections'.
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 use by stating the main action and the cascading side effect, which implicitly warns the agent not to use this tool if devices should be preserved. However, it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states that the tool automatically connects after adding ('添加后自动连接') and that it can be used for subsequent device scanning, providing useful behavioral context beyond the basic 'add' operation. It doesn't contradict any annotations since none exist.
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 concise sentences, front-loaded with the core purpose. Each sentence adds distinct value: the action, the trigger and types with required params, and the post-add behavior. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, the description covers the essential usage flow, including when to call it, what each type requires, and the automatic connection behavior. It mentions its relationship to device scanning, which aligns with sibling tools. While it doesn't specify return values or error handling, these are not strictly required for a setup action, and the schema covers parameter specifics.
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% coverage of parameter descriptions, so the baseline is 3. The description adds per-type parameter grouping and concrete examples (COM3, 192.168.1.100, 8080), which aids understanding, but this is largely redundant with the schema's existing '仅 type=... 时需要' notes. It doesn't add major new meaning 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 opens with '添加通讯连接' (add a communication connection), clearly stating the specific verb and resource. It enumerates three supported types (serial, tcp, udp) and distinguishes itself from siblings like remove_connection and list_connections by focusing on the addition operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the trigger condition: '用户通过对话告知通讯方式后调用此工具' (call this tool after the user tells you the communication method). It also notes the tool's role in enabling subsequent device scanning, which clarifies when to use it in the workflow. However, it doesn't explicitly mention when not to use it or name alternatives, so it's not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It explicitly states the state transition: starting from a disconnected relay, closing it for the specified time, then automatically opening and restoring. This accurately describes the tool's side effects on the relay state. It does not mention peripheral concerns like prerequisites (e.g., connection) or return values, but the core behavior is transparent and predictable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: a single compound sentence that front-loads the core function, then adds a behavior explanation, a relatable analogy, and a brief parameter list. Every element serves a purpose without redundancy or fluff. It is appropriately sized for a simple control tool.
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 simple nature, the rich parameter schema, and the absence of an output schema, the description is comprehensively complete. It explains what the tool does, how it behaves, and what each parameter represents. The only lack is explicit coverage of unit or zero-value behavior, but these are already documented in the schema, so the description does not need to repeat them.
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 each parameter having a description that explains its meaning, range, and special values (e.g., time=0 disables). The tool description adds minimal value beyond the schema by merely re-listing parameter names and clarifying 'channel=回路号'. Since the schema already provides full semantics, 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 opens with '单路点动 OFF→ON' (single-channel momentary OFF→ON), which clearly states the verb (point/trigger), resource (relay channel), and direction (OFF→ON), distinguishing it from siblings like momentary_on_off_single and multi-channel variants. It further explains the exact behavior: the disconnected relay closes for a specified time then automatically opens and restores, with the analogy of a button press, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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: it is for generating a momentary pulse on a relay, equivalent to pressing and releasing a button. It does not explicitly name alternatives or when not to use it, but the behavior and direction (OFF→ON) strongly imply the distinction from the ON→OFF variant, giving clear situational context without formal exclusions.
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?
No annotations are provided, but the description discloses internal behavior in detail: continuous fire-and-forget SET_RELAY_MASK commands, automatic disconnection at start/end, compatibility with TCP transparent devices (V4/V5), and a final status read to confirm the endpoint. This is strong behavioral transparency beyond what schema or annotations would provide.
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 compact yet dense; every sentence adds value: behavior, internal mechanics, compatibility, parameters, and natural language mapping. It is well-structured and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, mechanism, parameter defaults, and usage triggers, which is substantial for a tool without an output schema. However, it does not explicitly state what the tool returns, leaving some ambiguity about the result of the call. Minor gap but overall quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with rich per-parameter documentation including constraints (e.g., end cannot be less than start) and examples. The description's parameter list mostly restates names/defaults without adding new semantic information, 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 explicitly states it performs a single-light ping-pong bounce animation between start and end circuits, providing a specific verb and resource. It also lists natural language aliases ('跑马灯、ping-pong、来回弹跳、弹弹球'), which clearly distinguishes it from siblings like blink_multi or momentary 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 maps natural language phrases to the tool, giving clear trigger conditions for when to use it. However, it does not explicitly state when not to use it or mention alternatives, so guidance is partial but useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It does so by outlining a three-step execution flow: broadcast discovery, query IO channels and modules, then register and persist. It also discloses the side effect of persistence and that it enables subsequent control. It could mention re-run behavior or error handling, but the core behavior is well explained.
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 and well-structured. It leads with the primary action, then uses a numbered list to explain the execution flow. Every sentence earns its place, and the prerequisite note is essential. No redundant language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description is quite complete. It explains what happens step-by-step and why it's necessary. It doesn't specify outcomes if no devices found, but that's a minor gap. Overall, it provides sufficient context for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema has no properties, so schema coverage is effectively 100%. Per the rubric, 0 params yields a baseline of 4. The description doesn't need to add parameter details, and it doesn't, so it's adequate.
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: '扫描所有连接上的在线设备并自动注册' (scan all connected online devices and automatically register). It specifies the action (scan), resource (connected devices), and outcome (registration). It also distinguishes itself by noting it's a prerequisite: '首次使用时必须先调用此工具'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: it must be called first before use, and after scanning, devices are controllable via address + loop number. It doesn't explicitly name alternatives like auto_discover, but the prerequisite instruction provides strong guidance on when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It discloses the exact network addresses (192.168.16.254:8080 and 192.168.1.255:8080), the multi-NIC matching behavior, the step-by-step process (connect → broadcast search → query IO/modules → register device), and the failure handling. This goes well beyond a basic statement of function and gives the agent a clear model of side effects and edge cases.
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 paragraph but well-organized: it starts with the purpose and prerequisite, then details each connection type, then the flow, then the fallback. Every sentence carries substantive information, though it could be improved with bullet points for scanability. It is not overlong for the complexity covered.
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 complexity (network/serial discovery, multi-step process) and the absence of an output schema, the description covers all major behavioral aspects: the prerequisite question, serial/network variants, exact addresses, the automated sequence, and failure escalation. It does not explicitly state the return value or success result, but the outcome (device registration) is implicit, leaving only minor 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?
Schema coverage is 100% with descriptions for all parameters, so the baseline is 3. The description adds significant value by providing concrete values for connection_type behavior (e.g., the actual IP/port and the default baud rate of 9600) and clarifying that path is required only for serial, enhancing the schema's abstract descriptions without being redundant.
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 "设备搜索与添加" (device search and add), specifying both the action (search and add) and the resource (devices). It also distinguishes itself from sibling tools by outlining the auto-discovery workflow and explicitly referencing setup_connection for manual fallback, making it unmistakable when this tool is the right choice.
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?
Provides explicit trigger conditions: when the user says "搜索设备" the AI must first ask the connection method and then call this tool. It also details the behavior for both network and serial modes, and instructs that if default addresses fail, the user should confirm the actual address and use setup_connection manually, thereby covering when-to-use and alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![mcp-kr-controller MCP server](https://glama.ai/mcp/servers/kinbeg/mcp-kr-controller/badges/card.svg)](https://glama.ai/mcp/servers/kinbeg/mcp-kr-controller)

Score Badge

Copy to your README.md:

[![mcp-kr-controller MCP server](https://glama.ai/mcp/servers/kinbeg/mcp-kr-controller/badges/score.svg)](https://glama.ai/mcp/servers/kinbeg/mcp-kr-controller)

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/kinbeg/mcp-kr-controller'

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