Validate Chilean RUTs for individuals or legal entities using the official Modulo 11 algorithm and return the canonical, correctly formatted identifier.
Valida un RUT chileno de persona natural o jurídica usando el algoritmo oficial Módulo 11 y entrega su formato canónico.
| Name | Required | Description | Default |
|---|---|---|---|
| rut | Yes | RUT chileno a validar (con o sin puntos/guion) |
Changes observed during successful MCP inspections.
v1.5.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It usefully discloses the validation method (Módulo 11) and that it returns a canonical format, which implies a stateless, read-only operation. But it omits critical behavior: what happens with an invalid RUT (error vs. boolean false) and the exact shape of the returned value.
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?
One well-formed sentence with the action, resource, method, and output front-loaded and no filler. Nothing redundant or wasteful.
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?
For a simple one-parameter validation utility with no annotations and no output schema, the description adequately covers purpose, method, and the fact that it produces a canonical format. It falls just short of complete because the return value and invalid-input behavior remain unspecified.
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 description coverage is 100% with a single parameter, so the schema already explains that the RUT is accepted with or without dots/dashes. The description adds only slight context by noting persona natural o jurídica, which is not a parameter detail, so baseline 3 applies.
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?
The description states a specific verb (valida) and resource (RUT chileno de persona natural o jurídica), and even names the mechanism used (algoritmo oficial Módulo 11). This makes it unmistakable among the sibling tools, none of which touch RUT validation.
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?
Usage is implicit in the purpose — an agent can infer this is the tool to call when it needs to check or normalize a Chilean RUT. However, there is no explicit when-to-use framing, no prerequisites, and no mention of related alternatives or follow-up tools in the suite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.