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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds genuinely useful context beyond that: no authentication required, free access, pagination support, the composition of returned records (title, type, experiment, availability, collision energy, abstract snippet), and the domain-specific data formats (NanoAOD/MiniAOD/AOD). No contradiction with annotations.

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?

Four sentences, each earning its place: purpose, filters, return content, and access/pagination/format context. The main purpose is front-loaded in the first sentence. The record-field enumeration and format detail are slightly granular but informative for an agent deciding whether results will satisfy a user request. No filler or tautology.

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?

Given an output schema exists (return values need not be spelled out), the description covers what remains essential: authentication (none), pagination behavior, what fields each record contains, and the data formats available. All 5 parameters are optional and fully documented in the schema. The only gap is the missing differentiation from sibling CERN Open Data tools, which is a usage-guideline concern rather than a coverage gap.

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 100% — every one of the 5 parameters (q, page, type, limit, experiment) already carries meaningful documentation with examples, defaults, ranges, and enums. The description reinforces these concepts (filter by record type, experiment, and keyword; supports pagination) but adds no new parameter-level meaning beyond the schema, so the baseline of 3 applies.

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 names a specific verb and resource — 'Search 80,000+ particle physics records from the CERN Open Data portal' — and scopes it with experiments (CMS, ATLAS, ALICE, LHCb, legacy) and record types. This clearly distinguishes it from a detail-fetch or browse tool, though it never explicitly names its siblings (cernopendata.records.detail, cernopendata.datasets.browse), which keeps it from a 5.

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 description implies when to use the tool through context — filtering, full-text keyword search, pagination, record contents — and explicitly notes 'Free, no auth required,' which is useful adoption context. However, it provides no explicit guidance on when NOT to use it, such as 'use cernopendata.records.detail for a specific record' or 'use cernopendata.datasets.browse for browsing datasets,' even though three sibling CERN Open Data tools exist.

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