MQScript MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
The tools are generally well-differentiated by their specific functions, with clear prefixes like 'mqscript_cjson_' for JSON operations or 'mqscript_device_' for device controls. However, some overlap exists between similar UI interaction tools (e.g., 'mqscript_tap' vs. 'mqscript_element_click') and timing functions (e.g., 'mqscript_delay' vs. 'mqscript_sys_sleep'), which could cause minor confusion for an agent.
Naming Consistency5/5
All tools follow a consistent 'mqscript_' prefix with snake_case naming, using clear verb_noun patterns (e.g., 'mqscript_file_read', 'mqscript_ui_addcheckbox'). This uniformity makes the tool set predictable and easy to navigate, with no deviations in style or structure.
Tool Count2/5
With 83 tools, the count is excessive for a single server, making it overwhelming and difficult for an agent to manage effectively. This large number suggests poor scoping, as many functions could be consolidated (e.g., multiple string manipulation or UI tools) rather than exposed as separate tools.
Completeness5/5
The tool set provides comprehensive coverage for mobile automation and scripting, including file operations, UI interactions, device controls, mathematical functions, string manipulation, and system commands. There are no obvious gaps; it supports full CRUD-like workflows and diverse scripting needs without dead ends.
Average 2.8/5 across 83 of 83 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/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 but fails completely. 'Show floating window' doesn't indicate whether this is a read-only operation, whether it modifies state, what permissions might be required, whether it has side effects, or what happens if the window doesn't exist. For a tool that presumably interacts with UI elements, this lack of behavioral information is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three words, this description is under-specified rather than efficiently informative. It fails to provide necessary context about what 'show' means operationally. The single phrase doesn't earn its place by adding meaningful value beyond the tool name itself, making this a case of harmful brevity rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a UI manipulation tool with no annotations, no output schema, and sibling tools that suggest complex floating window operations, the description is completely inadequate. It doesn't explain what the tool returns, what happens on success/failure, how it relates to other floating window tools, or what 'showing' a window entails in this specific scripting context. The minimal description leaves critical gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention the 'id' parameter at all, but the input schema has 100% description coverage with a clear parameter description ('Floating window ID'). Since the schema documentation is complete, the baseline score of 3 is appropriate - the description adds no parameter information beyond what the schema already provides, but the schema adequately documents the single required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show floating window' is a tautology that essentially restates the tool name 'mqscript_fw_show' (where 'fw' likely stands for 'floating window'). It doesn't specify what 'show' means in this context - whether it makes a window visible, displays its properties, or something else. While it identifies the resource (floating window), the verb 'show' remains vague without clarifying the specific action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. There are multiple sibling tools related to floating windows (mqscript_fw_addbutton, mqscript_fw_addtextview, mqscript_fw_create, mqscript_fw_hide, mqscript_fw_onclick), but the description doesn't explain how 'show' differs from 'create' or relates to 'hide'. No context about prerequisites, sequencing, or appropriate use cases is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Output debug information' reveals nothing about behavioral traits: it doesn't specify where the output goes (console, log file, UI), whether it's synchronous/asynchronous, if it has side effects, or any performance characteristics. This leaves the agent completely in the dark about how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words. While this brevity comes at the cost of completeness, every word earns its place by conveying the core function without any fluff. It's front-loaded and wastes no space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a description that provides minimal context, this is completely inadequate. The agent cannot understand where the debug output goes, what format it takes, when to use it, or how it integrates with the broader system. For a debugging tool that could have various behavioral implications, this description fails to provide necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'message' clearly documented as 'Debug message to output'. The description adds no additional parameter semantics beyond what the schema already provides. With complete schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Output debug information' is a tautology that essentially restates the tool name 'mqscript_traceprint' (trace + print). It doesn't specify what type of debug information, where it goes, or what format it uses. While it indicates the general domain (debugging), it lacks the specificity needed to distinguish it from potential sibling debug tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or scenarios where this debug output would be appropriate versus other debugging methods or tools in the sibling list. The agent receives no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Release a key' implies an action that might affect system state (e.g., input simulation), but it doesn't specify if this requires permissions, has side effects, operates on a specific device, or what happens on invocation (e.g., does it trigger events?). This is inadequate for a tool with potential behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just two words ('Release a key'), which is appropriately sized for a simple tool. It's front-loaded with the core action, though this brevity contributes to gaps in other dimensions. There's no wasted language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's potential complexity (simulating key releases in an automation context), lack of annotations, no output schema, and minimal description, this is incomplete. The description doesn't cover what the tool returns, error conditions, or how it integrates with sibling tools like 'mqscript_keydown', leaving significant gaps for an AI agent to understand its use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'keyCode' documented as 'Key code to release' in the schema. The description adds no additional meaning beyond this, such as explaining key code formats (e.g., numeric codes, standard mappings) or examples. The baseline score of 3 reflects adequate but minimal value added over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Release a key' is a tautology that essentially restates the tool name 'mqscript_keyup' (key up = release a key). It doesn't specify what resource or system this operates on (e.g., keyboard input, virtual keypad, mobile device), nor does it distinguish from sibling tools like 'mqscript_keydown' or 'mqscript_keypress' that likely handle related key operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Given sibling tools like 'mqscript_keydown' and 'mqscript_keypress', there's no indication of whether this is for ending a key press, simulating key releases in automation, or other contexts. No prerequisites 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.
Behavior1/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. 'Exit the script' implies a termination action but doesn't specify critical behaviors: whether this stops the entire script execution, what happens to ongoing processes, if it's reversible, or any side effects (e.g., cleanup). This is inadequate for a tool that likely ends script flow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two words, with zero wasted language. It's front-loaded and to the point, though this brevity contributes to its lack of detail. Every word earns its place by stating the core action, but it could benefit from additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's likely critical role in script termination (implied by 'exit'), the description is incomplete. No annotations exist to clarify safety or behavior, and there's no output schema. The description fails to address what 'exiting' entails operationally, leaving significant gaps for an agent to understand this tool's impact in the scripting context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'exitCode' well-documented in the schema as 'Exit code' with a default of 0. The description adds no parameter information beyond what the schema provides, so it doesn't enhance understanding. The baseline score of 3 reflects adequate schema coverage without description contribution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Exit the script' is a tautology that restates the tool name 'mqscript_sys_exit' without adding meaningful context. It specifies the verb 'exit' and resource 'the script', but doesn't clarify what 'the script' refers to or how this differs from other termination methods in the sibling tools. It's minimally informative but essentially repeats the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, appropriate contexts (e.g., after completing tasks, on error), or how it compares to other system-related siblings like 'mqscript_sys_sleep' or 'mqscript_sys_getenv'. This leaves the agent without direction on proper invocation timing.
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. 'Get device information' implies a read-only operation but doesn't specify if it requires permissions, has side effects, or how it handles errors. It lacks details on return format, rate limits, or any behavioral traits beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single phrase 'Get device information'. It is front-loaded and wastes no words, though this brevity comes at the cost of completeness. Every word serves a purpose, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 2 parameters, the description is incomplete. It doesn't explain what 'device information' entails, how results are returned, or any behavioral context. While the schema covers parameters, the overall tool purpose and usage remain under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters ('infoType' and 'resultVariable') well-documented in the schema. The description adds no additional meaning beyond what the schema provides, such as examples or usage context. Given the high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get device information' is a tautology that restates the tool name 'mqscript_device_getinfo' without adding specificity. It mentions the verb 'get' and resource 'device information' but doesn't distinguish what kind of device information or how it differs from sibling tools like 'mqscript_device_setbrightness' or 'mqscript_device_setvolume'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any context, prerequisites, or exclusions, nor does it reference sibling tools for comparison. This leaves 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 of behavioral disclosure. 'Copy file' implies a mutation operation, but it doesn't disclose critical traits like whether it requires permissions, handles errors, or has side effects (e.g., overwriting files based on the 'overwrite' parameter). The description lacks context on what gets copied, how it behaves on failure, or any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Copy file' is extremely concise with zero wasted words, front-loading the core action. It's appropriately sized for a simple tool, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a file mutation operation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values, error handling, or behavioral nuances, leaving significant gaps for an AI agent to understand how to invoke it correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for 'sourcePath', 'destinationPath', and 'overwrite'. The description adds no additional meaning beyond what the schema provides, such as path formats or overwrite implications. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Copy file' is a tautology that restates the tool name 'mqscript_file_copy' without adding specificity. It mentions the verb 'copy' and resource 'file', but doesn't distinguish it from sibling tools like 'mqscript_file_read' or 'mqscript_file_write' beyond the basic action implied by the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as when to choose this over other file operations like 'mqscript_file_write' or 'mqscript_file_read' in the sibling list.
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 'compare' but doesn't specify what happens during comparison (e.g., returns a boolean, sets a variable, or logs result). It lacks details on permissions, side effects, error handling, or output format, which is inadequate for a tool with potential screen interaction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Compare color'). It avoids unnecessary words, but could be more structured by explicitly mentioning key parameters or context. Overall, it's appropriately sized with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (color comparison at coordinates), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the comparison result (e.g., boolean outcome stored in 'resultVariable'), error cases, or interaction with the screen, leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema, which has 100% coverage with clear parameter descriptions (e.g., 'expectedColor' in BBGGRR format). The description implies parameters for point ('specified point') and color comparison, but doesn't elaborate on semantics like coordinate systems or color formats. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Compare color at specified point with expected color', which is clear but vague. It specifies the verb ('compare') and resource ('color'), but lacks details on what 'point' refers to (screen coordinates) or the comparison mechanism. It doesn't distinguish from siblings like 'mqscript_findcolor' or 'mqscript_getpixelcolor', which are related color tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'mqscript_findcolor' (which searches for colors) or 'mqscript_getpixelcolor' (which retrieves color at a point), leaving the agent without context for tool selection. No explicit when/when-not instructions or prerequisites are included.
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 discloses minimal behavioral traits. It implies a read-only transformation (formatting), but doesn't specify if it modifies the original variable, creates a new one, handles errors (e.g., invalid formats), or has side effects. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it appropriately sized. However, it's not optimally front-loaded with critical details (e.g., it could start with 'Format an existing date/time variable...'), and the brevity contributes to vagueness rather than clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is incomplete. It lacks information on return values (e.g., where the formatted result is stored), error handling, and practical usage examples. Without annotations or output schema, the description should compensate more to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (dateTimeVariable, format, resultVariable) with clear descriptions. The description adds no additional meaning beyond the schema, such as format examples (e.g., 'yyyy-MM-dd' vs 'MM/dd/yyyy'), variable naming conventions, or default behavior nuances. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Format date time with specified format' states the basic action (formatting) and resource (date time), but it's vague about scope and lacks sibling differentiation. It doesn't specify whether this formats existing variables, system time, or other sources, nor does it distinguish from siblings like 'mqscript_datetime_adddays' or 'mqscript_datetime_now' beyond the core formatting concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a pre-existing date/time variable), exclusions, or comparisons to similar tools like 'mqscript_datetime_compare' or 'mqscript_sys_gettime'. The description offers only the basic function without context for decision-making.
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 lacks behavioral details: it doesn't disclose if this requires specific permissions, whether it's destructive (likely yes, as it sets text), error conditions, or side effects. The description is minimal and misses key 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and direct, though it could benefit from more detail without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a mutation tool (implied by 'set'), the description is incomplete. It doesn't cover behavioral traits, return values, or usage context, leaving significant gaps for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema. The description adds no additional meaning beyond the schema, such as format examples or constraints. Baseline 3 is appropriate since the schema adequately documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set text to UI element' clearly indicates the action (set) and target (UI element), but it's vague about scope and lacks differentiation from siblings like mqscript_element_gettext. It doesn't specify what type of UI elements or context (e.g., mobile automation, web interface).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. It doesn't mention prerequisites (e.g., needing an element ID from another tool), compare to siblings like mqscript_element_gettext, or specify contexts where it's appropriate.
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. 'Read file content' implies a read-only operation, but it doesn't specify potential side effects (e.g., file locking, memory usage for large files), error handling (e.g., what happens if the file doesn't exist or lacks permissions), or output format (e.g., returns a string, may throw exceptions). This leaves critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Read file content' is extremely concise—just three words—and front-loaded with the core action. It wastes no space on redundant details, but this brevity comes at the cost of completeness, as it omits necessary context for effective tool use. While efficient, it could benefit from a bit more elaboration to balance clarity with conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of file operations (with potential errors, encoding issues, and sibling tools), no output schema, and no annotations, the description is incomplete. It doesn't cover what the tool returns (e.g., file content as a string, error messages), how it handles edge cases (e.g., large files, missing files), or how it integrates with other tools (e.g., using 'resultVariable' in subsequent steps). This leaves significant gaps for an agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for 'filePath', 'encoding', and 'resultVariable'. The description adds no additional meaning beyond the schema, such as explaining how 'filePath' is resolved (e.g., relative vs. absolute) or what 'resultVariable' does in the broader context. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read file content' clearly states the verb ('Read') and resource ('file content'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'mqscript_file_write' (which writes files) or other file-related tools like 'mqscript_file_copy' and 'mqscript_file_delete', leaving room for ambiguity about when to choose this specific read 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'mqscript_file_exists' (to check file presence) and 'mqscript_file_write' (for writing), there's no indication of prerequisites (e.g., file must exist), use cases (e.g., reading configuration vs. data), or exclusions (e.g., not for binary files). This lack of context makes it harder for an agent to select the right tool.
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 ('Add button') but doesn't describe what happens after adding—e.g., whether the button is interactive by default, if it requires additional setup like event handlers, or any side effects. For a UI manipulation tool with zero annotation coverage, this is a significant gap in transparency about its behavior and implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Add button to floating window'. It's front-loaded with the core action and target, with zero wasted words. However, it's arguably too concise, bordering on under-specified for a tool with 7 parameters and no annotations, but within the dimension of conciseness, it scores well for being direct and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns, how errors are handled, or any behavioral nuances. For a tool that likely modifies UI state, more context is needed—e.g., whether it's idempotent, requires specific permissions, or interacts with other tools. The description alone is inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all 7 parameters (e.g., 'Control ID', 'Button text', 'X position in window'). The description adds no additional parameter semantics beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline is 3 even without param info in the description, which fits here as the schema adequately documents the inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add button to floating window' clearly states the action (add) and target (button to floating window), but it's somewhat vague about the specific context or scope. It doesn't differentiate from sibling tools like 'mqscript_fw_addtextview' or 'mqscript_ui_addcheckbox', which also add UI elements. The purpose is understandable but lacks specificity about what makes this button addition unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention when to choose this over 'mqscript_fw_addtextview' or other UI-related tools in the sibling list. The description is a bare statement without context about prerequisites, typical use cases, or exclusions, leaving the agent to infer usage based on 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. 'Create an If statement structure' implies a write operation that generates something, but it doesn't specify what is created (e.g., output format, whether it's saved or returned), any side effects, permissions needed, or error handling. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for a simple tool, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tool that creates code structures, the lack of annotations and output schema means the description should do more. It doesn't explain the output (e.g., whether it returns a string, modifies a script, or triggers execution), making it incomplete for effective use without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for 'condition', 'thenBody', and 'elseBody'. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain syntax examples or constraints). Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create an If statement structure' states the verb ('Create') and resource ('If statement structure'), making the purpose clear. However, it's somewhat vague about what exactly is being created (e.g., a code snippet, a configuration object, or a script block) and doesn't distinguish it from sibling tools like 'mqscript_for' or 'mqscript_while', which are also control flow structures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., within a scripting environment), or comparisons to other control flow tools like 'mqscript_for' or 'mqscript_while'. Without this, users must infer usage from the tool name and parameters 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 'Chat with TURING robot' but does not reveal if this is a read-only or mutating operation, rate limits, authentication needs, or what the response entails. This leaves significant gaps in understanding the tool's behavior and safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words, making it front-loaded and easy to parse. However, it is overly concise to the point of under-specification, lacking necessary details for a tool with behavioral complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with 4 parameters and potential behavioral complexity (e.g., chat interactions may involve network calls, error handling). It fails to address key aspects like response format, error conditions, or usage context, leaving the agent with insufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (apiKey, message, resultVariable, userId). The description adds no meaning beyond what the schema provides—it doesn't explain parameter interactions or usage context. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Chat with TURING robot' states the general action (chat) and target (TURING robot), but is vague about what this entails—it doesn't specify if this is for AI conversation, testing, or another purpose. It distinguishes from siblings (e.g., mqscript_turing_setconfig) by focusing on chat rather than configuration, but lacks specificity in verb+resource details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites (e.g., needing an API key), context for use, or exclusions. Without such information, the agent has no basis for choosing this tool over other chat or interaction tools in the sibling list.
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 ('parse') but doesn't describe key traits: error handling (e.g., what happens with invalid JSON), side effects (e.g., whether it modifies state), performance (e.g., speed or memory usage), or output format (e.g., the type of object returned). This leaves significant gaps for a tool that processes data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Parse JSON string to object' is front-loaded and directly conveys the core action. It's appropriately sized for a simple tool, avoiding unnecessary elaboration while staying focused on the task.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a data parsing tool with no annotations and no output schema), the description is incomplete. It doesn't explain the return value (what 'object' entails), error cases, or how it fits into the broader context of JSON handling with sibling tools. For a tool that transforms data, more detail is needed to ensure correct usage by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('jsonString' and 'resultVariable'). The description adds no meaning beyond this—it doesn't explain parameter interactions, default usage, or examples. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but there's no extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Parse JSON string to object' clearly states the verb ('parse') and resource ('JSON string'), but it's vague about the exact purpose—it doesn't specify what 'object' means in this context (e.g., a data structure for further manipulation) or how it differs from sibling tools like 'mqscript_cjson_stringify' (which likely does the reverse). It avoids tautology by not just restating the name, but lacks specificity for full 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like converting JSON data for processing, prerequisites (e.g., valid JSON input), or exclusions (e.g., not for binary data). With siblings like 'mqscript_cjson_get' and 'mqscript_cjson_set' that handle JSON objects, there's no explicit comparison to help an agent choose correctly.
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 but only states the basic action without disclosing behavioral traits. It doesn't cover whether the operation mutates the object in-place, handles errors for invalid paths, requires specific permissions, or has side effects, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that directly states the tool's purpose. It's front-loaded and wastes no words, making it efficient for quick understanding, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, error handling, return values, and usage context, making it insufficient for safe and effective tool invocation by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents the three parameters. The description adds no additional meaning beyond implying a 'set' action, which aligns with the schema but doesn't compensate with extra context like path syntax examples or value handling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set value in JSON object' clearly states the action (set) and target (JSON object), but it's vague about the scope and doesn't differentiate from siblings like mqscript_cjson_get. It specifies the resource but lacks detail on what 'set' entails operationally.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, such as when to choose this over other JSON tools like mqscript_cjson_parse or mqscript_cjson_stringify.
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. 'Convert value to string' implies a transformation operation but doesn't specify details like error handling (e.g., what happens if conversion fails), side effects, or performance characteristics. It lacks context on what 'value' means (e.g., input types, conversion rules) beyond the schema, leaving behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Convert value to string') that is front-loaded and wastes no words. It directly conveys the core function without unnecessary elaboration, making it appropriately sized for a simple conversion tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a conversion function with 2 parameters, no annotations, and no output schema), the description is incomplete. It doesn't explain the return value or storage mechanism (implied by 'resultVariable'), lacks error handling or input constraints, and doesn't differentiate from siblings. For a tool with no output schema and minimal annotations, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'value' described as 'Value to convert to string' and 'resultVariable' as 'Variable name to store result'. The description 'Convert value to string' adds minimal meaning beyond the schema, as it essentially restates the 'value' parameter's purpose. With high schema coverage, the baseline is 3, and the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Convert value to string' clearly states the action (convert) and target (value to string), which is a specific verb+resource. However, it doesn't distinguish this tool from its many siblings (like mqscript_cbool, mqscript_cint, etc.), which appear to be other conversion or utility functions. The purpose is understandable but lacks sibling 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like mqscript_cbool (convert to boolean) and mqscript_cint (convert to integer), it's unclear when string conversion is preferred or what context it applies to (e.g., data formatting, output preparation). No explicit when/when-not or alternative mentions are present.
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 like whether it modifies the original variable, creates a new one, handles negative days for subtraction, or deals with time zones. For a mutation 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just four words, front-loading the core action. There's zero waste or redundancy, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a mutation tool (adding days implies change), the description is incomplete. It doesn't explain the result format, error handling, or side effects. For a tool with three parameters and behavioral implications, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (dateTimeVariable, days, resultVariable) with clear descriptions. The description adds no additional meaning beyond the schema, such as examples or edge cases. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add days to date time' clearly states the action (add) and target (date time), but it's vague about what 'date time' refers to (a variable, a string, etc.) and doesn't distinguish from siblings like 'mqscript_datetime_compare' or 'mqscript_datetime_format'. It's functional but lacks specificity about the 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing an existing datetime variable, or compare to other datetime tools like 'mqscript_datetime_now' for current time. Usage is implied from the name but not explicitly stated.
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 'Compare two date times' but doesn't disclose behavioral traits like what the comparison returns (e.g., boolean, integer difference), side effects (e.g., stores result in a variable), or error handling. This is inadequate for a tool with potential mutation (storing results).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Compare two date times') with zero wasted words, making it front-loaded and easy to parse. However, this conciseness comes at the cost of completeness, but for this dimension alone, it's optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what the comparison does (e.g., returns -1, 0, 1 for ordering), how results are stored or used, or error cases. For a tool with 3 parameters and potential behavioral complexity, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema (e.g., 'First DateTime variable name'). The description adds no additional meaning beyond the schema, but since the schema is comprehensive, the baseline score of 3 is appropriate as it doesn't detract value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Compare two date times' clearly states the verb (compare) and resource (date times), but it's vague about what comparison means (e.g., equality, ordering, difference) and doesn't distinguish from siblings like 'mqscript_datetime_adddays' or 'mqscript_datetime_format'. It's adequate but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage based on the name alone. This is a significant gap for a tool in a set with many datetime-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Set device volume' implies a mutation operation but doesn't specify whether this requires special permissions, affects system-wide or app-specific settings, has side effects, or provides any feedback/confirmation. This leaves significant gaps in understanding the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, with zero wasted language. It's front-loaded with the core action and target, 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.
Completeness2/5
Given 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 insufficiently complete. It doesn't address what happens after setting the volume (success/failure indicators), potential side effects, or system constraints. Given the complexity of device operations and lack of structured behavioral hints, more context would be needed 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters (streamType with enum values and volume with range). The description adds no additional parameter semantics beyond what's already in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set device volume' clearly states the action (set) and target (device volume), which is a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'mqscript_device_setbrightness' or other device-related tools, making it somewhat generic within the context of this server's toolset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are no mentions of prerequisites, context requirements, or comparisons to sibling tools like 'mqscript_device_getinfo' or other volume-related functions that might exist in the broader system.
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 the basic action. It doesn't disclose behavioral traits such as whether vibration requires specific permissions, if it's synchronous/asynchronous, potential side effects (e.g., interrupting other operations), or error conditions (e.g., unsupported devices). This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Make device vibrate' is extremely concise with zero wasted words, front-loading the core action. It's appropriately sized for a simple tool, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a mutation tool (vibration implies device change), the description is incomplete. It lacks details on behavior, return values, error handling, and device-specific constraints, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'duration' parameter fully documented in the schema as 'Vibration duration in milliseconds' with a default of 200. The description adds no additional meaning beyond the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Make device vibrate' clearly states the action (make vibrate) and target (device), but it's vague about scope and doesn't differentiate from siblings like 'mqscript_device_setbrightness' or 'mqscript_device_setvolume' which also affect device settings. It's functional but lacks specificity about what kind of vibration or device 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., device compatibility), exclusions, or related tools like 'mqscript_device_getinfo' for checking device capabilities. The description alone offers no 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 the full burden of behavioral disclosure. It implies a UI interaction but doesn't specify what 'click' entails (e.g., single click, requires element visibility, potential side effects like navigation), leaving the agent to guess about behavior and risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with 'Click on UI element', a single sentence that is front-loaded and wastes no words. It efficiently conveys the core action, though it may be overly brief for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a UI interaction tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after the click (e.g., page change, error handling) or provide enough context for safe and effective use, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'elementId' clearly documented as 'Element ID or selector'. The description adds no additional meaning beyond this, so it meets the baseline 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Click on UI element' states a clear action (click) and target (UI element), but it's vague about scope and doesn't differentiate from sibling tools like 'mqscript_tap' or 'mqscript_touch' which likely perform similar UI interactions. It provides a basic purpose but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as 'mqscript_tap' or 'mqscript_touch', nor does it mention any prerequisites or context for usage. It's a generic statement with no usage instructions.
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 ('Get text') but doesn't explain what happens if the element isn't found, if the text is empty, or how the result is stored (e.g., in a variable as implied by the schema). It also omits details like whether this is a read-only operation (implied but not stated), potential errors, or performance considerations, leaving 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Get text from UI element') that is front-loaded and wastes no words. It directly conveys the core action without unnecessary elaboration, making it easy to parse quickly. Every part of the sentence earns its place by specifying what is being retrieved and from where.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of interacting with UI elements and the lack of annotations and output schema, the description is incomplete. It doesn't explain the return value (e.g., the text content as a string), error conditions, or dependencies on other tools (e.g., needing to identify elements first). For a tool that likely involves dynamic UI state, this leaves critical context gaps for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('elementId' and 'resultVariable'). The description adds no additional meaning beyond the schema, such as examples of valid element IDs or how the result variable is used. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get text from UI element' clearly states the verb ('Get') and resource ('text from UI element'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'mqscript_element_settext' (which sets text) or other text-related tools like 'mqscript_cstr' or 'mqscript_inputtext', leaving room for ambiguity about when to choose 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a UI element to be visible or accessible), compare it to siblings like 'mqscript_element_settext' for text manipulation, or suggest other tools for related tasks such as 'mqscript_inputtext' for user input. This lack of context makes it harder for an agent to decide when this tool is appropriate.
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. 'Delete file' implies a destructive mutation, but it doesn't disclose critical behaviors: whether deletion is permanent or reversible, permission requirements, error handling (e.g., if file doesn't exist), or side effects. This leaves significant gaps for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two words, front-loading the essential action. There is no wasted language, making it efficient for quick understanding, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, no annotations, and no output schema, the description is incomplete. It lacks details on behavior, outcomes, error cases, and usage context, which are crucial for safe and effective tool invocation by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'filePath' clearly documented as 'File path to delete'. The description adds no additional meaning beyond this, but since the schema is comprehensive, the baseline score of 3 is appropriate as it doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete file' clearly states the action (delete) and resource (file), but it's vague about scope and lacks differentiation from siblings like 'mqscript_file_copy' or 'mqscript_file_write'. It doesn't specify if it deletes a single file, multiple files, or has any constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., file must exist), when not to use it (e.g., for directories), or compare it to sibling file operations like 'mqscript_file_copy' for moving files.
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 ('check') but doesn't disclose behavioral traits such as whether it's read-only (implied but not explicit), error conditions (e.g., invalid paths), performance implications, or output format. This leaves gaps in understanding how the tool behaves beyond the basic check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words ('Check if file exists'), which is front-loaded and wastes no space. Every word contributes directly to the purpose, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., boolean, error message) or how results are stored via 'resultVariable'. For a tool with no structured behavioral data, more context is needed to fully understand its operation and integration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('filePath' and 'resultVariable'). The description doesn't add any meaning beyond what the schema provides, as it doesn't elaborate on parameter usage or constraints. Given the high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check if file exists' clearly states the verb ('check') and resource ('file'), making the purpose understandable. However, it's somewhat vague about what 'exists' means in this context (e.g., file system existence vs. some other state) and doesn't distinguish from siblings like 'mqscript_file_read' or 'mqscript_file_delete' beyond the basic action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., file permissions), error handling, or comparisons to siblings like 'mqscript_file_read' (which might implicitly check existence). The description lacks context for decision-making.
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 the basic action. It doesn't disclose behavioral traits like whether it creates files if they don't exist, overwrites by default, requires permissions, handles errors, or has side effects. This is inadequate for a file-writing tool with mutation implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for its purpose, though it could benefit from more detail given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file-writing tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like file creation, error handling, or return values, leaving significant gaps in understanding how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters (filePath, content, append, encoding). The description adds no meaning beyond what the schema provides, as it doesn't explain parameter interactions or usage nuances. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Write content to file' clearly states the verb ('Write') and resource ('content to file'), but it's vague about scope and doesn't differentiate from sibling tools like 'mqscript_file_copy' or 'mqscript_file_read'. It doesn't specify whether this creates new files or modifies existing ones, making it less specific than ideal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'mqscript_file_copy' or 'mqscript_file_read'. The description lacks context about prerequisites (e.g., file existence), exclusions, or comparison to siblings, leaving usage entirely implicit.
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 for behavioral disclosure. 'Create' implies a mutation operation, but the description doesn't mention whether this requires specific permissions, if the window is persistent, what happens on failure, or any side effects. It lacks details on the creation process, such as whether it appears immediately or requires additional steps like 'mqscript_fw_show'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single phrase 'Create a floating window', which is front-loaded and wastes no words. Every part of the description earns its place by stating the core action and resource, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a creation tool with 5 parameters and no annotations or output schema, the description is incomplete. It doesn't explain the floating window's lifecycle, how it integrates with other tools (e.g., adding elements with sibling tools), or what happens after creation. For a mutation tool with no structured support, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters (id, height, width, x, y) documented in the schema. The description adds no additional meaning beyond the schema, such as explaining the coordinate system (e.g., pixels, screen-relative), default behavior, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a floating window' clearly states the action (create) and resource (floating window), but it's somewhat vague about what a 'floating window' is in this context and doesn't differentiate from sibling tools like 'mqscript_fw_addbutton' or 'mqscript_fw_show' that also manipulate floating windows. It's better than a tautology but lacks specificity about the window's purpose or characteristics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools related to floating windows (e.g., 'mqscript_fw_addbutton', 'mqscript_fw_hide'), but the description doesn't explain that this tool is for initial creation while others are for modification or interaction. No context or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'hide' but doesn't explain what happens to the floating window (e.g., if it's destroyed, minimized, or hidden from view), whether it requires specific permissions, or any side effects like resource cleanup. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with 'Hide floating window', consisting of a single, front-loaded sentence that directly states the tool's purpose without any wasted words. It efficiently communicates the core action, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation to hide a floating window), no annotations, no output schema, and minimal description, the description is incomplete. It lacks details on behavioral outcomes, error conditions, or what 'hide' entails, which is insufficient for safe and effective use by an AI agent in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'id' parameter clearly documented as 'Floating window ID'. The description adds no additional meaning beyond this, as it doesn't elaborate on parameter usage or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Hide floating window' clearly states the action (hide) and target (floating window), but it's vague about what 'hide' means operationally (e.g., minimize, remove from view, or background). It distinguishes from sibling tools like 'mqscript_fw_show' by implying opposite functionality, but lacks specificity about the resource's state post-hide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for hiding floating windows, but it doesn't specify prerequisites (e.g., requires an existing floating window), exclusions, or comparisons to related tools like 'mqscript_fw_show' for toggling visibility.
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 tool checks if a value is numeric, but doesn't explain what 'numeric' means (e.g., integers, floats, scientific notation), how the result is returned (e.g., boolean, string), or any error handling. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose and appropriately sized for a simple checking 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.
Completeness2/5
Given 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 incomplete. It doesn't explain the return format (e.g., boolean stored in a variable), what constitutes a 'numeric' value, or error cases. For a tool in a scripting context with many siblings, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for both parameters: 'value' (value to check) and 'resultVariable' (variable name to store result). The description adds no additional parameter semantics beyond what the schema already provides, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check if value is numeric' clearly states the tool's purpose with a specific verb ('check') and object ('value'), but it doesn't distinguish this tool from its many siblings (e.g., mqscript_cbool, mqscript_cint) which perform similar type-checking or conversion operations. The purpose is understandable but lacks sibling 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like mqscript_cint (convert to integer) or mqscript_cbool (convert to boolean). There's no mention of prerequisites, context, or comparison with sibling tools, leaving the agent to infer usage based on 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 ('Press a key once') but lacks behavioral details such as whether this requires specific permissions (e.g., accessibility services), what happens on failure, if it's synchronous or asynchronous, or any side effects (e.g., triggering system events). For a tool that likely interacts with device input, this is a significant gap in 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Press a key once' is extremely concise and front-loaded, consisting of a single, clear sentence with zero waste. It efficiently communicates the core action without unnecessary details, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a key-press tool (likely for device automation), the description is incomplete. No annotations or output schema exist, and the description lacks context on usage, behavior, or return values. It doesn't explain what 'once' entails (e.g., duration, timing) or how it integrates with other tools, leaving significant gaps for an AI agent to understand its full role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'keyCode' fully documented in the schema (e.g., examples like 4 for back). The description adds no additional meaning beyond the schema, as it doesn't mention the parameter at all. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Press a key once' clearly states the action (press) and target (a key), but it's vague about the context—it doesn't specify what device or interface the key press applies to (e.g., Android device, virtual keyboard). It distinguishes from siblings like 'mqscript_keydown' and 'mqscript_keyup' by implying a single press action, but the distinction isn't explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention siblings like 'mqscript_keydown' (for holding a key) or 'mqscript_keyup' (for releasing a key), nor does it specify prerequisites or contexts (e.g., use during automation on a mobile device). The description alone offers no usage instructions.
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 for behavioral disclosure. While 'Get substring' implies a read-only operation, the description doesn't address potential edge cases (e.g., what happens if start position is out of bounds, if length extends beyond string, or if negative values are used). It also doesn't mention that the result is stored in a variable (as indicated by the resultVariable parameter), which is a key behavioral aspect. The description is minimal and lacks 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words ('Get substring from specified position'). It's front-loaded with the core functionality and contains no wasted words. While it may be too brief for optimal tool understanding, it earns full marks for conciseness as every word contributes directly to stating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a string manipulation tool with 4 parameters and no annotations or output schema, the description is inadequate. It doesn't explain the 1-based indexing (mentioned in schema but not emphasized), doesn't clarify the default behavior when length is -1, doesn't mention the variable storage mechanism, and provides no examples or context about return values. Given the complexity of substring extraction with position and length parameters, more guidance is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four parameters well-documented in the schema itself (text, start, length, resultVariable). The description adds no additional parameter information beyond what the schema provides - it doesn't explain the relationship between parameters or provide usage examples. With complete schema coverage, the baseline score of 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get substring from specified position' clearly states the verb ('Get substring') and resource ('from specified position'), making the purpose understandable. However, it doesn't distinguish this tool from sibling string manipulation tools like 'mqscript_left', 'mqscript_right', or 'mqscript_instr', which all work with substrings or string positions. The description is functional but generic within this 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'mqscript_left' (get left substring), 'mqscript_right' (get right substring), and 'mqscript_instr' (find substring position), there's clear overlap in functionality, but the description doesn't explain when this mid-position extraction is preferred over those other approaches. No usage context 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.
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 ('Make a phone call') but does not describe traits such as whether it initiates a call immediately, requires user interaction, handles errors, or has side effects (e.g., audio output, call logs). 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Make a phone call' is extremely concise with zero wasted words, front-loading the core action. It efficiently communicates the tool's purpose in a single, clear phrase without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that performs a phone call—a potentially complex action with device and network dependencies—the description is inadequate. With no annotations, no output schema, and minimal behavioral details, it fails to provide necessary context such as success/failure responses, permissions needed, or interaction with the device's call system, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'phoneNumber' parameter clearly documented as 'Phone number to call'. The description does not add any extra meaning beyond this, such as format requirements (e.g., international codes) or validation rules. Given the high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Make a phone call' clearly states the action (make) and resource (phone call), providing a basic purpose. However, it lacks specificity about the context (e.g., automated calling, device interaction) and does not distinguish from sibling tools like 'mqscript_phone_sendsms' or 'mqscript_phone_getcallstate', which are related phone operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., device permissions, network connectivity), exclusions, or comparisons to sibling tools like 'mqscript_phone_sendsms' for SMS or 'mqscript_phone_getcallstate' for checking call status, leaving usage context unclear.
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 for behavioral disclosure. 'Send SMS message' implies a write operation with external effects, but it doesn't disclose permissions needed, rate limits, delivery confirmation, costs, or error handling. This leaves significant gaps for a tool that interacts with phone systems.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words with zero wasted text. It's front-loaded with the core action and resource, though this brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that sends SMS messages (a mutation with external effects), the description is inadequate given no annotations and no output schema. It doesn't explain what happens after sending, error conditions, or system requirements. The minimal description leaves too many questions unanswered for proper tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (phoneNumber and message) clearly documented in the schema. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 where schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send SMS message' clearly states the action (send) and resource (SMS message), but it's vague about scope and doesn't differentiate from sibling tools like mqscript_phone_call. It provides basic purpose but lacks specificity about what exactly is being sent or to what system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, constraints, or compare it to related tools like mqscript_phone_call or mqscript_showmessage. Users must 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?
No annotations are provided, so the description must fully disclose behavior. 'Launch an application' implies a write/mutation action (starting an app), but it does not specify permissions required (e.g., accessibility settings), side effects (e.g., app opens in foreground), error handling (e.g., if app not found), or performance traits (e.g., blocking until launch). This lack of detail is a significant gap 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Launch an application' is a single, efficient sentence with no wasted words. It is front-loaded and directly states the core action, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of launching an application (a mutation with potential side effects), no annotations, no output schema, and minimal description, the tool is inadequately documented. The description does not cover return values, error cases, or behavioral nuances, leaving critical gaps for an AI agent to invoke it correctly in a real-world context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'packageName' clearly documented as 'Package name of the app to launch'. The description does not add any meaning beyond this, such as format examples (e.g., 'com.example.app') or constraints. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Launch an application' clearly states the action (launch) and target (application), providing a basic purpose. However, it lacks specificity about what type of application (e.g., mobile app, system app) or context (e.g., on a device, in a script environment), and does not distinguish it from potential siblings like 'mqscript_sys_shell' which might also launch applications. This makes it vague but not tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., app must be installed), context (e.g., use in automation scripts), or compare it to siblings like 'mqscript_sys_shell' for broader system commands. This absence of usage context leaves the agent without clear 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 'Set TURING robot configuration,' implying a write/mutation operation, but doesn't clarify if this is persistent, reversible, requires specific permissions, or has side effects (e.g., affecting other tools). This leaves significant gaps in understanding the tool's behavior beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single phrase, 'Set TURING robot configuration,' which is front-loaded and wastes no words. It directly states the tool's purpose without unnecessary elaboration, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a configuration-setting tool with no annotations and no output schema, the description is incomplete. It doesn't address what the configuration affects, success/failure outcomes, or how it integrates with sibling tools like 'mqscript_turing_chat.' For a mutation tool with behavioral implications, more context is needed to ensure safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter descriptions (e.g., 'TURING API key'). The description adds no additional meaning beyond this, as it doesn't explain how these parameters interact or their role in configuration. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set TURING robot configuration' clearly indicates a configuration-setting action for a TURING robot, which is a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'mqscript_turing_chat' or explain what 'configuration' entails beyond the parameters. This makes it somewhat vague about the exact scope of configuration being set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing API access), exclusions, or related tools like 'mqscript_turing_chat' for chat interactions. Without such context, users must 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 ('Add') but doesn't explain what happens after adding (e.g., if it returns a control reference, modifies UI state, or requires further steps). No details on permissions, side effects, or error handling are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for the tool's apparent complexity, 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/5
Given 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 incomplete. It lacks information on return values, behavioral traits, and usage context, which are crucial for a UI control tool. The schema handles parameters well, but overall guidance is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters (id, defaultText, hint) with clear descriptions. The tool description adds no additional meaning or context beyond what the schema provides, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Add') and the resource ('edit text control'), which clarifies the basic purpose. However, it's vague about what an 'edit text control' is (e.g., a UI input field) and doesn't distinguish it from similar sibling tools like 'mqscript_ui_addcheckbox' or 'mqscript_inputtext', missing specific 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention context (e.g., for creating user interfaces), prerequisites, 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?
With no annotations, the description carries full burden but only states the basic action without disclosing behavioral traits like whether it requires prior UI setup, affects other controls, has side effects, or provides feedback. It lacks details on permissions, error handling, or interaction with other UI tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste, front-loading the core action. It's appropriately sized for a simple tool, making it easy to parse without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a mutation tool. It doesn't cover behavioral aspects like success indicators, error conditions, or dependencies on other UI tools, leaving gaps in understanding how to use it effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both parameters ('id' as Control ID and 'visible' as Visible state). The description adds no meaning beyond this, such as explaining ID formats or visibility implications, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set visibility of a UI control' clearly states the action (set visibility) and target (UI control), but it's vague about what constitutes a 'UI control' and doesn't differentiate from sibling tools like 'mqscript_ui_setenabled' or 'mqscript_ui_show'. It avoids tautology but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'mqscript_ui_show' or 'mqscript_fw_show/hide'. The description implies usage for UI visibility changes but offers no context on prerequisites, exclusions, or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Show the UI dialog' but lacks details on behavioral traits such as whether it blocks execution, requires user interaction, handles errors, or has side effects. For a UI 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is appropriately sized and front-loaded, making it easy to parse without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a UI tool that likely involves user interaction, the description is incomplete. It fails to cover key aspects like what the dialog displays, how it interacts with the user, or what happens after showing. This leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'title' well-documented in the schema. The description adds no additional meaning beyond the schema, such as explaining the dialog's content or behavior. Baseline 3 is appropriate as the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show the UI dialog' states a clear action (show) and target (UI dialog), but it's vague about what specific UI dialog is shown and lacks differentiation from sibling tools like 'mqscript_showmessage' or 'mqscript_fw_show'. It provides a basic purpose without specifics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'mqscript_showmessage' (for messages) or 'mqscript_fw_show' (for floating windows). The description offers no context, prerequisites, or exclusions, leaving usage unclear.
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 conversion action but doesn't describe how the conversion works (e.g., what strings map to true/false, error handling for invalid inputs, or whether it's a read-only operation). This leaves significant gaps for a tool that performs data transformation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple conversion 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (boolean conversion), 100% schema coverage, and no output schema, the description is minimally adequate. However, it lacks details on conversion rules or output format, which could be helpful for an agent to use it correctly without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters: 'value' (value to convert) and 'resultVariable' (variable name to store result). The description adds no additional meaning beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without extra param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Convert value to boolean' clearly states the tool's function with a specific verb ('convert') and resource ('value'), but it doesn't distinguish this from sibling tools like 'mqscript_cint' (convert to integer) or 'mqscript_cstr' (convert to string) beyond the boolean focus. It's not tautological but lacks sibling 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or compare it to other conversion tools in the sibling list, leaving the agent to infer usage based on 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. 'Get environment variable' implies a read-only operation, but it doesn't specify what happens if the variable doesn't exist (e.g., returns null, error, or default), whether it's safe or has side effects, or any rate limits. This leaves significant gaps for an agent to understand the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear phrase ('Get environment variable') with zero wasted words. It's front-loaded and efficiently conveys the core action without unnecessary elaboration, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (a simple read operation with 2 parameters), 100% schema coverage, and no output schema, the description is minimally adequate. However, it lacks details on behavioral aspects like error handling or return values, which are not covered by annotations or schema. This makes it incomplete for full agent understanding, though not severely lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('varName' and 'resultVariable'), including a default value for 'resultVariable'. The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints. Since schema coverage is high, the baseline score of 3 is appropriate, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get environment variable' clearly states the verb ('Get') and resource ('environment variable'), making the purpose understandable. However, it lacks specificity about scope or context (e.g., system vs. script environment), and while it distinguishes from obvious opposites like 'setenv', it doesn't explicitly differentiate from similar tools like 'sys_gettime' in the sibling list, which is a different type of system query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an environment variable to exist), exclusions, or comparisons to siblings like 'sys_setenv' for setting variables or 'sys_gettime' for other system data. Usage is implied by the name but not explicitly stated.
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 'Get' which implies a read operation, but doesn't specify if it's safe, has side effects, requires permissions, or how it handles errors (e.g., for non-existent arrays). 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste: 'Get upper bound of array'. It's appropriately sized and front-loaded, making it easy to parse quickly without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (array operation with 2 parameters), 100% schema coverage, and no output schema, the description is minimally adequate. It states the purpose but lacks details on behavior, usage context, or return values. With no annotations, it should do more to compensate, but it meets a basic threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters: 'arrayName' as the name of the array and 'resultVariable' as the variable to store the result. The description adds no additional meaning beyond what the schema provides, such as explaining what 'upper bound' means for the array or default behavior. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get upper bound of array' clearly states the verb ('Get') and resource ('upper bound of array'), making the purpose understandable. However, it doesn't specify what 'upper bound' means in this context (e.g., maximum index, size, or value) or distinguish it from similar tools like 'mqscript_len' (which might get array length). This makes it somewhat vague compared to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'mqscript_len' (likely for length) and 'mqscript_ubound' (for upper bound), there's no indication of the difference, prerequisites, or context for choosing one over the other. This leaves usage entirely implied.
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 a read operation ('Get'), implying no destructive effects, but doesn't disclose behavioral traits like error handling, performance, or how the result is returned (e.g., in a variable). This is inadequate for a tool with parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the core purpose. It's appropriately sized for a simple mathematical function, 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/5
Given 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 incomplete. It doesn't explain return values, error cases, or how the result is stored (e.g., in 'resultVariable'), leaving gaps for a tool with parameters and potential behavioral nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('number' and 'resultVariable') fully. The description adds no additional meaning beyond the schema, such as examples or constraints, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'absolute value of a number', making the purpose specific and understandable. However, it doesn't differentiate from siblings like 'mqscript_sqr' (square root) or 'mqscript_sin' (sine), which are also mathematical operations, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for mathematical operations (e.g., 'mqscript_sqr', 'mqscript_sin'), there's no indication of context, prerequisites, or exclusions, leaving usage unclear.
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. 'Convert value to integer' implies a transformation operation but doesn't specify error handling (what happens with non-convertible strings like 'abc'), whether the operation is destructive to the original value, or what permissions might be required. This leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, front-loading the core functionality with zero wasted language. Every word earns its place by communicating the essential purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns (the converted integer value), how errors are handled, or provide context about the conversion process (e.g., base interpretation, truncation behavior). For a type conversion tool in a scripting environment, this leaves too many practical questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters ('value' and 'resultVariable') clearly documented in the schema. The description adds no additional parameter information beyond what's already in the structured schema, so it meets the baseline score when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Convert value to integer' clearly states the tool's function with a specific verb ('Convert') and resource ('value to integer'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'mqscript_cbool' or 'mqscript_cstr' which perform similar type conversions, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'mqscript_cbool' (convert to boolean) and 'mqscript_cstr' (convert to string), there's no indication of when integer conversion is appropriate or what happens with non-numeric input values.
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. 'Get value from JSON object' implies a read-only operation, but it doesn't specify error handling (e.g., what happens if the path doesn't exist), performance characteristics, or side effects like variable storage. For a tool with 3 parameters and no annotations, this leaves significant gaps in understanding its behavior beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Get value from JSON object') that is front-loaded and wastes no words. It directly conveys the core action without unnecessary elaboration, making it easy to parse and understand quickly. Every word earns its place in defining the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a JSON extraction tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the return format, error conditions, or how the resultVariable interacts with the system. While the schema covers parameter basics, the lack of behavioral and output details makes it inadequate for full understanding, especially compared to more detailed sibling tools in the list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for all parameters (e.g., 'JSON object variable name', 'Property path', 'Variable name to store result'). The description 'Get value from JSON object' adds minimal semantic context beyond the schema, such as implying extraction via a path, but doesn't elaborate on path syntax or variable usage. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get value from JSON object' clearly states the verb ('Get') and resource ('value from JSON object'), making the purpose immediately understandable. It distinguishes from obvious siblings like 'mqscript_cjson_set' (which sets values) and 'mqscript_cjson_parse' (which parses JSON strings), though it doesn't explicitly mention these distinctions. The purpose is specific but could be slightly more detailed about the extraction mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'mqscript_cjson_set' for setting values or 'mqscript_cjson_parse' for creating JSON objects from strings, nor does it specify prerequisites such as requiring a parsed JSON object. Usage is implied by the tool name and description but lacks explicit context or exclusions.
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. 'Convert object to JSON string' implies a read-only transformation, but it doesn't specify error handling (e.g., for non-serializable objects), performance characteristics, or side effects like variable creation. The description is minimal and lacks critical behavioral context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is 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 avoids unnecessary elaboration, making it easy to parse quickly. Every word earns its place by directly conveying the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that performs data transformation. It doesn't explain the return value (e.g., where the JSON string is stored or how to access it), error conditions, or dependencies on other tools. For a 2-parameter tool with no structured support, more context is needed for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (objectVariable and resultVariable) with clear descriptions. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. This meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Convert object to JSON string' clearly states the verb ('convert') and resource ('object to JSON string'), making the purpose immediately understandable. It distinguishes from siblings like mqscript_cjson_parse (which does the reverse) and mqscript_cjson_get/set (which manipulate JSON). However, it doesn't specify the exact scope or limitations beyond the basic conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing object variable), compare it to similar tools like mqscript_cjson_parse for the inverse operation, or indicate any context-specific constraints. Usage is implied from the name and description but not explicitly stated.
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 pauses execution, implying it's a blocking operation, but doesn't disclose behavioral traits such as whether it's interruptible, if it affects script state, error handling for invalid durations, or performance impacts. The description is minimal and lacks necessary context for safe 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Pause script execution') and specifies the key detail ('for specified duration'). There is zero waste, and every word earns its place, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a blocking delay operation with no annotations and no output schema), the description is incomplete. It lacks information on behavioral risks (e.g., script hanging), error conditions, or return values. For a tool that could significantly impact script flow, more context is needed to ensure safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'milliseconds' clearly documented in the schema. The description adds no additional meaning beyond implying a duration is specified, which is already covered. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Pause') and resource ('script execution') with the specific action of delaying for a specified duration. It distinguishes itself from siblings by focusing on timing control rather than UI manipulation, file operations, or other script functions, though it doesn't explicitly contrast with similar timing tools like 'mqscript_sys_sleep'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'mqscript_sys_sleep' (which might serve a similar purpose) or specify contexts where a delay is appropriate (e.g., waiting for UI updates, network responses). Usage is implied only through the action described.
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. 'Define variables or arrays' implies a write/mutation operation, but it doesn't disclose behavioral traits like scope (local/global), persistence, error handling, or what happens if variables already exist. For a mutation tool with zero annotation coverage, this leaves critical behavioral aspects 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Define variables or arrays' is extremely concise—just three words—with zero wasted language. It's front-loaded with the core action and resources. Every word earns its place by specifying both the operation and target, making it efficiently structured despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a variable/array definition tool with no annotations and no output schema, the description is incomplete. It doesn't explain the scripting context, return values, error conditions, or how this interacts with other tools in the mqscript_* family. For a mutation operation in what appears to be a scripting environment, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'variables' documented as 'Variable names separated by commas (e.g., "a, b(), c")'. The description adds no additional meaning beyond this schema information, such as explaining what 'b()' signifies or how arrays are specified. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Define variables or arrays' clearly states the verb 'define' and the resources 'variables or arrays', providing a specific purpose. However, it doesn't distinguish this tool from its many siblings (e.g., mqscript_cint, mqscript_cstr) which also appear to define or convert values, leaving some ambiguity about when this particular definition tool should be used versus others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With numerous sibling tools like mqscript_cint (convert to integer) and mqscript_cstr (convert to string), there's no indication whether this tool is for initial declaration, type conversion, or something else. No context, exclusions, or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions capabilities like 'multiple colors, color deviation, and similarity' but fails to describe critical behaviors: what happens when no color is found (e.g., returns null, sets variables to default), whether the search is case-sensitive or screen-dependent, or any performance implications (e.g., slow for large regions). For a tool with 10 parameters and no 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place by highlighting key features (region, multiple colors, deviation, similarity) without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no annotations, no output schema), the description is inadequate. It doesn't explain the return format (e.g., what 'result index' means, how coordinates are stored), error conditions, or practical use cases. For a screen-interaction tool with variable output storage, more context is needed to guide effective usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal value beyond the input schema, which has 100% coverage with detailed parameter descriptions. It hints at 'multiple colors, color deviation, and similarity'—concepts already covered in the 'colorValue' and 'similarity' parameter descriptions. Since schema coverage is high, the baseline is 3, and the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find color in specified region with support for multiple colors, color deviation, and similarity.' It specifies the verb ('Find'), resource ('color'), and key capabilities (multiple colors, deviation, similarity). However, it doesn't explicitly differentiate from sibling tools like 'mqscript_cmpcolor' or 'mqscript_getpixelcolor', which appear to be related color operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'mqscript_cmpcolor' (which might compare colors) or 'mqscript_getpixelcolor' (which might retrieve a single pixel's color), leaving the agent to infer usage context from tool names 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. 'Create' implies a code-generation operation, but it doesn't describe what happens after creation (e.g., whether the loop is executed immediately, how it integrates with other script components, or any side effects). This leaves significant behavioral gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose and appropriately sized for a straightforward 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a code-generation tool with no annotations and no output schema, the description is insufficient. It doesn't explain the output format (e.g., whether it returns generated code as a string or modifies a script state), error conditions, or integration with the scripting environment, leaving critical context gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the schema provides. However, schema description coverage is 100%, with clear documentation for all 5 parameters (variable, start, end, step, body). The baseline score of 3 reflects that the schema adequately covers parameters, though the description doesn't enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a For loop structure' clearly states the verb ('Create') and resource ('For loop structure'), making the purpose immediately understandable. It distinguishes from siblings like 'mqscript_if' and 'mqscript_while' by specifying a for-loop construct, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when a for-loop is appropriate compared to while-loops or other control structures, nor does it specify prerequisites or typical use cases within the scripting 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 offers minimal behavioral insight. It implies a write operation ('Add') but doesn't disclose effects like whether the text view is persistent, requires specific permissions, or interacts with other UI components. No information on error handling, performance, or side effects is included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words, making it highly efficient and front-loaded. It immediately conveys the core function without unnecessary elaboration, which is ideal for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It lacks details on behavioral traits, usage context, and expected outcomes, leaving gaps in understanding how to effectively invoke and interpret results from this UI modification tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional semantic context beyond implying a UI addition, which is already clear from the tool name and schema. This meets the baseline for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add text view to floating window' clearly states the action (add) and resource (text view to floating window), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'mqscript_fw_addbutton' or 'mqscript_ui_addedittext', which also add UI elements but to different contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing floating window), compare it to similar tools like 'mqscript_fw_addbutton' for adding buttons, or specify use cases for text views over other UI elements.
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 tool sets an event handler but doesn't explain what happens when clicked (e.g., executes code, may affect UI state), whether it overwrites existing handlers, requires specific permissions, or has side effects. 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/5
Is 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's front-loaded and wastes no space, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that modifies UI behavior (setting event handlers) with no annotations and no output schema, the description is insufficient. It lacks details on behavioral outcomes (e.g., what the handler does, error conditions), doesn't reference sibling tools for context, and fails to explain the mutation's impact, leaving gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (windowId, controlId, handlerCode) with clear descriptions. The description doesn't add any additional meaning beyond what the schema provides, such as explaining parameter relationships or usage examples, meeting 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set click event handler') and target resource ('for floating window button'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'mqscript_element_click' or 'mqscript_fw_addbutton', which might handle similar UI interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a created floating window), exclusions, or comparisons to sibling tools like 'mqscript_element_click' for non-floating-window elements.
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 the basic function. It doesn't disclose whether this reads from screen, requires specific permissions, has performance implications, or what format the color is returned in (RGB, hex, etc.). The description is minimal and lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core function without any 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (color format), where it reads from (screen coordinates system), or any limitations. Given the complexity of coordinate-based operations and lack of structured data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description mentions 'specified coordinates' which aligns with the x and y parameters, but adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get color') and target ('pixel at specified coordinates'), making the purpose immediately understandable. It doesn't differentiate from siblings like 'mqscript_cmpcolor' or 'mqscript_findcolor', but it's specific enough to understand what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'mqscript_cmpcolor' (compare colors) or 'mqscript_findcolor' (find colors on screen). There's no mention of prerequisites, context, or typical use cases.
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 the basic action without behavioral details. It doesn't disclose whether this requires specific permissions, how it interacts with UI state, potential side effects, or error conditions, which is inadequate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words, clearly front-loading the core action. Every word earns its place, 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.
Completeness2/5
Given 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 lacks behavioral context, error handling, and output expectations, failing to compensate for the missing structured data, which is insufficient for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'text' parameter fully. The description adds no additional meaning beyond implying text input into a field, aligning with the baseline score when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Input text') and target ('into the current focused field'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'mqscript_element_settext' which might serve similar text-setting purposes, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing a focused field), exclusions, or comparisons to siblings like 'mqscript_element_settext' or 'mqscript_keypress', leaving usage context ambiguous.
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 tool finds a substring position, but doesn't describe what happens if the substring isn't found (e.g., returns -1, null, or error), whether it's case-sensitive, or any performance or side-effect considerations. This leaves significant gaps for a tool that performs a search operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Find position of substring in string') that front-loads the core purpose with zero waste. It's appropriately sized for a straightforward tool, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (string search with optional parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain the return value (e.g., integer position or error indicator), edge cases, or how it fits among many string-related siblings, leaving the agent with insufficient context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all parameters clearly documented in the input schema (e.g., 'text' as the string to search in, 'searchText' as the substring). The description adds no additional parameter semantics beyond the schema, so it meets the baseline of 3 where the schema does the heavy lifting without extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Find position of substring in string', which specifies the verb ('find position') and resource ('substring in string'). It's specific enough to understand the core functionality, though it doesn't explicitly differentiate from potential string manipulation siblings like 'mqscript_mid' or 'mqscript_replace' that might also work with substrings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for string manipulation (e.g., mqscript_mid, mqscript_replace, mqscript_split), there's no indication of this tool's specific use case, prerequisites, or exclusions, leaving the agent to infer usage from the purpose 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. 'Press and hold a key' implies a mutation action but doesn't disclose behavioral traits like whether it requires specific permissions, how long the key is held, if it interacts with system events, or what happens on failure. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Press and hold a key' is a single, efficient sentence that is front-loaded and wastes no words. It directly conveys the core action without unnecessary elaboration, 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.
Completeness2/5
Given 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 incomplete for a mutation tool. It lacks details on behavior, error handling, or return values, and doesn't compensate for the absence of structured data. For a tool that likely interacts with system input, more context is needed to understand its full operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'keyCode' documented as 'Key code to press down'. The description adds no additional meaning beyond this, such as examples of key codes or format details. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Press and hold a key' clearly states the action (press and hold) and the resource (a key), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'mqscript_keypress' (press) or 'mqscript_keyup' (release), which would require mentioning the 'hold' aspect more explicitly to distinguish it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'mqscript_keypress' or 'mqscript_keyup'. It lacks context about scenarios requiring key holding (e.g., for sustained input or in combination with other actions), leaving usage unclear relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action but omits critical behavioral details: whether it returns an integer, handles null/empty strings, has side effects, requires specific permissions, or includes error handling. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words, front-loading the core purpose ('Get length of a string'). It is appropriately sized for a simple function and avoids unnecessary elaboration, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool with parameters. It does not explain return values (e.g., integer length), error conditions, or behavioral nuances, leaving the agent with insufficient context to use it reliably beyond basic inference from the name and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for both parameters ('text' as the input string and 'resultVariable' as the output storage). The description adds no additional semantic context beyond what the schema provides, such as examples or edge cases, so it meets the baseline for adequate but unenhanced parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get length of a string' clearly states the verb ('Get length') and resource ('a string'), making the purpose immediately understandable. However, it does not differentiate from siblings like 'mqscript_instr' (which finds substrings) or 'mqscript_ubound' (which gets array bounds), leaving room for confusion in a crowded namespace of string/array functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'mqscript_instr' for substring operations or 'mqscript_ubound' for array dimensions, the description lacks context on appropriate use cases, prerequisites, or comparisons, 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 of behavioral disclosure. 'Get current call state' implies a read-only operation, but it doesn't specify what 'call state' includes (e.g., ringing, active, ended), whether it requires permissions, or how it handles errors. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Get current call state' is extremely concise—just three words—and front-loaded with the core action. There's no wasted language or redundancy, making it easy to parse quickly. Every word earns its place by directly conveying the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (involving phone state retrieval) and lack of annotations and output schema, the description is incomplete. It doesn't explain what the call state entails, possible return values, or error conditions. For a tool that interacts with device functionality, more context is needed to ensure proper usage without relying on guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with one parameter 'resultVariable' clearly documented as storing the call state. The description doesn't add extra parameter details, but since schema coverage is high and there's only one optional parameter, the baseline is strong. The description implies the tool retrieves call state without needing input parameters, which aligns with the schema's optional nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get current call state' clearly states the verb ('Get') and resource ('current call state'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'mqscript_phone_call' or 'mqscript_phone_sendsms', which are related phone operations but serve different functions. The description is specific enough to understand what it does but lacks sibling 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing an active call, or compare it to other phone-related tools like 'mqscript_phone_call' for making calls. Without this context, an agent might struggle to select this tool appropriately in scenarios involving phone operations.
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. While 'Replace' implies a mutation operation, the description doesn't clarify whether this modifies the original string or returns a new one, what happens on errors (e.g., if searchText isn't found), or any performance considerations. It lacks critical context 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/5
Is 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 action ('Replace occurrences of substring'), making it easy to scan and understand immediately. Every word earns its place by directly conveying the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a string manipulation tool with mutation implications and no annotations or output schema, the description is incomplete. It doesn't address return values (e.g., whether it returns the modified string or stores it in a variable), error handling, or how it interacts with sibling string tools. For a 5-parameter tool with behavioral nuances, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters well-documented in the schema itself (e.g., 'count' as number of replacements, 'resultVariable' for storing results). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for high schema coverage without adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Replace' and the resource 'occurrences of substring with new text', making the purpose immediately understandable. It doesn't specifically differentiate from sibling tools like 'mqscript_instr' (which searches for substrings) or 'mqscript_join' (which concatenates strings), but the core function is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling string manipulation tools like 'mqscript_left', 'mqscript_right', 'mqscript_mid', or 'mqscript_join', nor does it specify use cases or prerequisites. The agent must infer usage from the name and parameters 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. 'Display a message dialog' implies a UI interaction but lacks details on dialog type (e.g., modal, duration), user interaction (e.g., blocking vs. non-blocking), platform-specific behavior, or error handling. This is a significant gap for a tool with potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Display a message dialog') with zero wasted words, making it easy to parse and front-loaded with the core action. It earns its place by succinctly conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a UI-interaction tool. It doesn't cover behavioral aspects like dialog behavior, response handling, or error cases, which are crucial for an agent to use it effectively in a script automation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'message' clearly documented in the schema as 'Message to display'. The description adds no additional semantic context beyond this, such as message length limits, formatting options, or localization considerations. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Display a message dialog' clearly states the tool's function with a specific verb ('Display') and resource ('message dialog'), making the purpose immediately understandable. It doesn't explicitly distinguish from siblings like 'mqscript_traceprint' (which might log rather than show a dialog) or 'mqscript_inputtext' (which might prompt for input), but the core action is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like user notifications, debugging pop-ups, or how it differs from sibling tools such as 'mqscript_traceprint' (for logging) or 'mqscript_inputtext' (for input dialogs), 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 the full burden of behavioral disclosure. It states the basic action but lacks details on error handling (e.g., what happens with empty strings or invalid delimiters), performance implications, or output format (e.g., array structure). This is inadequate for a tool with mutation-like behavior (splitting implies transformation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action ('split string into array') and specifies the method ('using delimiter'), 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/5
Given 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 incomplete. It doesn't explain the output format (e.g., type of array, handling of edge cases), error conditions, or how it fits within the broader MQScript context (e.g., scripting environment implications). For a tool with potential side effects in a scripting system, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all three parameters. The description adds no additional semantic context beyond implying 'text' is split by 'delimiter' into an 'array', which is already covered by the schema. This 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('split') and resource ('string'), and specifies the output ('array using delimiter'). However, it doesn't explicitly differentiate from sibling tools like 'mqscript_join' (which likely does the opposite) or 'mqscript_instr' (which might search within strings), missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'mqscript_join' for the reverse operation or 'mqscript_instr' for string searching, nor does it specify prerequisites or context for splitting strings, leaving usage unclear.
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 'specified duration', which hints at timing control, but fails to describe critical behaviors such as whether this simulates a touchscreen gesture, requires device interaction permissions, has side effects (e.g., triggering UI events), or what happens on failure. For a tool with no annotations, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Swipe') and key details. There is no wasted verbiage or redundancy, making it easy to parse and understand quickly. Every word earns its place in conveying the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a UI interaction tool with no annotations and no output schema, the description is insufficient. It doesn't explain the return value (e.g., success/failure status), error conditions, or behavioral nuances like coordinate systems (e.g., screen pixels). For a tool that likely involves device control, more context is needed to ensure proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all parameters (x1, y1, x2, y2, duration) with their types and purposes. The description adds minimal value beyond this, only implying that parameters define start/end points and duration for the swipe. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Swipe') and the resource ('from one point to another'), specifying the verb and target. It distinguishes from siblings like 'tap' or 'touch' by indicating a directional movement between coordinates. However, it doesn't explicitly differentiate from other motion-related tools if any exist in the sibling list, which is why it's not 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'tap', 'touch', or other UI interaction tools in the sibling list. It lacks context about typical scenarios (e.g., for scrolling, dragging) or prerequisites, leaving the agent to infer usage based on the action 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. 'Set environment variable' implies a mutation operation, but it doesn't specify whether this affects the current session only, is persistent, requires specific permissions, or has side effects. The description lacks details on error handling, scope (e.g., process-level), or any behavioral traits beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, making it front-loaded and zero-waste. It efficiently conveys the core action without unnecessary elaboration. Every word earns its place, though this brevity may contribute to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It doesn't explain what happens after setting the variable (e.g., return values, success indicators), potential errors, or usage context. For a tool that modifies system state, more detail is needed to ensure safe and correct invocation by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter names and descriptions ('varName' and 'value'). The description doesn't add any semantic details beyond what the schema provides, such as examples or constraints (e.g., valid variable names). Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set environment variable' clearly states the action (set) and resource (environment variable), making the purpose immediately understandable. It distinguishes from sibling tools like 'mqscript_sys_getenv' (get vs. set), though it doesn't explicitly mention this distinction. The description is specific but could be more detailed about scope or persistence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing appropriate permissions), when it's appropriate (e.g., for script configuration), or contrast with siblings like 'mqscript_sys_getenv' for retrieval. Usage is implied by the verb 'set,' but explicit context is missing.
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. 'Execute system shell command' implies a potentially powerful and risky operation, but the description doesn't mention security implications, permission requirements, side effects, or what happens when waitForCompletion is false. This leaves significant behavioral gaps for a tool that interacts with the system shell.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, front-loading the essential information with zero wasted words. Every word earns its place by specifying the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a system shell execution tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns, error conditions, security implications, or how it differs from other system tools. Given the complexity and risk of shell execution, more context is needed 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so all parameters are documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema descriptions, meeting the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Execute') and resource ('system shell command'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like mqscript_sys_getenv or mqscript_sys_setenv, which are also system-related but perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, security considerations, or comparison to other system tools in the sibling list, leaving the agent with no contextual usage information.
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 ('Sleep') but doesn't cover critical traits like whether it blocks execution, has side effects, requires permissions, or handles errors. For a tool that likely pauses execution, this omission is significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple tool, making it easy to parse without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It lacks behavioral context (e.g., execution blocking, error handling) and usage guidelines, which are essential for an agent to invoke it correctly in a scripting environment with many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'milliseconds' parameter fully documented. The description adds no additional meaning beyond the schema, such as context on valid ranges or units. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Sleep for specified duration' clearly states the verb ('Sleep') and the resource ('duration'), making the purpose immediately understandable. However, it doesn't distinguish this from sibling tools like 'mqscript_delay', which likely serves a similar timing function, so it misses full sibling 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'mqscript_delay' or other timing-related siblings. It lacks context about use cases, prerequisites, or exclusions, leaving the agent without explicit or implied usage instructions.
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 mentions 'Hold touch on screen' but doesn't specify what 'hold' entails (e.g., continuous press), potential side effects (e.g., UI interactions, app responses), or system requirements. This is inadequate for a tool that likely interacts with device input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded and wastes no space, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a screen interaction tool with no annotations and no output schema, the description is insufficient. It lacks details on behavior, error conditions, or what happens after the touch (e.g., does it return success/failure?). More context is needed 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for 'duration', 'x', and 'y' parameters. The description adds no additional meaning beyond the schema, such as coordinate system details or duration constraints. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Hold touch') and the resource ('on screen'), specifying the duration aspect. It distinguishes from sibling tools like 'mqscript_tap' (brief touch) and 'mqscript_swipe' (movement), though not explicitly named. However, it doesn't fully differentiate from all siblings (e.g., 'mqscript_element_click'), keeping it at 4 rather than 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'mqscript_tap' or 'mqscript_swipe'. The description only states what it does, not the context or prerequisites for its use, leaving the agent to infer based on tool names 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 full burden for behavioral disclosure. 'Add a checkbox control' implies a UI mutation operation, but it doesn't specify whether this requires specific permissions, how the checkbox integrates with existing UI elements, what happens on errors, or any rate limits. The description lacks essential context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's perfectly 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a UI mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., success/failure, control reference), how errors are handled, or integration requirements with other UI tools. The context signals indicate this is a non-trivial operation that needs more behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('a checkbox control'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar UI control tools like 'mqscript_ui_addedittext' or 'mqscript_fw_addbutton', which would require mentioning it's specifically for boolean input controls in a UI 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., requiring a UI layout context), comparison with other UI controls, or typical use cases for checkbox controls versus other input methods.
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 'Create' implying a mutation, but doesn't disclose behavioral traits like permissions needed, side effects, or what the new layout entails (e.g., if it's persistent, requires other UI tools to function). This is a significant gap 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, making it easy to parse without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation to create UI layouts), lack of annotations, no output schema, and many sibling UI tools, the description is incomplete. It doesn't explain return values, integration with other UI tools, or behavioral context, leaving significant gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'orientation' well-documented in the schema (including enum values and default). The description adds no parameter information beyond what the schema provides, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new UI layout'), making the purpose understandable. However, it doesn't differentiate from sibling UI tools like 'mqscript_ui_newrow' or 'mqscript_fw_create', which might also create UI elements, so it lacks sibling distinction for 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools for UI operations (e.g., 'mqscript_ui_newrow', 'mqscript_fw_create'), the description offers no context, prerequisites, or exclusions, leaving usage unclear.
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 ('Start a new row') but doesn't explain what happens (e.g., does it add to an existing layout, require specific permissions, have side effects, or return a value?). For a UI manipulation tool with zero annotation coverage, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action, making it easy to parse quickly. Every word earns its place by conveying the essential purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of UI manipulation and the lack of annotations and output schema, the description is insufficient. It doesn't explain the outcome (e.g., what 'starting a new row' returns or affects), prerequisites, or how it integrates with other UI tools. For a tool in this context, more detail is needed to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description doesn't add parameter information, which is appropriate here. Baseline is 4 for zero parameters, as there's nothing to compensate for, and the description doesn't mislead about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Start a new row in layout' clearly states the action (start) and target (row in layout), but it's somewhat vague about what 'layout' refers to and doesn't differentiate from sibling tools like 'mqscript_ui_newlayout' or other UI-related tools. It avoids tautology by not just repeating the name, but lacks specificity about the context or system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing layout), exclusions, or related tools like 'mqscript_ui_newlayout' for creating layouts first. It leaves usage entirely to inference from the name and 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. While 'Set enabled state' implies a mutation operation, it doesn't disclose important behavioral aspects: whether this requires specific permissions, what happens to the UI when disabled (e.g., graying out vs hiding), if changes are immediate or batched, or potential side effects on other controls. The description is minimal and lacks crucial context for safe 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise - a single sentence with zero wasted words. It's front-loaded with the core purpose and contains no unnecessary information. Every word earns its place in this minimal but complete statement of function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after setting the enabled state, what errors might occur, how to identify valid control IDs, or the visual/functional implications of enabling/disabling. The combination of mutation operation with minimal description creates significant gaps for an agent trying to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('id' and 'enabled') clearly documented in the schema. The description doesn't add any meaningful parameter semantics beyond what the schema already provides - it doesn't explain what constitutes a valid 'Control ID' or what 'enabled' state means in practice. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set enabled state') and target ('UI control'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'mqscript_ui_setvisible' which also modifies UI control states, leaving room for confusion about when to use one versus the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'mqscript_ui_setvisible' that also modify UI control properties, there's no indication of when enabling/disabling is appropriate versus showing/hiding or other UI manipulation methods.
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 'Create' but doesn't disclose what this creation entails—whether it generates code, modifies state, requires specific permissions, or has side effects. For a tool with no annotations, this leaves critical 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/5
Is 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 and directly states the tool's purpose without unnecessary elaboration, 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/5
Given 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 incomplete. It doesn't explain what the tool returns (e.g., generated code, success status) or behavioral aspects like error handling. For a tool that likely creates programming constructs, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for 'condition' and 'body' parameters. The description doesn't add any meaning beyond what the schema provides (e.g., syntax examples or usage context), so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a While loop structure' clearly states the verb ('Create') and resource ('While loop structure'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'mqscript_for' (a For loop tool), which would require explicit differentiation for 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'mqscript_for' or 'mqscript_if'. There's no mention of prerequisites, typical use cases, or comparison with sibling tools, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 tool 'Get[s] current date and time,' implying a read-only operation, but does not specify whether it returns a string, object, or other format, nor does it mention any side effects, permissions, or performance considerations. For a tool with no 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence ('Get current date and time') that is front-loaded and wastes no words. It directly conveys the core purpose without unnecessary elaboration, making it highly concise and well-structured for its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no annotations, no output schema, but 100% schema coverage), the description is minimally adequate. It states what the tool does but lacks details on output format, error handling, or integration with sibling tools. Without an output schema, the description should ideally hint at the return type, but it does not, leaving some contextual gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('format' and 'resultVariable'). The description does not add any meaning beyond what the schema provides—it does not explain parameter usage, default values, or examples. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter semantics without extra description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get current date and time' clearly states the tool's function with a specific verb ('Get') and resource ('current date and time'). It distinguishes from siblings like 'mqscript_datetime_adddays' or 'mqscript_datetime_format' by focusing on the current moment rather than manipulation or formatting of existing dates. However, it doesn't explicitly mention the optional formatting parameter, which slightly limits 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention sibling tools like 'mqscript_sys_gettime' (which might serve a similar purpose) or clarify scenarios where this tool is preferred over others. There is no context about prerequisites, dependencies, or typical use cases.
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. 'Set screen brightness' implies a mutation operation, but it lacks details on permissions required, whether changes persist, error conditions (e.g., invalid brightness), or system impact (e.g., battery usage). This leaves significant gaps for an agent to understand 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It is front-loaded with the core action ('Set screen brightness'), 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation tool with no annotations or output schema, the description is minimally adequate. It states the purpose clearly but lacks behavioral context (e.g., side effects, errors) and usage guidelines. Given the simplicity of the tool, it's functional but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'brightness' parameter fully documented (range 0-255). The description adds no additional parameter semantics beyond what the schema provides, such as typical values or effects at extremes. This meets 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set screen brightness' clearly states the verb ('Set') and resource ('screen brightness'), making the tool's purpose immediately understandable. It distinguishes from siblings like 'mqscript_device_getinfo' (read) and 'mqscript_device_setvolume' (different setting), though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the context implies it's for adjusting screen brightness, there's no mention of prerequisites (e.g., device permissions), side effects, or comparison to similar tools like 'mqscript_dim' (which might adjust brightness in a different 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 the full burden of behavioral disclosure. While it states what the tool does, it doesn't describe important behavioral aspects: whether this modifies the original array, what happens with empty arrays, how errors are handled, or what format the result takes. For a transformation 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise at 6 words, front-loading the core functionality with zero wasted words. Every element ('Join', 'array elements', 'into string', 'using delimiter') contributes essential understanding. This is an excellent example of efficiency in technical documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple transformation nature of this tool and 100% schema coverage, the description is minimally adequate. However, with no output schema and no annotations, the description should ideally mention what the tool returns (presumably the joined string stored in resultVariable) or any side effects. For a tool with three parameters and no structured output documentation, the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'using delimiter' which aligns with one parameter, but doesn't add meaningful semantics beyond what the 100% schema coverage already provides. The schema thoroughly documents all three parameters (arrayName, delimiter, resultVariable) with descriptions and defaults. The description adds no additional context about parameter usage, constraints, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Join') and resource ('array elements into string'), making the purpose immediately understandable. It distinguishes from sibling tools like 'mqscript_split' (which does the opposite operation) by specifying the direction of transformation. However, it doesn't explicitly mention the sibling relationship or contrast with other array/string manipulation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While the purpose is clear, there's no mention of when this is appropriate versus other string manipulation tools (like 'mqscript_concat' if it existed) or array processing tools. The agent must infer usage from the tool name and description 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 ('Convert string to lowercase') but lacks behavioral details such as error handling (e.g., for non-string inputs), performance characteristics, or side effects. The description is minimal and does not disclose operational traits beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste. It is front-loaded and efficiently conveys the core purpose without unnecessary elaboration, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (simple string transformation), 100% schema coverage, and no output schema, the description is minimally adequate. However, it lacks context on error handling or integration with sibling tools, which could enhance completeness for an AI agent. It meets basic requirements but has room for improvement in operational guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('text' and 'resultVariable') fully documented in the schema. The description adds no additional meaning beyond the schema, such as examples or constraints. Baseline score of 3 is appropriate as the schema handles parameter documentation effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Convert') and resource ('string'), specifying the transformation to lowercase. It distinguishes from sibling 'mqscript_ucase' (uppercase conversion) by implication, though not explicitly named. However, it lacks explicit differentiation from other string manipulation tools like 'mqscript_replace' or 'mqscript_join'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention sibling tools, prerequisites, or specific contexts for application. Usage is implied only by the tool's name and description, with no explicit when/when-not statements.
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 for behavioral disclosure. It states what the tool does but doesn't describe important behavioral aspects: what happens if 'count' exceeds string length (truncation, error, or padding?), whether the operation is read-only or modifies state, what format the result takes, or if there are any side effects. The description is minimal and lacks 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that states the tool's purpose without unnecessary words. It's appropriately sized for a simple string manipulation function and is front-loaded with the essential information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple string extraction tool with 100% schema coverage but no annotations or output schema, the description is minimally adequate. It tells what the tool does but lacks important context about behavior, error handling, and relationship to sibling tools. The absence of output schema means the description should ideally mention what gets returned, but it doesn't.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description mentions 'specified number of characters' which aligns with the 'count' parameter and 'string' which aligns with 'text', but adds no additional semantic context beyond what the schema already provides. With complete schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get specified number of characters from left side of string'. It uses a specific verb ('Get') and identifies the resource ('characters from left side of string'). However, it doesn't explicitly differentiate from its sibling 'mqscript_right' (which presumably gets characters from the right side), though the naming convention implies this distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'mqscript_right', 'mqscript_mid', or 'mqscript_instr' that might serve similar string manipulation purposes. There's no context about prerequisites, error conditions, or typical use cases.
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 tool's action but lacks details on side effects, error handling, or performance characteristics. For example, it doesn't specify what happens if 'count' exceeds the string length or if negative values are used, which are critical for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's function without any unnecessary words. It is front-loaded and efficiently communicates the core purpose, making it easy to parse and understand quickly. Every part of the description earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (simple string extraction), no annotations, and no output schema, the description is minimally adequate. It covers the basic action but lacks details on behavioral traits and usage context. For a tool with no structured safety or output information, more completeness would be beneficial, but it's not entirely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters are documented in the schema. The description adds no additional semantic details beyond what the schema provides (e.g., it doesn't explain edge cases or usage nuances). Thus, it meets the baseline of 3, as the schema adequately covers parameter meanings without extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get specified number of characters from right side of string.' It uses a specific verb ('Get') and resource ('characters from right side of string'), making the purpose unambiguous. However, it does not explicitly differentiate from its sibling 'mqscript_left', which likely extracts from the left side, leaving room for slight improvement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'mqscript_left' or 'mqscript_mid' for different string extraction needs, nor does it specify any prerequisites or contextual cues for usage. This lack of comparative or situational advice limits its effectiveness in guiding the agent.
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 calculation action but doesn't describe what happens after: whether the result is returned directly, stored in a variable (implied by the resultVariable parameter but not explained), or if there are side effects like errors for invalid inputs. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Calculate sine of an angle (in radians)'. It's front-loaded with the core purpose and includes essential context (units). There's no wasted verbiage, making it appropriately sized for this simple mathematical tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (a basic mathematical function), 100% schema coverage, and no output schema, the description is minimally complete. It states what the tool does but lacks behavioral details (e.g., error handling, return format) and usage guidelines. For a tool with no annotations, it should do more to compensate, but it's adequate for the simple context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for both parameters: 'angle' as 'Angle in radians' and 'resultVariable' as 'Variable name to store result'. The description adds no additional meaning beyond the schema, such as explaining the default for resultVariable or valid ranges for angle. With high schema coverage, the baseline is 3, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Calculate sine of an angle (in radians)'. It specifies the verb ('Calculate') and resource ('sine'), and distinguishes from siblings like mqscript_cos and mqscript_tan by naming the trigonometric function. However, it doesn't explicitly differentiate from all mathematical siblings (e.g., mqscript_sqr, mqscript_abs), so it's not a perfect 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools (e.g., mqscript_cos for cosine, mqscript_tan for tangent) or other mathematical functions, nor does it specify prerequisites or exclusions. Usage is implied from the function name alone, but no explicit context is given.
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 ('calculate square root') but does not mention potential side effects (e.g., if it modifies state or requires permissions), error handling (e.g., for invalid inputs like negative numbers), or performance aspects (e.g., computational limits). This leaves significant gaps in understanding the tool's behavior beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words or fluff. It is front-loaded and appropriately sized for a simple mathematical function, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (a basic mathematical operation) and the absence of annotations and output schema, the description is minimally adequate but lacks depth. It covers the core purpose but does not address behavioral aspects like error handling or usage context, which would be beneficial for a tool with no structured safety or output information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('number' and 'resultVariable'), so the schema does the heavy lifting. The description does not add any additional semantic details beyond what the schema provides, such as explaining the range or constraints for 'number' (e.g., non-negative values) or the purpose of 'resultVariable'. This 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Calculate square root of a number' clearly states the tool's function with a specific verb ('calculate') and resource ('square root'), making the purpose immediately understandable. However, it does not explicitly differentiate from sibling tools like 'mqscript_abs' or 'mqscript_sin', which perform other mathematical operations, leaving some ambiguity in distinguishing its specific role within the family of mathematical functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as other mathematical functions in the sibling list (e.g., 'mqscript_abs' for absolute value or 'mqscript_sin' for sine). It lacks context about prerequisites, error conditions (e.g., handling negative numbers), or comparisons to similar tools, leaving the agent without 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 of behavioral disclosure. It states the tool gets the current system time but doesn't explain what 'system time' entails (e.g., timezone, precision), whether it's a read-only operation, or how errors might occur. This leaves gaps in understanding the tool's behavior beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, clear sentence ('Get current system time') that front-loads the essential action and resource. There is no wasted verbiage, making it 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (simple time retrieval with two optional parameters) and high schema coverage, the description is minimally adequate. However, with no output schema and no annotations, it lacks details on return values (e.g., format of the time string) and behavioral context, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, fully documenting both parameters ('format' and 'resultVariable') with their purposes and defaults. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for adequate coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('current system time'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'mqscript_datetime_now' or 'mqscript_datetime_format', which appear related to time/date operations, leaving some ambiguity about when to choose this tool over those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'mqscript_datetime_now' and 'mqscript_datetime_format' that seem related to time operations, the agent lacks explicit instructions on selection criteria, such as format customization or system-specific vs. datetime-specific contexts.
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 calculation action but doesn't describe what happens after calculation (e.g., where the result is stored, if there are error conditions for invalid inputs, or performance characteristics). For a mathematical tool with potential edge cases (like undefined values at certain angles), 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function with zero wasted words. It's appropriately sized for a simple mathematical operation and front-loads the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mathematical calculation tool with 100% schema coverage but no output schema and no annotations, the description is minimally adequate. It covers the basic operation but lacks information about return values, error handling, or mathematical constraints that would be helpful for an agent to use it correctly in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents both parameters (angle and resultVariable). The description mentions 'angle in radians' which aligns with the schema but adds no additional semantic context beyond what's already in the structured data. This 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Calculate tangent of an angle (in radians)', which includes a specific verb ('Calculate') and resource ('tangent of an angle'). It distinguishes from sibling tools like mqscript_sin and mqscript_cos by specifying the trigonometric function, but doesn't explicitly differentiate from other mathematical operations in the sibling list beyond the function name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for use, or comparisons to similar tools like mqscript_sin or mqscript_cos, leaving the agent to infer usage solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Short tap once' which clarifies the action type, but lacks details on permissions needed, screen state requirements, error conditions, or what happens after tapping (e.g., UI response). For a mutation 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and efficient: two concise sentences with zero waste. The first sentence states the core action, and the second clarifies it's a short tap, earning its place by adding behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with full schema coverage and no output schema, the description adequately covers the basic action but lacks context for a mutation tool. It doesn't explain side effects, success indicators, or error handling, leaving gaps in completeness for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema. The description adds no additional meaning beyond implying coordinates are for screen tapping, which is already evident from the schema. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Tap on screen at specified coordinates' with the verb 'tap' and resource 'screen'. It distinguishes from siblings like 'swipe' or 'touch' by specifying a short tap action, though it doesn't explicitly contrast with similar tools like 'element_click'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or compare it to siblings like 'element_click' (which might tap UI elements) or 'touch' (which might handle different touch interactions).
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 the basic operation. It doesn't disclose behavioral traits such as error handling (e.g., for non-string inputs), performance implications, side effects, or output format. The description is minimal and lacks context beyond the core function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and directly states the tool's function without unnecessary elaboration, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (simple string transformation), 100% schema coverage, and no output schema, the description is adequate but minimal. It covers the basic purpose but lacks context on usage, behavior, and sibling differentiation, which could help an agent use it more effectively in a broader scripting environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters ('text' and 'resultVariable'). The description doesn't add any semantic details beyond what's in the schema (e.g., it doesn't explain character encoding or locale considerations for uppercase conversion). Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Convert string to uppercase' clearly states the verb ('convert') and resource ('string'), making the purpose immediately understandable. However, it doesn't differentiate from its sibling 'mqscript_lcase' (lowercase conversion) beyond the obvious direction, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'mqscript_lcase' or other string manipulation tools (e.g., 'mqscript_replace', 'mqscript_join'). There's no mention of prerequisites, typical use cases, or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the calculation but fails to describe key behaviors such as error handling for invalid inputs, precision of results, or side effects like storing results in a variable. This leaves significant gaps for a tool that performs mathematical operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mathematical tool with no annotations and no output schema, the description is insufficient. It lacks details on return values (e.g., numeric result format), error conditions, or usage examples, leaving the agent with incomplete information to invoke the tool effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters ('angle' and 'resultVariable'). The description adds no additional semantic context beyond what the schema provides, such as valid ranges for the angle or implications of the resultVariable. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Calculate cosine') and the resource ('an angle in radians'), distinguishing it from siblings like mqscript_sin and mqscript_tan by specifying the trigonometric function. It provides a precise verb+resource combination without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like mqscript_sin or mqscript_tan, nor does it mention any prerequisites or context for usage. It simply states what the tool does without indicating appropriate 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but lacks details on behavioral traits such as whether the operation is deterministic, has side effects, requires permissions, or how errors are handled. For a tool with no annotation coverage, 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/5
Is 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 unnecessary words. It is front-loaded with the core functionality, making it easy to parse and understand quickly, which is ideal for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (simple random number generation), no annotations, no output schema, and high schema coverage, the description is adequate but minimal. It covers the basic purpose but lacks completeness in usage guidelines and behavioral transparency, which are important for effective tool invocation in a broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for both parameters ('max' as 'Maximum value (exclusive)' and 'resultVariable' as 'Variable name to store result'). The description adds minimal value beyond the schema by implying the range starts at 0, but it does not provide additional syntax, format details, or examples. This meets the baseline of 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Generate random number') and the resource/scope ('between 0 and specified maximum'), making the purpose immediately understandable. It distinguishes itself from sibling tools by focusing on random number generation, which is unique among the listed tools that perform various mathematical, UI, system, and string operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context for use, or comparisons to other tools (e.g., mathematical functions like 'mqscript_sin' or 'mqscript_cos'), leaving the agent to infer usage based solely on the purpose.
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:

[![MQScript_MCP MCP server](https://glama.ai/mcp/servers/allegiant/MQScript_MCP/badges/card.svg)](https://glama.ai/mcp/servers/allegiant/MQScript_MCP)

Score Badge

Copy to your README.md:

[![MQScript_MCP MCP server](https://glama.ai/mcp/servers/allegiant/MQScript_MCP/badges/score.svg)](https://glama.ai/mcp/servers/allegiant/MQScript_MCP)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/allegiant/MQScript_MCP'

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