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

With readOnlyHint=false, the agent knows this is not a pure read, and the description correctly clarifies it does not charge or start work, which is genuinely useful boundary-setting. It does not say whether a quote record is created, whether the quote expires, or what 'detects source drift' means for the caller (warning? hard failure?), so the mutation side effect remains underspecified.

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 short, front-loaded sentences with no filler; the scope and the 'does not charge' caveat are placed early where an agent will see them. 'Detects source drift' is terse to the point of being cryptic, but nothing is redundant.

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?

For a 2-param tool with no output schema and no annotations beyond safety hints, the essentials are present but thin: the agent still does not know what a successful quote returns, whether quoting is repeatable, or how drift is surfaced. Adequate as a minimum-viable definition, not complete for a billing-adjacent step in an import pipeline.

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%, so the description must carry full weight. It adds one meaningful constraint — the profile must be an 'approved profile' — but says nothing about upload_id, whether it must be a completed upload, or how the two IDs relate. Most of the parameter semantics remain undocumented.

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?

'Quote one full-file evaluation against an approved profile' names a specific verb (quote) and resource (full-file evaluation), which is far more informative than the tool name alone. It is distinguishable from start_supplier_import by implication ('does not ... start work'), though the term 'quote' remains ambiguous about whether it produces a price, a time estimate, or a validity decision.

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?

'Does not charge or start work' implies this is the pre-flight step before start_supplier_import, which is useful context. However, it never explicitly says when to use this versus preview_supplier_feed or whether quoting is a prerequisite for approval/start, leaving the agent to infer the ordering.

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