Writes RAPID module text to an ABB controller via RWS with automatic mastership, validating syntax before upload to prevent invalid code from reaching the controller.
Write RAPID module text via RWS (auto-mastership). Validates RAPID syntax before upload.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| task | Yes | ||
| module | Yes | ||
| skipValidation | No | Skip RAPID syntax validation (default: false) |
Changes observed during successful MCP inspections.
v3.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two genuinely useful traits: mastership is acquired automatically and RAPID syntax is validated before upload (which explains the skipValidation parameter). It omits other important behavior for a write operation - whether an existing module is overwritten, whether the module must be unloaded first, and what controller state is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler; the mechanism and the validation step are stated immediately. It is arguably too terse rather than too long, and the shift from "write" to "upload" introduces a minor terminology wobble.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive mutation tool with no annotations, no output schema, and 25% parameter coverage, so the description should explain overwrite semantics, error/validation-failure behavior, and return expectations. It covers none of these, leaving the agent under-informed before performing a controller write.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% - only skipValidation has a description. The description implies that "code" holds RAPID module text and that validation applies to it, but says nothing about what "task" and "module" identify (task name? module name? must the module already exist?), so the three required parameters remain semantically undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Write RAPID module text via RWS") plus the mechanism, so the action is unambiguous. It does not differentiate itself from the near-identical sibling rs_write_module, leaving the agent to infer the difference between the rs_ and rws_ families.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance, no prerequisites, and no exclusions. With a sibling literally named rs_write_module, the absence of any routing rule (which API family to prefer, when validation matters) is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.