run_module

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden for behavioral disclosure. It only advises check mode first, but fails to mention that the tool can execute arbitrary Ansible modules with potentially destructive side effects, requires permissions, or what happens on failure. This is a significant transparency gap for a tool running arbitrary code.

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?

The description is two short sentences, front-loaded with the core purpose and a safety tip. Every word contributes to the message, and it is easily scannable. It is concise without unnecessary verbosity.

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?

Despite its conciseness, the description is severely incomplete for a tool with 9 parameters, no annotations, and no schema descriptions. It fails to explain how to use arguments, inventory, become, connection, or when this tool is appropriate versus run_playbook. The presence of an output schema does not compensate for the missing operational guidance.

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?

With schema description coverage at 0%, the description is expected to compensate for missing parameter explanations. It does not explain any of the 9 parameters beyond implicitly referring to module and check_mode. Args, hosts, become, timeout, inventory, connection, and become_user are left entirely to the schema, which lacks descriptions. The description adds no meaningful semantic value.

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 clearly states the verb 'Run' and the resource 'Ansible module via local ansible CLI', distinguishing it from sibling tools like run_playbook. It is specific and unambiguous, making the tool's primary function immediately clear.

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 includes a usage tip to prefer check_mode=true, which is helpful, but it lacks explicit guidance on when to use this tool versus alternatives like run_playbook. The context of running a single module is implied but no exclusions or alternative suggestions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.