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

With no annotations, the description carries the full burden and does so well: it discloses the free/paid split, the top-250 census-depth gating, the 404 fallback pointing at the x402 paid quote, the discontinued raw-card quotes, and a frozen USD level. It adds real behavioral context beyond any structured field. It stops short of auth mechanics or rate limits for this endpoint.

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?

It is front-loaded with the core purpose and an explicit 'Use this when' closer, which is good structure. However, the long parenthetical derivation chain (realized sales > delisting-inferred sales > ask median x 0.85 ...) and the interleaved pricing/gating details make it read as a run-on paragraph where several clauses do not earn their place for tool selection.

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 no annotations, the description supplies most of what an agent needs: scope, gating rules, fallback behavior, related universe endpoint, and an informational-only disclaimer. Gaps remain on product_id's meaning and what the six-step derivation actually returns, but for a preview tool it is largely complete.

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 the description must compensate. It does for two of three params: grade is given a format example ('PSA 10') and its omission default (the slab's deepest-census grade), and term_days is constrained to 7, 14 or 30 as free text. product_id, the only required parameter, is never explained, leaving the caller to infer it is a slab identifier.

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 verb+resource: a free, worked derivation of lending terms (max LTV) for a graded slab, with a named date-stamped methodology. It explicitly distinguishes itself from the paid /api/v1/loan-terms quote endpoint, so an agent can tell the two apart. It does not differentiate from other siblings (market_snapshot, simulate_price), and the dense parenthetical derivation chain slightly muddies the core purpose.

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?

It gives an explicit 'Use this when' clause: collateral math for a slab, or explaining how the oracle derives an LTV before paying for a full quote. It also names the alternative (/api/v1/loan-terms) and the condition that routes to it (non-free-board slabs return 404). No explicit when-not guidance beyond the 404 case, so it falls short of a 5.

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