queryFixedAvailableInventory

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

Annotations already mark this read-only, and the description adds a concrete computation formula (min(market supply + 50M finance trial, UTA remaining borrow limit)), rounding-down precision, and account restriction. No contradiction with 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?

Purpose is front-loaded, and the rules are grouped into a tight bulleted list with no filler. The 'Service' line is minor extra context but not harmful; the 'All parameters are required' bullet partly duplicates the schema.

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 read-only query with no output schema, the description explains the calculation and constraints well, but lacks parameter formats (term, annualRate) and any hint about the response shape. It is adequate but not fully self-sufficient.

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 has 0% coverage, so the description must carry the meaning. It usefully specifies uppercase currency and required/allowed-coins constraints, but it does not define the term format or how annualRate should be expressed (decimal vs percentage), leaving two of three parameters 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?

States a specific action ('Query') on a concrete resource ('available inventory for fixed-rate borrowing') and names the three required dimensions. However, it never distinguishes this from the similarly named sibling getCryptoLoanFixedAvailableInventory, so it stops short of full differentiation.

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 rules give clear prerequisites (unified account, supported coins, uppercase currency, all parameters required) but there is no explicit when-to-use/when-not-to-use statement or mention of an alternative tool. It implies the fixed-rate borrowing context but leaves the agent to infer when this endpoint is preferred over siblings.

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