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

Adds substantial behavior beyond the annotations: abstract availability (~6 in 10), refusal of stale/expired quotes, Professional+ account requirement, and the full x402 payment mechanics including currency, chains, the $0.01 quote credit, and the _meta["x402/payment"] field. This is exactly the kind of auth/pricing/failure-mode context annotations cannot carry.

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?

Front-loads the core action and inputs in the first sentence, then layers return details, failure modes, and billing. Dense but every clause carries information; the payment sentence is long but the pricing detail is load-bearing for a pay-per-call tool.

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, the description still characterizes the return: papers with abstracts and the curation/ranking rationale. Combined with the auth, billing, and failure conditions, an agent has everything needed to decide and call correctly.

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 coverage is 50% — quote_id is documented ('From lab_quote') but depth is only an enum with a default. The description compensates by naming both depth values and explaining what they control (top papers by impact matched to the quoted filter). It does not state the effective upper bound or ordering differences between papers_20 and papers_100 beyond the labels.

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 verb and resource ('Get the papers for a lab_quote') plus the exact inputs (quote_id, depth) and the output semantics (top papers matching the quoted filter, ranked by impact, with curation behind each rank). This clearly separates it from lab_quote (which issues quotes) and the get_subject_papers / get_element_papers siblings.

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?

Explains the prerequisite workflow (quote_id comes from lab_quote), the depth choice, and a clear when-not condition: a stale or expired quote is refused. Also gives the account requirement and a pay-per-call fallback path. It stops short of explicitly contrasting with the other paper-retrieval siblings, so a 4 rather than 5.

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