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

With no annotations, the description carries the full burden and does disclose genuinely useful behavior: a per-call credit cost, a 7-day free-sample rate limit, and the NIP-98 signed-GET auth model. It stops short of saying what happens when credits are insufficient or whether the free sample is per-paper or per-agent, and does not note any truncation of the full text.

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?

Two short clauses, zero waste, with the core resource statement front-loaded before the cost conditions. The telegraphic style ("2 cr", bare "Full text") trades some clarity for brevity, which is the only deduction.

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 3-parameter, no-output-schema tool this covers cost, rate limiting, and auth style, but omits what the returned "full text" actually contains (raw paper body vs. structured payload) and what error surface appears when payment or the free sample fails. Adequate but with clear gaps.

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 67%: auth and format are documented in the schema, but the required id (a 64-hex paper identifier) has only a regex and no prose. The description adds nothing about id semantics or about how the NIP-98 auth object should be supplied, so it does not compensate for the uncovered parameter.

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 fragment "Full text" identifies the resource but supplies no verb, so the description never says it fetches/reads a paper's full content. It also fails to distinguish this from the closely named sibling get_paper or from upload_fulltext/submit_paper, which is the main ambiguity an agent would face here.

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 economic usage conditions ("2 cr in the paid window; one free sample per 7 days below 2 cr") which tell the agent when invocation is cheap or free, but there is no guidance on when to choose read_paper over get_paper, list_papers, or upload_fulltext.

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