update_module

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

With no annotations, the description must carry the full behavioral burden, but it only states that an update occurs and lists parameters. It does not disclose whether the operation is a partial update, whether omitted optional fields are reset to null, what validation is performed, or what the response contains.

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 appropriately sized: one clear action sentence followed by a structured Args list. Each parameter line is short and directly useful, with no fluff or repetition of schema information beyond the parameter name itself.

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?

The parameter list is complete and an output schema exists, so return values are covered. However, the description does not explain update semantics such as whether only provided fields are changed, which is a notable gap for a mutation tool with no annotations.

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?

The Args block supplies per-parameter meaning that the schema lacks, such as identifying project_id and module_id as UUIDs and specifying the YYYY-MM-DD format for date fields. This compensates for the 0% schema description coverage, though some descriptions like 'Updated status' are thin.

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 opens with 'Update an existing module', a specific verb-resource pair that clearly indicates this tool modifies an existing module. This distinguishes it from sibling tools like create_module, delete_module, get_module, and the various update_* tools for other resources.

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 offers no guidance on when to use this tool versus alternatives such as create_module for new modules or delete_module for removal. No prerequisites, exclusions, or context are provided beyond the bare update action.

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