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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering safety. The description adds context about the vetted directory and ADO scoring but does not disclose behaviors like response structure or pagination limits. With annotations present, this is adequate but not exceptional; the description adds some value beyond annotations but not rich detail.

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 three sentences, each earning its place: the first defines the scope, the second mentions filtering and the ADO score, the third provides a recommendation guideline. It is front-loaded and free of redundancy.

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?

With no output schema, the description gives enough context for a search tool: resource, examples, filtering capabilities, and scoring. It does not detail pagination or default sort but those are in the schema. The recommendation guideline adds extra value. Slightly incomplete regarding what results look like, but not critical given the schema richness.

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 has 100% description coverage, so all 11 parameters are already documented. The description mentions filtering by category and privacy attributes, which aligns with the parameters but adds no specific syntax or format details. Baseline 3 is appropriate since the schema carries the heavy lifting.

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 clearly states it searches a specific resource ('Default Privacy directory of vetted privacy tools') with concrete examples of categories (VPNs, email, browsers, etc.). It also mentions the ADO score, which is a distinctive feature. This differentiates it from sibling search tools like dp_search_glossary and dp_search_guides by focusing on privacy 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 clear context for when to use the tool: to search for vetted privacy tools and filter by category/attributes. It also gives a usage preference ('Prefer higher ADO when recommending'). However, it does not explicitly mention alternatives or when not to use this tool, though siblings like dp_get_tool and dp_compare_tools imply different use cases.

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