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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and non-destructive, so the safety profile is covered. The description adds real context the annotations cannot: these are "typical rules of thumb" and "the manufacturer's own guidelines override them," which tells the agent how much authority to grant the output.

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 dense paragraph that front-loads the resource, then the payload inventory, then the override caveat, then the omit-process behavior. Every sentence carries weight; only the tail of the process list is mildly padded.

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, the description takes on the burden of describing returns and does so concretely (tolerances, file formats, rules plus reasons, pre-RFQ checklist, common mistakes), while also covering the optional-parameter behavior and the trust caveat. Nothing needed to invoke or interpret the call is missing.

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 0%, but the single enum parameter is self-explanatory and the description supplies the semantics that matter: it clarifies that process selects one manufacturing process, gives common examples (sheet metal, CNC machining, injection molding), and defines the omitted case as "list all." That covers the optionality behavior the enum alone does not.

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 resource (design-for-manufacturing rules for one process) and enumerates the payload an agent will get back (tolerances, file formats, rules with reasons, checklist, common mistakes). It reads clearly against lookups like get_playbook_step or check_design, though it never names a sibling to draw the boundary explicitly.

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?

"Omit process to list all" gives one concrete usage decision, which is genuinely useful for the single optional parameter. Beyond that there is no when-to-use/when-not guidance and no routing to check_design (which presumably consumes these rules), so the agent must infer the workflow context.

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