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

Beyond the readOnly/idempotent/destructive annotations, the description discloses meaningful behavior: results come from a versioned public search document, include match provenance, are revalidated against website checkout eligibility, and use stable pagination. It also clarifies the closed-world scope and what kind of data is excluded. This adds substantial context beyond the 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?

Three tightly written sentences: the first states the core action and key guarantees, the second explains the data source and revalidation behavior, and the third clarifies exclusions. There is no filler, and the most important info is front-loaded.

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 read-only, idempotent public catalog search with an output schema and fully documented optional parameters, the description covers purpose, scope, data provenance, pricing, pagination stability, and privacy boundaries. Nothing essential for an agent to decide whether and how to call this tool is missing.

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?

The input schema already documents all six parameters with descriptions, defaults, and constraints at 100% coverage. The description adds general context about stable pagination and public catalog scope but does not add parameter-specific semantics beyond what the schema provides. A baseline of 3 is appropriate here.

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 opens with a specific verb and resource: 'Searches currently orderable Vitals Vault tests and panels.' It also distinguishes this from sibling search tools by emphasizing 'customer-safe prices,' 'public search document,' and ordering/checkout eligibility, which clearly mark it as the public catalog search tool.

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 gives clear context for when to use the tool: for currently orderable public catalog items, not personal or account-specific data. It explicitly excludes identity, account data, private results, and PHI from the input contract. It stops short of naming an alternative sibling tool or an explicit 'use X instead' guideline, so it earns a 4 rather than a 5.

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