mod_build

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

Although annotations are absent, the description goes beyond a simple call to action. It discloses that it runs mod_lint first, that failure to lint blocks the build, that running lint is cheap, and that skipping lint can mask real defects (the example of a modded class that loads and reports success). This is rich behavioral context that an agent needs to know.

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 slightly verbose with the runtime-cost rationale, but the first sentence is sharp and the extra lines about skip_lint earn their place by explaining a non-obvious parameter. It is well-structured with the main purpose first.

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 a single boolean parameter and an output schema, the description covers what the tool does, what it returns, when to skip lint, and the safety/correctness rationale. It's complete for an agent to decide when to call it and what to expect.

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 schema provides only a boolean with a default and title, but 0% description coverage means the description must explain it. It does: skip_lint is introduced and its purpose/rationale are clearly described. Could add a touch more about consequences (e.g., potential build failure), but the current explanation is sufficient.

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 a specific verb+resource ('Pack this project's mods') and states the return value ('Returns a job_id'). It clearly distinguishes this from sibling tools by describing the lint-first behavior, which no other tool describes. The purpose is unmistakable.

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 explicitly explains when to use skip_lint and why: skip_lint packs anyway, and the rationale ('a refusal that cannot be overridden is a refusal that gets worked around') provides clear guidance on when to override. It also implies normal usage (use without skip_lint) and the alternative of fixing lint errors first.

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