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

With no annotations, the description does substantial work: it discloses the unsupported_nucleus error contract ('results: [], never the proton table'), truncation semantics (bounded at max_results 50 per category, n_results is the untruncated count), and that empty query is valid. It does not address the api_key parameter, auth requirements, or cost, which is the remaining gap for an unannotated tool.

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?

One front-loaded sentence states purpose and precondition, then a tightly structured bullet list gives per-category semantics. Every line carries distinct information — defaults, error behavior, or truncation — with no restatement of the tool name or filler.

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?

An output schema exists, so return shape needn't be described, and the description instead covers what the schema cannot: error status values, the no-fallback guarantee for unsupported nuclei, truncation accounting, and default category/nucleus behavior. That is everything needed to invoke this correctly aside from auth details.

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 carry parameter meaning, and it does for four of five: category values are fully enumerated with per-value semantics, nucleus gets its default (1H) and the allowed alternate (13C), query gets the empty-string interpretation, and max_results gets a bound. Only api_key is left completely unexplained.

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 ('Look up NMR reference data') and immediately carves out scope with 'no spectrum needed', which separates it from the many covnmr_* analysis tools that do require spectra. The four enumerated category values make the tool's coverage concrete rather than generic.

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 'no spectrum needed' precondition implicitly routes agents away from covnmr_analyze/identify toward this table-lookup tool, and 'An empty query is a legitimate "show me the table" request' gives explicit guidance on an edge case agents would otherwise avoid. It stops short of naming sibling tools or stating when this should be skipped in favor of them.

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