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

With no annotations provided, the description carries the behavioral burden, and it directly discloses the most important trait: 'This does not submit or spend money.' It also implies a safe, non-mutating normalization operation. It does not mention error behavior or idempotence, but the side-effect-free disclosure is substantial for an agent deciding whether to call it.

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?

Two sentences, with the core outcome front-loaded and no filler. Each sentence earns its place: the first defines the transformation target, the second covers side-effect safety and prerequisite routing.

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 description covers the essential context: what is normalized, the target contract, the safety profile, and the prerequisite tool to consult. An output schema exists, so omitting return-value detail is acceptable. The only gap is a more explicit statement of where the result should be consumed (e.g., passed to hydracept_invoke), though this is largely inferable from the contract name.

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 0%, so the description must compensate. It adds meaning by identifying the parameter as a 'LoRA picker selection' and instructing that only route-compatible entries should be selected. However, it does not describe the exact properties or shape of the adapter objects beyond pointing to the external contract, leaving the agent to infer the structure.

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 uses a specific verb and resource: 'Normalize a LoRA picker selection into the exact image.generate.v1 input.adapters contract.' This clearly states what the tool transforms and to what target, and the explicit 'does not submit or spend money' distinguishes it from submission/invocation tools among the siblings.

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 gives a clear usage context: call hydracept_model_adapters first and 'select only route-compatible entries.' It also states this is a preparation step rather than a submission, which implies it should precede hydracept_invoke or hydracept_run. It does not enumerate all alternative tools or list exclusion cases, so it stops short of a 5.

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