Pick the cheapest offer that really fits

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

Beyond the annotations (readOnly, openWorld, non-destructive), the description discloses a real behavioral guarantee—'Never picks hardware the workload cannot run on'—and explains that it accounts for weight-download costs rather than sticker price. It also reveals the return envelope {ok, message, next_tool, next_args}, making its recommend-then-delegate behavior concrete. No contradiction with annotations; readOnlyHint is consistent with producing next_args rather than creating.

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 compact clauses front-load the core value proposition, and every sentence earns its place: plan contents, the compatibility guarantee, and the return envelope. There is no filler, restatement of the schema, or marketing language.

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?

The description covers the plan contents, cost model (weight download), safe-selection guarantee, and return envelope, and an output schema exists so return values need not be re-explained. Gaps are moderate: no statement of failure behavior when no offer fits, and no explicit routing relative to estimate_deployment—though the core calling contract is clear.

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 83%, so the baseline is 3 even without parameter details in the description. The text reinforces the planning model (session cost, work_minutes context) but adds no parameter-specific semantics and does not compensate for max_usd_per_hour, the single parameter lacking a schema description.

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+resource: it turns a workload template into a concrete rental plan. Names the exact deliverables (offer to rent, session cost including weight download, avoided sticker-price trap, create_instance arguments) and differentiates from siblings like estimate_deployment and create_instance by framing itself as the planning step that outputs next_tool/next_args.

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?

Usage context is implied—'One call from a workload to a concrete plan' signals this is the pre-create planning step, and 'exact create_instance arguments' hints at its place in the workflow. However, it never names alternatives or exclusions; with siblings like estimate_deployment that could plausibly serve the same role, an explicit 'use this when X, use that when Y' is missing.

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