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

Annotations already cover readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds meaningful behavioral context beyond that: the 0-to-1 score scale, the composition of the result (risk indicators, negative mention evidence), risk classification levels, the data source (Stratalize citation risk composite), and the $0.10 USDC per-call cost. This is substantial value over the structured fields, though failure modes for unknown vendors are not disclosed.

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?

Four sentences, front-loaded with the use case before the output format and example. Every sentence earns its place: use context, return shape, illustrative example, and source/cost. The example is slightly verbose but earns its keep by showing how the risk score maps to a decision recommendation.

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?

Given the tool's simplicity — one string parameter, read-only annotations, no output schema — the description covers the key gaps: return format, score interpretation, example, source, and pricing. It also goes beyond by suggesting how to act on the result ('recommend short-term contract only'). Minor omissions like behavior for unknown vendors and classification thresholds keep it from a 5.

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% for vendor_name, so the description must compensate. It partially does — the example ('Vendor X scores 0.72 risk') implies vendor_name identifies the entity being scored. However, it never specifies the expected form (legal name vs. common name, exact-match requirements, ambiguity handling), leaving the single required parameter underspecified.

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 states a specific verb+resource ('screening a vendor for financial instability or procurement risk') and a concrete purpose ('before a long-term contract commitment'). The output claim — a 0-to-1 risk score with indicators and negative mention evidence — clearly distinguishes this from sibling tools like get_vendor_benchmark or get_vendor_market_rate, which target market pricing rather than risk scoring. The worked example makes the purpose 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 opens with an explicit 'Use when...' framing tied to a concrete decision context (vendor screening before long-term contract commitment). It does not name alternative tools or state when not to use it, so it stops short of fully explicit routing, but the usage context is clear and actionable.

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