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

With no annotations, the description carries the behavioral disclosure burden. It adds meaningful caveats: tariff targets are observed rates, origins are statistically associated not causal, and unsupported/dependent/conflicting fields return invalid params. Missing rate-limit or authentication detail, but the interpretive caveats exceed the baseline for a fetch tool.

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 sentences each earn their place: purpose, interpretive caveat, and schema-guidance plus a working example. It is front-loaded and efficient. The only issue is the second sentence is dense and slightly jargony, which is a minor readability cost.

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?

Complexity is high – ten parameters, a large oneOf switch over many index constants, and no output schema. The description points to schema branches and gives a concrete example, but it does not enumerate the available indexes, explain result shapes, or guide selection among overlapping artifact types. Without an output schema, this leaves the agent to infer a lot from the input branches alone.

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 100%, so the baseline is 3. The description adds value by telling agents to consult the selected branch of the schema for accepted fields, offering a concrete runnable example (get_state_cost_index plus Ohio filter), and clarifying the tariff/origin semantic distinction – guidance that the parameter descriptors alone do not provide.

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?

Opens with 'Fetch a published MFG Calcs index...' – a specific verb plus a clear list of artifact types it can return. It communicates the tool's broad fetch-and-dispatch role, though it doesn't explicitly distinguish itself from sibling tools like get_revisions and get_vintages that overlap in the 'vintage' and 'revision record' categories.

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?

No when-to-use vs alternatives guidance is provided. It never tells the agent when to prefer get_index over get_revisions, get_vintages, or lookup_tariff even though those are plausible competitors. The 'Try:' example and schema-branch advice address parameter usage, not tool selection.

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