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

The description aligns with the readOnlyHint=true annotation and reinforces a non-committal, non-destructive operation. However, it adds little beyond the annotations: it restates the no-commitment aspect but does not disclose behavior such as result ordering, pagination, or what fields are returned. The annotation already covers the safety profile, so a mid-range score is appropriate.

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 description is a single, concise sentence that front-loads the core action and scope. Every word contributes meaning, with no fluff or repetition. It is well-suited for quick agent comprehension.

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?

With no output schema and almost no parameter documentation, the description alone is insufficient for an agent to fully understand expected return values or how filters interact. It conveys the high-level purpose but lacks the operational detail needed for confident invocation.

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%, and the description provides no information about limit, min_vcpu, gpu_count, or min_memory_mb. The parameter names are somewhat self-explanatory, but the description does not compensate for the missing schema documentation or clarify units or filtering behavior.

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 action ('Find compute offers') and resource ('compute offers'), and the qualifier 'without creating a financial commitment' clearly distinguishes it from commitment-based siblings like reserve_compute or create_order. The title reinforces the core value proposition. This is unambiguous and actionable.

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 phrase 'without creating a financial commitment' implies the tool is for exploration before committing, but it never explicitly says when to use this tool versus quote_compute, reserve_compute, or compute_status. No alternatives are named, so the agent must infer the appropriate selection context from the wording alone.

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