createQuote

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

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description is consistent with them. Beyond the annotations, it adds valuable behavioral context: the 50 requests-per-second rate limit, the self-quoting prohibition, and the collateral requirement for spot products. It stops short of describing the post-submission lifecycle (e.g., whether the quote is binding or awaits counterparty action), but the added context meaningfully exceeds what the annotations convey.

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 compact (~90 words), front-loads the core purpose, and uses a bullet list for the buy/sell distinction and rate limit. The only waste is slight redundancy: the agent hint restates 'Provide at least one of quoteBuyList or quoteSellList' already given in the opening paragraph. Otherwise every sentence earns its place.

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 7-parameter, destructive, no-output-schema tool with 14% schema coverage, the description covers the core mechanics well but leaves gaps: there is no explanation of what a successful submission returns, how the quote fits the broader RFQ workflow (acceptance, execution), or the meaning of expireIn/anonymous/quoteLinkId. The confirm semantics are handled by the schema, which helps, but an agent still lacks enough context to fully predict the tool's behavior end-to-end.

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 only 14%, so the description must compensate. It does exactly that for the two most confusing parameters: quoteBuyList and quoteSellList have identical item schemas, and the description disambiguates them ('Maker execution matches the leg direction' vs 'opposite to the leg direction') — without this, an agent literally could not tell them apart. It also states the mutual-exclusivity constraint. However, rfqId, expireIn, anonymous, and quoteLinkId receive no semantic explanation anywhere, leaving a coverage gap.

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 opens with a specific verb+resource: 'Submit a quote for an existing RFQ.' The phrase 'existing RFQ' cleanly separates this from sibling createRfq, and the buy/sell direction semantics distinguish it from executeQuote. An agent can identify the tool's role in the RFQ lifecycle without ambiguity.

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 agent hint gives an explicit when-to-use directive ('Use this to respond to an RFQ with pricing') and the description states the at-least-one-list validation. It also provides one clear exclusion ('You cannot quote your own RFQ') and a spot-product prerequisite (collateral enabled). However, it never names sibling alternatives like acceptNonLpQuote or executeQuote, so routing among the RFQ quote family is left partially to inference.

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