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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the pagination behavior, which is a small but real addition beyond the annotations. However, it does not disclose what the response contains, whether results are ordered by default, or any rate-limit or filtering behavior. With annotations carrying the safety burden, a 3 is appropriate.

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?

The description is a single short sentence with no filler, and the key action ('Search by tracking key') is front-loaded. It earns its place, though it is so brief that it sacrifices substance. This is efficient but not necessarily complete.

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?

The tool has 5 parameters, 0% schema description coverage, and an output schema that is not described. The description does not explain what a tracking key is, what tracker_type values are accepted, or what the paginated response looks like. For a search tool with this many siblings, the description is too thin to allow confident invocation without external knowledge.

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 compensate for the schema's lack of parameter documentation. The description only mentions pagination, which maps to page/limit/sort, but says nothing about the meaning of 'tracker_type' or 'key' beyond their names. The schema provides titles and types but no descriptions, so the agent is left to guess what values are valid for tracker_type and what format key should take. This is a significant gap.

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 states a specific verb and resource ('Search by tracking key') and notes pagination, which is clear enough to identify the tool's basic function. However, it does not distinguish this from the many other search_* siblings, and 'tracking key' is not elaborated (what kind of tracking key, what it matches against). It is not a tautology, but it lacks the specificity needed to differentiate it from similar search tools.

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 provides no guidance on when to use this tool versus alternatives. With over 100 sibling tools including many search_* variants, an agent has no way to know whether search_tracking_key is the right choice for a given query. The pagination hint is the only contextual clue, and it does not address selection criteria.

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