Offers ranked by real cost

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

Annotations already declare this is read-only and non-destructive, and the description adds genuinely extra behavioral detail: the bucket categories, the 'not by sticker $/hour' ranking with download time weighted, and the {ok, message, next_tool, next_args} response envelope. Nothing in the description contradicts the annotations.

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 tight sentences: the first states the purpose, the second adds the ranking nuance that prevents misuse, and the third gives the return envelope. There is no filler, repetition, or redundant restating of the tool name.

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 output schema, annotations, sibling context, and a small param set, the description covers the tool's role, ranking behavior, and return wrapper. The main gaps are the unclarified max_usd_per_hour parameter and the lack of explicit usage boundaries, but those do not make the tool unusable for an agent.

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 schema documents limit, template, and work_minutes, covering 3 of 4 params; the description mainly reinforces template via 'workload' and work_minutes via 'weight download time included'. It does not clarify max_usd_per_hour, whose schema field has no description, so the description only partially compensates.

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 phrase 'Live Vast offers for a workload' names a concrete resource and action, and the bucket/ranking explanation ('ready_now ... unsupported', ranked by actual session cost) differentiates it from sibling listing tools like list_templates or list_instances. The title reinforces the central differentiator: ranked by real cost.

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 usable context: call it when you need live offers that can run a specific workload/template. However, it never names an alternative or an explicit exclusion, such as 'use estimate_deployment instead when you only need a cost estimate', so it does not fully meet the bar for a 5.

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