Create a new mod module

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

Annotations declare this is a write (readOnlyHint=false) but non-destructive. The description adds real value beyond that: the concrete file layout it generates, that dependencies default to the installed official modules, and the default target folder. It does not state behavior when a folder already exists (overwrite vs. error), which is a notable gap.

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?

Three dense but well-front-loaded sentences; the primary action and default location lead, and each clause carries concrete technical detail without filler.

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?

With no output schema and a mutation tool, the description is nearly sufficient: it explains what is created and where. Missing only the return value and the collision/overwrite behavior, which an agent would want before invoking it.

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 100%, so all seven parameters are already documented, setting the baseline at 3. The description adds some meaning for with_csharp by describing the generated csproj/SubModule.cs and bin output, but does not clarify the dependencies syntax or other parameters beyond the schema.

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 ('Scaffolds') and resource ('a new module folder') and enumerates exactly what is produced: SubModule.xml with dependencies, ModuleData/, and an optional C# project. This clearly separates it from read-only siblings like module_info or list_modules.

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 implied by the name and the scaffolding detail, but there is no explicit when-to-use, no prerequisites (e.g. game install path requirement), and no routing to alternatives such as clone_object for duplicating an existing module. Adequate but gaps remain.

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