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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral context beyond that: the result set is deliberately capped at 15 commodities with monthly trade data, and it discloses the boundary condition that the website supply models cover 65 minerals while patent questions leave this tool entirely. It does not cover pagination or error behavior, but neither applies meaningfully to a fixed 15-item enumeration.

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 usage trigger and routing guidance are front-loaded before the enumeration, which is the right ordering. The parenthetical commodity list is long but earns its place because callers must pass subsequent tools a commodity name, and this is the authoritative source of valid names. Slightly heavy for a single-tool read, hence 4 rather than 5.

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?

An output schema exists, so return values need no prose, yet the description still tells the agent what the payload will contain and how it is grouped (primary mined/refined vs secondary scrap/recycled, plus HS codes). Combined with the explicit scope boundaries against the supply models and CM-PATRA tools, an agent has everything needed to call this correctly and interpret the result.

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 tool takes zero parameters, so per the rubric the baseline is 4. The description sensibly spends no effort on parameter syntax and instead uses the space for scope and routing context.

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 and resource (lists the 15 tracked commodities) and enumerates exactly what the list contains, including the primary/secondary split and HS codes. It explicitly demarcates its own scope from siblings: 'these 15 are the scope of the trade, risk and sourcing tools', with patents routed to CM-PATRA and 65 minerals belonging to the website models.

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?

Gives an explicit trigger ('when the user asks which critical minerals... MiningBridge covers') and an explicit pre-condition ('before any other MiningBridge tool if unsure of the commodity name'). It also names the alternative destination for a related question class (patent questions go to CM-PATRA tools), so the agent has both when-to-use and when-not-to-use guidance.

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