CNCjs MCP Server
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity, as each targets a specific action or resource in the CNCjs/GRBL ecosystem (e.g., connect_to_port vs. disconnect_port, get_machine_position vs. get_machine_settings). The descriptions explicitly differentiate tools, even for related functions like emergency_stop and feed_hold, ensuring agents can reliably select the correct tool.
Naming Consistency5/5Tool names follow a highly consistent verb_noun pattern throughout, using snake_case uniformly (e.g., get_connection_status, load_gcode, set_feed_override). This predictability makes the tool set easy to navigate and understand, with no deviations in naming conventions across all 30 tools.
Tool Count4/5With 30 tools, the count is slightly high but reasonable for the comprehensive scope of CNC machine control, covering connection management, machine state monitoring, G-code handling, job control, and safety operations. Each tool appears to earn its place, though some consolidation might be possible without losing functionality.
Completeness5/5The tool set provides complete CRUD/lifecycle coverage for CNC machine operations, including connection setup, file loading, job execution (start, pause, resume, stop), machine control (jog, home, overrides), state monitoring, and emergency handling. No obvious gaps exist, as all core workflows from initialization to shutdown are supported.
Average 3.4/5 across 27 of 30 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto 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?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose critical behavioral traits such as whether this establishes a persistent connection, what permissions or hardware access is required, potential side effects, error conditions, or what happens if the connection fails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded with the core purpose, earning its place without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that establishes a connection (a potentially complex operation with hardware implications), the description is inadequate. With no annotations and no output schema, it fails to explain what the tool returns, error handling, connection persistence, or how this fits into the broader workflow with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds no additional meaning about parameters beyond what's in the schema, meeting the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open a serial connection') and the target ('to a CNC controller'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'list_serial_ports' or 'get_connection_status', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an available port), when-not-to-use scenarios, or relationships with sibling tools like 'disconnect_port' or 'get_connection_status'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states what the tool does, without mentioning if it's read-only, requires authentication, has rate limits, or what the output format might be. This leaves key behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded and efficiently conveys the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of machine control tools and lack of annotations or output schema, the description is incomplete. It does not explain what WCO values represent, how they are returned, or any dependencies, making it insufficient for an agent to use the tool effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate, but it could have clarified if any implicit parameters (e.g., machine identifier) are involved, though not required for this score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get work coordinate offset (WCO) values' states the action (get) and resource (WCO values), making the purpose clear. However, it does not differentiate from siblings like 'get_machine_position' or 'get_machine_settings', which could also involve coordinate-related data, leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. For example, it does not specify if this is for real-time monitoring, setup, or debugging, nor does it mention prerequisites like needing a connected machine or specific machine state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'load' and 'execution', implying a write operation that may start or queue a job, but doesn't clarify if this requires specific machine states, permissions, or has side effects like overwriting existing content. For a tool with potential safety implications in CNC operations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of CNC operations and lack of annotations or output schema, the description is incomplete. It doesn't address critical context like error handling, machine state requirements, or what happens after loading (e.g., does execution start automatically?). For a tool in a safety-sensitive domain, this leaves too much undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters ('name' and 'content'). The description adds no additional meaning beyond the schema, such as format details for G-code or naming conventions. Baseline 3 is appropriate since the schema adequately documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Load') and target ('G-code content into CNCjs for execution'), which is specific and unambiguous. However, it doesn't distinguish this tool from sibling tools like 'send_gcode' or 'start_job', which might have overlapping or related functionality in the CNCjs context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'send_gcode' or 'start_job'. It lacks context about prerequisites (e.g., whether a connection must be established first) or typical workflows, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Adjust') but doesn't clarify whether this is a real-time command, requires specific permissions, has side effects (e.g., affecting ongoing jobs), or what happens on success/failure. For a machine control tool, this is a significant gap in safety and operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any redundant words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of machine control (with siblings indicating operations like emergency_stop, jog, etc.), no annotations, and no output schema, the description is incomplete. It fails to address critical aspects like error conditions, real-time implications, or integration with other tools (e.g., should feed_hold be used first?), leaving the agent with insufficient context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'value' fully documented in the schema as a percentage with min/max bounds. The description adds no additional semantic context beyond what the schema provides, such as units clarification or typical usage values, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Adjust') and resource ('feed rate override') with a specific range (10-200%), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'set_spindle_override', which has a similar naming pattern and likely adjusts a different machine parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or in what context it should be applied. The description lacks any mention of prerequisites, such as machine connection status or operational state, which are critical for CNC/machine control 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 provided, the description carries the full burden of behavioral disclosure. It implies a mutation ('Adjust') but doesn't specify if this requires specific permissions, whether changes are immediate or reversible, or what happens if the machine is offline. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single, front-loaded sentence that directly states the tool's function without unnecessary words. Every part of the sentence earns its place by specifying the action, resource, and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like safety, side effects, or response format, leaving significant gaps for the agent to operate effectively in a machine control context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal value beyond the input schema, which already fully documents the 'value' parameter with its range and description. The description restates the range (10-200%) but doesn't provide additional context like units or effects, resulting in a baseline score due to high schema coverage (100%).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Adjust') and resource ('spindle speed override') with a specific range (10-200%), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'set_feed_override', which serves a similar function for feed rate rather than spindle speed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites (e.g., machine must be connected or in a certain state) or comparisons to siblings like 'set_feed_override', leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a destructive action (stopping a job) but doesn't clarify effects like whether the job can be resumed, if machine state is preserved, or what happens to the current position. The input schema hints at 'graceful' vs. 'force' behavior, but the description doesn't elaborate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It's front-loaded and efficiently communicates the core action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that performs a potentially destructive action (stopping a job) with no annotations and no output schema, the description is insufficient. It lacks details on behavioral consequences, error conditions, or what constitutes a 'current job', leaving significant gaps for an AI agent to operate safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the 'force' parameter. The description adds no parameter-specific information beyond what's in the schema, resulting in the baseline score of 3 for adequate but no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Stop the current job' clearly states the action (stop) and resource (current job), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'pause_job' or 'emergency_stop', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'pause_job', 'resume_job', or 'emergency_stop'. There's no mention of prerequisites (e.g., requires a job to be running) or context for choosing between graceful vs. forced stops.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves information ('Get'), implying it's a read-only operation, but doesn't disclose behavioral traits such as whether it requires machine connection, has latency, or returns structured data. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the alarm code format is, how the human-readable meaning is structured, or any error conditions. For a tool in a machine control context, this leaves critical gaps in understanding its behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, earning a baseline score of 4 as it doesn't need to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and the resource ('current alarm code and human-readable meaning'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_machine_state' or 'get_connection_status', which might also provide status information, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., during machine errors), or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action but doesn't disclose behavioral traits like whether it's a read-only operation, if it requires an active connection, potential errors, or response format. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently conveys the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the connection status entails (e.g., connected/disconnected, details), potential return values, or how it fits into the broader context of CNCjs operations, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for this scenario is 4, as the description doesn't need to compensate for any parameter gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'current CNCjs connection status', making the purpose specific and understandable. However, it doesn't explicitly differentiate from siblings like 'get_machine_state' or 'get_workflow_state', which might also provide status information, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as whether it should be used before other operations or in response to specific events, leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'travel limits' but does not clarify what that entails (e.g., units, format, or if it's a filter). It lacks details on permissions, rate limits, or response behavior, leaving significant gaps for a tool in a machine control context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded and directly states the tool's function, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of machine control tools and lack of annotations or output schema, the description is insufficient. It does not explain the return format, what 'travel limits' entails, or how this tool fits among siblings, leaving the agent with incomplete information for proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by specifying 'with travel limits', which provides context about the output, though it does not fully explain what 'travel limits' means.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('machine profiles'), making the purpose evident. However, it does not differentiate from sibling tools like 'get_machine_state' or 'get_machine_settings', which also retrieve machine information, leaving some ambiguity about when to use this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. With siblings like 'get_machine_state' or 'get_machine_settings' that also fetch machine data, there is no indication of context, prerequisites, or exclusions for using 'list_machines'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of behavioral disclosure. 'Resume' implies a state-changing operation, but the description doesn't disclose permissions needed, whether it's reversible, what happens if no job is paused, or any rate limits. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'resume' entails operationally, what the expected outcome is, or any error conditions. Given the complexity implied by sibling tools in a machine control context, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of parameters. The description doesn't need to add parameter information, and the baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Resume') and target resource ('a paused job'), providing specific verb+resource pairing. However, it doesn't explicitly differentiate from sibling tools like 'start_job' or 'pause_job', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'start_job' or 'pause_job'. It mentions 'paused job' which implies a prerequisite state but doesn't explicitly state when-not-to-use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what data is retrieved but omits critical details like whether this is a real-time snapshot or cached data, potential latency, error conditions, or if it requires specific machine states. This leaves significant gaps for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information ('Get feeder queue depth, hold state, and reason') with zero wasted words. It directly communicates the tool's function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with 0 parameters and no output schema, the description is minimally adequate but incomplete. It specifies the data retrieved but lacks context on format, units, or behavioral traits, which could hinder an agent's ability to interpret results correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately focuses on the output semantics, listing the data retrieved without redundant parameter details, meeting the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the specific data retrieved ('feeder queue depth, hold state, and reason'), making the purpose immediately understandable. It doesn't explicitly distinguish from siblings like 'get_connection_status' or 'get_machine_state', but the focus on feeder status is specific enough to imply differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Given siblings like 'get_machine_state' or 'get_workflow_state', the description lacks explicit context for choosing this tool, such as monitoring material handling or diagnosing feed issues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but lacks details on permissions, rate limits, or response format. For a read operation in a machine control context, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any wasted words. It is front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema) and lack of annotations, the description is minimally adequate but incomplete. It doesn't explain the return format or any behavioral nuances, which could be important in a machine control environment, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter information is needed. The description doesn't add param details, which is appropriate, earning a baseline high score as it doesn't mislead or omit necessary info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('currently loaded G-code file name and content'), making the purpose evident. However, it doesn't explicitly differentiate from siblings like 'get_job_progress' or 'load_gcode', which might also relate to G-code operations, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. For example, it doesn't specify if this should be used to check file status during a job or as a general query, leaving the agent to infer usage from context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but lacks details on permissions, rate limits, whether it requires an active machine connection, or what happens if the machine is offline. For a read operation in a machine control context, this omission is significant, though the action ('Get') implies it's likely non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource. Every word earns its place: 'Get' specifies the action, 'current machine and work positions' defines the scope, and '(X, Y, Z)' adds precision without redundancy. There's no wasted text, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema), the description is minimally adequate. It explains the purpose and output data but lacks context on usage, behavioral traits, or integration with siblings. For a tool in a machine control server with many siblings, more guidance would be helpful, but the simplicity of the operation keeps it from being incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's output semantics (positions in X, Y, Z). This adds value beyond the schema by clarifying what data is returned, though it doesn't detail the return format (e.g., units, coordinate system).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('current machine and work positions'), including the coordinate dimensions (X, Y, Z). It distinguishes itself from siblings like 'get_machine_state' or 'get_work_coordinate_offset' by focusing specifically on positional data rather than general state or offset values. However, it doesn't explicitly contrast with all similar siblings, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active connection), exclusions, or comparisons to siblings like 'get_machine_state' (which might include position) or 'get_work_coordinate_offset' (which relates to work coordinates). Without such context, users must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'gets' settings, implying a read-only operation, but doesn't clarify if this requires an active connection, has side effects, or details the return format (e.g., structured data vs. raw output). For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get all GRBL $$ machine settings with labels') with zero wasted words. Every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no output schema, and no annotations, the description is minimally adequate. It specifies the resource (GRBL settings with labels), but lacks details on behavioral context (e.g., connection requirements) and output format. For a read operation in a complex server with many siblings, more completeness would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by specifying 'GRBL $$ machine settings with labels', which provides context on what is retrieved beyond the schema. This compensates adequately, though it doesn't fully explain output semantics, keeping it from a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'all GRBL $$ machine settings with labels', which specifies what the tool retrieves. It distinguishes itself from siblings like get_machine_state or get_parser_state by focusing on settings rather than status or state. However, it doesn't explicitly differentiate from all siblings (e.g., get_alarm_info might also retrieve settings-related info), keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a connection via connect_to_port), exclusions, or compare it to similar tools like get_machine_state. Without such context, the agent must infer usage from the tool name and siblings alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a read operation ('Get'), implying no destructive effects, but doesn't disclose behavioral traits like whether it requires an active connection, has rate limits, returns real-time vs. cached data, or error conditions. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes clarifying examples. Every word earns its place, with no redundancy or wasted text, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters and no output schema, the description is minimally adequate but lacks completeness. It specifies what data is retrieved but not the format, scope (e.g., current machine only), or dependencies. For a read-only tool with no annotations, it should ideally mention connection requirements or return structure to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, with 100% schema description coverage (empty schema). The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. Baseline for 0 parameters is 4, as it avoids unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('active G-code parser state'), with specific examples of what that includes ('WCS, units, distance mode, etc.'). It distinguishes from siblings like get_machine_state or get_workflow_state by focusing on parser-specific data, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., connection status), timing (e.g., during job execution), or contrast with siblings like get_machine_settings or get_loaded_gcode that might overlap. The description implies usage when parser state is needed, but offers no explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a read operation ('Get'), but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, returns real-time or cached data, or error conditions. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes helpful detail about return values. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is adequate but incomplete. It explains what the tool returns but lacks context about when it's useful versus siblings, behavioral constraints, or error handling. For a read-only tool with no annotations, more guidance would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'workflow state', specifying the possible return values (idle, running, paused). It distinguishes from siblings like get_machine_state or get_parser_state by focusing on workflow rather than machine or parser status. However, it doesn't explicitly contrast with these siblings in the text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing considerations, or compare with sibling tools like get_machine_state or get_job_progress, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool returns (name, id, content). It doesn't disclose behavioral traits such as whether this requires an active connection, potential rate limits, error conditions, or the format/structure of the returned list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and includes specific details about what information is returned, making it appropriately sized for this simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and no output schema, the description covers the basic purpose but lacks important context about behavioral aspects (connection requirements, return format). It's minimally adequate but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, which is correct for this case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('CNCjs macros') with specific attributes (name, id, content). It distinguishes from most siblings by focusing on macros rather than machine operations, though it doesn't explicitly differentiate from 'run_macro' which is a related but different operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. While the tool's purpose is clear, there's no mention of prerequisites (e.g., connection status), timing considerations, or comparison to other tools like 'run_macro' for executing macros.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'List available serial ports' implies a read-only operation, but doesn't disclose whether this requires specific permissions, whether it returns dynamic/static data, what format the list takes, or if there are rate limits. For a tool with zero annotation coverage, this minimal description leaves significant behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple listing tool. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is minimally adequate but could be more complete. It doesn't explain what 'available' means (connected? detected?), what information is returned about each port, or how this relates to the broader machine control context. For a tool in a complex CNC/machine control server, more contextual guidance would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the absence of parameters. The description doesn't need to add parameter information. A baseline of 4 is appropriate for zero-parameter tools where the schema already provides complete coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and target resource ('available serial ports'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'list_machines' or 'connect_to_port', but the specificity of 'serial ports' provides inherent distinction. This is clear but lacks explicit sibling comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like whether a connection must be established first), whether this is for discovery before connection, or how it relates to 'list_machines' or 'connect_to_port'. The agent must infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action but doesn't disclose behavioral traits such as whether this requires the machine to be in a specific state (e.g., homed, unlocked), what happens if no G-code is loaded, if it's idempotent, or what the execution entails (e.g., immediate start, queuing). This is a significant gap for a tool that likely controls physical machinery.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero waste—'Start executing the loaded G-code program'—front-loading the core action. Every word earns its place, making it highly efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (likely controlling CNC/machinery), lack of annotations, and no output schema, the description is incomplete. It doesn't cover what the tool returns, error conditions, safety considerations, or dependencies on other tools (e.g., needing 'load_gcode' first). For a tool in this domain, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, which is correct given the schema completeness. A baseline of 4 is applied since it avoids unnecessary repetition and focuses on the tool's action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start executing') and the target resource ('the loaded G-code program'), making the purpose immediately understandable. It distinguishes from siblings like 'load_gcode' (which loads but doesn't execute) and 'stop_job'/'pause_job' (which control execution differently). However, it doesn't specify what type of job or machine context, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'loaded G-code program', suggesting this tool should be used after loading G-code, but it doesn't explicitly state when to use it versus alternatives like 'run_macro' or 'send_gcode'. No explicit exclusions or prerequisites are mentioned, leaving some ambiguity about proper sequencing with tools like 'get_loaded_gcode' or 'get_machine_state'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes what information is returned but doesn't disclose behavioral traits such as whether it's read-only (implied but not stated), error conditions (e.g., if no job is running), or performance characteristics (e.g., real-time updates). This leaves significant gaps for a tool in a machine control context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get current job progress') and lists specific metrics without any wasted words. It's appropriately sized for a simple query tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool returns but lacks details on behavioral context (e.g., error handling, real-time nature) that would be helpful in a machine control environment. It meets basic needs but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose. A baseline of 4 is applied as it efficiently handles the lack of parameters without unnecessary detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get') and resources ('current job progress'), and lists the metrics returned (lines sent, elapsed time, % complete). It distinguishes itself from siblings like 'get_machine_state' or 'get_workflow_state' by focusing on job-specific progress metrics, though it doesn't explicitly name these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage during an active job to monitor progress, but doesn't explicitly state when to use it versus alternatives like 'get_workflow_state' or prerequisites (e.g., requires a running job). It provides some context but lacks explicit guidance on exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively adds critical context: 'HIGH RISK — causes physical motion' clearly warns of safety implications and physical consequences, which is essential for a tool that moves machinery. However, it doesn't detail potential side effects (e.g., collision risks, machine state changes) or operational constraints like rate limits or prerequisites (e.g., machine must be unlocked).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: two sentences with zero waste. The first sentence states the core action, and the second provides critical risk context. Every word earns its place, making it easy for an agent to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-risk tool with 3 parameters, no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and risk warning but lacks details on usage context, error handling, or expected outcomes. Given the complexity (physical motion tool), it should ideally include more about safety prerequisites or machine state requirements to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (axis, distance, feedrate) with descriptions and constraints. The description adds no parameter-specific information beyond implying motion occurs. Baseline 3 is appropriate since the schema does the heavy lifting, though the description could have clarified parameter interactions (e.g., how distance and feedrate combine).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Jog the machine incrementally' specifies the verb (jog) and resource (machine) with the action (incremental motion). It distinguishes from siblings like 'home_machine' or 'send_gcode' by focusing on manual movement control. However, it doesn't explicitly differentiate from 'set_feed_override' which affects motion parameters but doesn't directly cause movement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'HIGH RISK — causes physical motion' which implies caution but doesn't specify scenarios where jogging is appropriate (e.g., manual positioning vs. automated moves) or when to use other motion-related tools like 'home_machine' or 'send_gcode'. No explicit alternatives or exclusions 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the action as 'controlled deceleration to stop' and characterizes it as 'safer than emergency stop', which provides useful behavioral context. However, it doesn't mention potential side effects, whether it requires the machine to be in a specific state, or what happens after the deceleration completes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that both earn their place. The first sentence explains what the tool does, and the second provides crucial comparative context with emergency_stop. There's zero wasted language or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no annotations and no output schema, the description provides adequate context about what the tool does and when to use it. However, it doesn't explain what happens after the deceleration (does it pause the job? maintain position?) or whether there are any prerequisites (must be in a running state?). Given the complexity of machine control tools, more behavioral detail would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description doesn't need to explain any parameters, and it appropriately focuses on the tool's purpose and usage context without attempting to describe non-existent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'controlled deceleration to stop', which is a specific verb+resource combination. It distinguishes itself from 'emergency_stop' by mentioning it's safer for non-critical situations, though it doesn't explicitly differentiate from other stopping-related siblings like 'stop_job' or 'pause_job'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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 ('for non-critical situations') and explicitly contrasts it with 'emergency_stop' as a safer alternative. However, it doesn't mention when NOT to use it or how it relates to other stopping mechanisms like 'stop_job' or 'pause_job'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While 'Close' implies a safe termination, it doesn't disclose whether this requires specific permissions, what happens to ongoing operations (e.g., jobs), if the closure is reversible, or any side effects. For a connection management tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it immediately understandable without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema) and lack of annotations, the description is adequate for basic understanding. However, it doesn't address behavioral aspects like error conditions or effects on machine state, which could be important for safe operation in this CNC/machine control context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to compensate, and it appropriately doesn't mention parameters. Baseline 4 is correct for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Close') and resource ('current serial connection'), using precise terminology. It distinguishes this tool from siblings like 'connect_to_port' (which establishes connections) and 'get_connection_status' (which checks status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'current serial connection', suggesting it should be used when a connection is active. However, it doesn't explicitly state when NOT to use it (e.g., if no connection exists) or name alternatives like 'emergency_stop' for different termination scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what data is retrieved, not behavioral aspects. It doesn't mention if this requires an active connection, has side effects, rate limits, or error conditions. For a tool with no annotation coverage, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get full GRBL machine state') followed by specifics in parentheses. Every word earns its place with no redundancy or wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (retrieving multiple machine state components) and lack of annotations/output schema, the description is adequate but incomplete. It specifies what data is included but doesn't cover behavioral context or return format, leaving gaps for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. Baseline for 0 params is 4, as no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get') and resource ('full GRBL machine state') with detailed enumeration of what's included (positions, feed, spindle, overrides, buffer). It distinguishes from siblings like get_machine_position (only positions) and get_machine_settings (settings only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'full GRBL machine state' and listing components, suggesting it's comprehensive. However, it doesn't explicitly state when to use this vs. more specific siblings (e.g., get_machine_position for just positions) or alternatives like get_workflow_state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Pause') and technical effects ('feed hold + pause sender'), but does not describe what happens after pausing (e.g., whether the job can be resumed, if machine state is preserved, or any side effects like spindle stopping). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Pause the current job') and adds clarifying technical detail ('feed hold + pause sender') without redundancy. Every word earns its place, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with no annotations or output schema), the description is minimally adequate. It explains what the tool does but lacks details on behavioral outcomes, error conditions, or interaction with sibling tools like 'resume_job'. Without annotations or output schema, more context would be helpful, but it meets the basic threshold for understanding the tool's primary function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not mention any parameters, which is appropriate. It earns a baseline score of 4 because it avoids unnecessary parameter details while clearly describing the tool's action without relying on parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Pause') and target resource ('the current job'), with additional technical detail ('feed hold + pause sender') that distinguishes it from sibling tools like 'feed_hold' (which might only pause motion) or 'stop_job' (which might terminate the job). This precise verb+resource combination makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'the current job', suggesting it should be used when a job is actively running. However, it does not explicitly state when to use this tool versus alternatives like 'feed_hold' or 'stop_job', nor does it mention prerequisites (e.g., job must be running) or exclusions. The context is clear but lacks explicit comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the prerequisite (homing switches enabled) and implies a machine control action, but lacks details on safety, permissions, or response behavior, leaving gaps for a tool with potential operational impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and prerequisite in two concise sentences, with zero wasted words, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is minimal but covers the basic purpose and prerequisite. However, for a tool that likely involves machine movement and safety considerations, it lacks details on behavioral outcomes or error handling, making it only adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage, the baseline is 4. The description adds no parameter details, which is acceptable as there are no parameters to document, maintaining clarity without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Run GRBL homing cycle ($H)') and the resource ('Machine'), distinguishing it from siblings like 'unlock_machine' or 'jog' by focusing on homing functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use ('Machine must have homing switches enabled'), but does not explicitly mention when not to use or name alternatives among siblings like 'unlock_machine' for similar operations.
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 effectively adds critical context: 'HIGH RISK — macro content may cause motion' warns of potential physical hazards and mutation effects, which is essential for a tool that could trigger machine movement. However, it doesn't detail other aspects like permissions or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and risk warning in just two sentences, with zero waste. Every sentence earns its place by providing essential information concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (high-risk execution tool), no annotations, and no output schema, the description is mostly complete. It covers purpose and critical safety warnings but lacks details on return values or error handling. It compensates well for the lack of structured data but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'identifier' documented as 'Macro name or ID to execute'. The description adds no additional meaning beyond this, as it doesn't specify format examples or constraints. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Execute a CNCjs macro') and resource ('by name or ID'), distinguishing it from siblings like 'list_macros' (which lists macros) and 'send_gcode' (which sends raw commands). It avoids tautology by not just restating the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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 (to execute a macro) but does not explicitly state when not to use it or name alternatives. For example, it doesn't compare to 'send_gcode' for direct commands or 'list_macros' for inspection, though the purpose implies differentiation.
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 and does well by disclosing critical behavioral traits: it's a high-risk operation that causes physical motion. This warns about safety implications and potential damage. It doesn't cover other aspects like error handling or response format, but the risk disclosure is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first states the core functionality, and the second provides crucial risk context. It's front-loaded with the main purpose and appropriately sized for a single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-risk tool with no annotations and no output schema, the description is mostly complete: it covers purpose, risk, and parameter intent. It could improve by mentioning response expectations or connection requirements, but the risk warning addresses the most critical gap given the physical nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the 'gcode' parameter's type and format. The description adds value by explaining the purpose ('to send') and reinforcing it can be one or more lines, matching the schema's anyOf structure. No extra syntax details are needed, so it exceeds the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send') and resource ('G-code lines to the machine'), specifying it can handle one or multiple lines. It distinguishes from siblings like 'load_gcode' (which loads but doesn't send) and 'run_macro' (which runs predefined sequences).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with 'HIGH RISK — causes physical motion', indicating when to use it (for direct machine control) and implicitly when not to (e.g., for non-motion commands). However, it doesn't explicitly name alternatives like 'jog' for manual movement or specify prerequisites like needing an active connection.
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 discloses that this is a write operation ('Clear') and mentions a prerequisite (alarm resolution), but doesn't detail side effects (e.g., whether it resets other machine states), error conditions, or response behavior. For a mutation tool with zero annotation coverage, this is a moderate gap, though the description is technically accurate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste: the first states the purpose, the second provides usage guidance. It's front-loaded with the core action and efficiently conveys essential information without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description is reasonably complete for its complexity—it explains what the tool does and when to use it. However, it lacks details on behavioral aspects like what happens on failure or the return format, which would be helpful for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, but it implicitly confirms no parameters are needed by not mentioning any. This meets the baseline for 0 parameters, though it doesn't explicitly state 'no parameters required'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Clear GRBL alarm state ($X)') and the resource ('machine'), distinguishing it from siblings like 'get_alarm_info' (which reads alarms) or 'emergency_stop' (which triggers a different safety action). It uses precise technical terminology ($X) that matches the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('Use after resolving the cause of the alarm'), providing a prerequisite condition. It also implies when not to use it (i.e., if the alarm cause isn't resolved), though it doesn't name specific alternatives—given the context, this is sufficient as the tool's purpose is narrowly scoped to post-alarm clearance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and effectively discloses key behavioral traits: it's a destructive action ('immediately halts all motion'), uses a specific protocol ('GRBL soft reset'), and implies urgency. However, it doesn't detail side effects like resetting machine state or requiring reconnection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise and front-loaded: the first phrase states the core action, followed by technical details and usage context in just two sentences, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-annotation tool with no output schema, the description is nearly complete: it explains purpose, usage, and mechanism. However, it lacks details on post-execution state (e.g., machine reset effects) or error handling, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema coverage, so the baseline is 4. The description adds no parameter information, which is appropriate given no parameters exist, maintaining the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('immediately halts all motion') and mechanism ('via GRBL soft reset (0x18)'), distinguishing it from sibling tools like 'stop_job' or 'feed_hold' by emphasizing its emergency nature and immediate effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('Use in any dangerous situation'), providing clear context for its application versus alternatives like 'stop_job' (normal stopping) or 'feed_hold' (temporary pause), with no misleading exclusions.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/brs077/CNC-design-control-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server