getDeliveryPrice

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

No annotations provided, so description carries full burden. It discloses read-only nature, cursor-based pagination, no authentication required, and default baseCoin for options. However, it does not mention error handling for non-expired symbols or rate limits; slightly incomplete but still good.

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?

Well-structured with bullet points and sections. Information is front-loaded with main purpose. However, 'Supports cursor-based pagination' appears redundant (in both main description and notes). Agent hint partially repeats earlier points. Slight trimming would improve conciseness.

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 no output schema and no annotations, the description is quite comprehensive: covers purpose, usage distinctions, pagination, auth, and parameter hints. It differentiates from relevant siblings. Missing details on return fields or behavior for invalid inputs, but still sufficient for agent understanding.

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 description must compensate. It explains 'category' filters product type, 'baseCoin' defaults to BTC for options, and mentions 'nextPageCursor' for pagination. But 'symbol', 'settleCoin', 'limit', and 'cursor' are not explicitly described; the schema for 'limit' is self-explanatory but other gaps remain.

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 clearly states the tool retrieves historical delivery (settlement) prices for expired futures and options contracts. It specifies the resource (historical delivery prices) and verb (retrieve), and lists specific use cases. It also distinguishes from sibling tool getInstrumentsInfo, which handles upcoming delivery dates.

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?

Explicit guidance on when to use (e.g., look up settlement price of expired contract, analyze historical delivery prices) and when not to use (upcoming delivery dates, with a direct reference to getInstrumentsInfo). Includes agent hint with specific tips for option queries and cursor-based pagination.

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