Default Privacy

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

Annotations already declare readOnlyHint and openWorldHint, so the description adds valuable context by detailing the returned data (dates, exposed data classes, account counts) and the domain-only scope. This goes beyond the annotations, though it omits potential limitations like rate limits or data freshness.

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 two sentences, front-loaded with the core purpose, then return details, then a scope qualifier. Every sentence earns its place with no redundancy 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?

For a simple tool with one parameter, no output schema, and basic annotations, the description covers all essential aspects: purpose, return value composition, and scope limitation. It adequately prepares an agent to understand what the tool does and what results to expect.

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 fully describes the single 'domain' parameter with 100% coverage, so the description adds little beyond the schema. It reiterates domain-level scope but does not introduce new parameter-related detail, aligning with the baseline score for high schema coverage.

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 the tool's function: checking if a domain appears in known public data breaches via HIBP. It also distinguishes from siblings by explicitly noting 'domain-level only — no personal email is queried', which differentiates it from email/password-focused 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 (domain-level breach checks) and hints at exclusions by stating 'no personal email is queried', implying that email-level lookups belong elsewhere. However, it does not explicitly name alternative sibling tools or state when-not-to-use conditions.

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

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds valuable context by specifying 'Read-only DNS lookups; no email is sent or stored.' This reassures about side effects and aligns with the annotation without contradiction, going beyond just repeating the hint.

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 two sentences, front-loaded with the primary action, and every phrase adds value. It efficiently conveys purpose, method, and side-effect safety without 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?

For a simple tool with one parameter and no output schema, the description covers the action, the records checked, the return format (A–F grade with explanations), and the read-only nature. It is fully sufficient for an agent to understand and invoke the tool.

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 coverage is 100%, with the sole parameter 'domain' clearly described. The description adds little beyond the schema, only implying the domain parameter through the overall purpose. Baseline 3 is appropriate since the schema already documents the parameter fully.

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 uses a specific verb ('Check') and resource ('a domain's email authentication posture'), explicitly listing SPF, DKIM, and DMARC, which distinguishes it from sibling checks like breach, password, or WHOIS tools. The mention of returning an A–F grade further clarifies its unique purpose.

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 clearly implies the tool is for checking email security, giving context for when to use it. However, it does not explicitly mention alternatives or when-not-to-use, which would earn a 5. The context is strong enough to infer appropriate usage.

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

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

Beyond the readOnlyHint annotation, the description adds rich behavioral details: the password is SHA-1 hashed locally, only the first 5 hash characters are sent to HIBP, the password never leaves the server, is never stored or logged, and the return value indicates found status and frequency. This significantly enhances transparency.

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 states the core purpose, the second explains the privacy mechanism, and the third states the return type. No redundant or filler content.

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 single-parameter tool with readOnly/openWorld hints, the description is complete: it explains the operation, the security behavior, and the return value. The absence of an output schema is mitigated by the explicit mention of what the tool returns ('whether it was found and how many times').

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 schema description already covers the 'password' parameter at 100% coverage, but the tool description adds critical semantic details: the hashing algorithm (SHA-1), the truncation to 5 characters, and the explicit guarantee that the password is never transmitted or stored. This goes beyond the schema's summary and provides practical understanding.

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 the tool's purpose: 'Check whether a password has appeared in known breaches using HIBP k-anonymity.' It uses a specific verb (check) and resource (password), and the mention of HIBP and k-anonymity distinguishes it from sibling tools like dp_check_domain_breaches and dp_check_email_security.

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—when you need to verify if a password is breached—and explains the privacy-preserving method. However, it does not explicitly mention alternatives or exclusions, though sibling tools cover different domains (email, domain, whois), so the usage scenario is implied.

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

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

The annotation already declares readOnlyHint and openWorldHint, so the read-only nature is covered. The description adds meaningful behavioral context by stating that the tool 'flag[s] exposed personal identity fields' and lists the specific fields (registrant name, email, phone, address), which goes beyond a simple lookup and is not captured in annotations. However, it does not describe the output format, which is a minor gap.

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 two sentences, immediately states the main action, and contains no filler. It is front-loaded with the core purpose and the 'Read-only RDAP lookup' note reinforces safety without being verbose.

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 should clarify what the tool returns; it only says it 'flags' fields without specifying the response structure (e.g., list, boolean, details). The tool is relatively simple, and annotations cover safety, but the missing return-value information prevents a higher score.

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% with a single parameter 'domain' that includes an example. The description does not add additional semantics beyond the schema, so the baseline of 3 is appropriate; it does not need to compensate for any coverage 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 uses specific verbs ('look up', 'flag') and clearly identifies the resource (domain's public WHOIS/RDAP registration record). It distinguishes itself from sibling tools like dp_check_domain_breaches or dp_check_email_security by focusing on personal identity field exposure, making its purpose unambiguous.

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 clearly implies the use case: checking a domain's registration privacy and exposed identity fields. However, it does not explicitly mention alternatives or when not to use this tool. The context is clear enough for an agent to decide when to invoke it, though a direct contrast with sibling tools would strengthen it.

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

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

The annotations already declare readOnlyHint=true, and the description is consistent with that. It adds behavioral context beyond the annotations by specifying that the tool performs side-by-side comparison and lists the fields included (ADO score, jurisdiction, encryption, PII requirements, audit status). No contradictions.

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 two sentences with no wasted words. The first sentence states the action and scope, and the second sentence gives the use case, front-loading the key information.

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?

Even without an output schema, the description names the key return fields and the comparison format, and the single parameter is fully documented. The annotations cover the safety profile, making this description complete for a tool of this complexity.

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 fully describes the 'slugs' parameter with min/max items and an example (100% coverage). The description mentions 'by slug' but adds little beyond what the schema provides, so the baseline score 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 uses a specific verb ('Fetch') and clearly states the resource ('full Privacy Protocol records') and scope ('for 2–5 tools by slug'). It distinguishes the tool from siblings like dp_get_tool (single tool) and dp_find_alternatives (alternatives).

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?

It explicitly says when to use the tool: 'Use to help a user choose between shortlisted tools.' However, it does not explicitly mention alternatives or when not to use it, so it falls just short of a 5.

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

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

Annotations already include readOnlyHint=true, and the description adds context by noting the output includes 'live ADO score and link' and that results are 'curated from the Default Privacy directory'. This goes beyond the schema and reveals the source and freshness of the data. No contradictions 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?

Two concise sentences that are front-loaded with the main purpose, followed by a clear usage clause. Every word adds value with no repetition of schema details or unnecessary fluff.

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 simple read-only lookup tool with no output schema, the description is complete: it explains what it returns (alternatives with ADO score and link), the source (Default Privacy directory), and when to use it. The behavior is fully described without needing to explain return values in detail.

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 has 100% coverage with descriptions for both parameters, including examples and default value for limit. The description repeats the product examples but adds no new parameter-specific semantics. Baseline 3 is appropriate since schema does 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 uses a specific verb 'return curated privacy-respecting alternatives' and explicitly names the resource (Default Privacy directory). It also provides concrete examples ('Google Analytics', 'Hotjar') and clearly distinguishes itself from sibling tools like dp_search_tools or dp_compare_tools by focusing on alternatives for hostile products.

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 explicitly states 'Use when a user wants to replace a tracking or privacy-hostile tool', giving a clear context. However, it does not provide when-not-to-use guidance or name alternative sibling tools, so it falls short of a 5.

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

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

The annotations (readOnlyHint=true) already establish this is a safe read operation. The description adds that it returns the 'full definition and content', giving the agent a good sense of the response. No contradictions with annotations. It does not mention edge cases like not-found behavior, but that is not required given the simplicity and annotation coverage.

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, well-structured sentence that is front-loaded with the verb and resource. It contains no filler or redundant information, making it highly efficient.

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 simple tool with one parameter, no output schema, and strong annotations, the description is fully sufficient. It states what the tool does, how the term is identified, and what is returned, leaving no major gaps for an agent to understand when and how to use it.

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 provides 100% coverage, including a description and example for the slug parameter ('end-to-end-encryption'). The description merely says 'by slug', adding no extra information beyond what the schema already provides. This meets the baseline but does not exceed it.

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 uses a specific verb ('Fetch') and clearly identifies the resource ('a single glossary term's full definition and content') and the identifier ('by slug'). This distinguishes it from dp_search_glossary, which searches for terms, and other sibling tools that retrieve guides or 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 implies the tool is used when you know the exact slug of the glossary term you want to retrieve. It does not explicitly mention alternatives or exclusions, but the context is clear: this is the direct-fetch by slug tool, while searching is handled by dp_search_glossary.

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

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

Annotations already establish this as a read-only operation (readOnlyHint=true). The description adds that it returns 'full markdown content and metadata,' which clarifies the output shape without contradicting the annotation. It doesn't detail metadata fields, but that is beyond what annotations cover.

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?

A single, direct sentence that immediately states the action and object. No filler or redundant context.

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 this simple get-by-slug tool, the description covers what it does, which resource it targets, and what kind of output to expect (markdown and metadata). With full parameter documentation in the schema and a readOnly annotation, nothing critical 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 schema already fully describes the singular 'slug' parameter with an example (100% coverage). The description merely restates 'by slug' and offers no additional semantic detail, so it does not elevate beyond the schema baseline.

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 uses the specific verb 'fetch' and clearly identifies the resource ('a single guide') and the retrieval key ('by slug'). This distinguishes it from sibling tools like dp_search_guides (search-based) and dp_get_glossary_term (different entity type).

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 implicitly directs use to when a guide slug is already known, but it does not explicitly instruct the agent to use dp_search_guides when the slug is unknown, nor does it mention any alternative or exclusions. Thus it falls between minimal and clear context.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds useful behavioral details—ranking by ADO score and excluding the input—but does not describe return format, pagination, or default limit behavior beyond the schema.

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, focused sentence that front-loads the primary purpose and adds key constraints (same category, ADO score, excludes input) without any wasted words.

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 the tool's simplicity, two well-documented parameters, and a read-only annotation, the description covers the essential context. It does not detail the output shape, but for a simple list-returning utility, this is sufficient.

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%, so both slug and limit are already documented. The description clarifies that the slug refers to a directory tool and that results are same-category peers, but it does not add significant meaning beyond the schema's parameter descriptions.

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 the verb (return), the resource (other tools in the same category), and the ranking criterion (ADO score). It also explicitly notes that the input tool is excluded, which distinguishes it from sibling tools like dp_find_alternatives and dp_compare_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 implies when to use the tool: when you need a shortlist of tools in the same category as a given directory tool. It does not explicitly list exclusions or alternative tools, but the phrase 'peers/alternatives within the directory' provides clear context for its purpose relative to siblings.

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

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

With readOnlyHint=true, the safety profile is already known. The description adds value by enumerating the exact record contents (description, ADO score, jurisdiction, etc.), giving the agent a clearer picture of the return payload. This goes beyond the annotation's basic read-only guarantee.

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 one sentence, front-loaded with the action, and contains no filler. Every element (record scope, slug identifier, field list) earns its place, making it both concise and informative.

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 the tool's simplicity (one parameter, read-only, no output schema), the description is sufficient. It lists the record's fields, covering return content, and clearly states the lookup mechanism. It could mention behavior for unknown slugs, but that is a minor gap for a getter tool.

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 schema already provides 100% coverage for the single 'slug' parameter, including a clear description and examples. The description merely repeats 'by slug' without adding new semantic depth, so it does not meaningfully enhance what the schema already offers.

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 the tool fetches a single privacy tool's full record by slug, listing the exact fields included. It is specific about the verb (fetch), resource (privacy tool record), and identifier (slug), and it distinguishes from sibling getter tools like dp_get_glossary_term and dp_get_guide by specifying it is for 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 makes the intended use obvious (retrieve a specific tool's record by slug) and implies this is the tool to use when you need that exact data. However, it does not explicitly mention alternatives or when not to use it, which would have made the guidance stronger.

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

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

Annotations already mark this as read-only, so the description adds context by specifying the output includes category groups, subcategories, and tool counts, and that slugs are returned. This goes beyond the annotations without contradicting them.

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 two sentences with no redundant information. The first sentence states the core purpose, and the second sentence provides actionable guidance, making every word earn its place.

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 the tool has no parameters and no output schema, the description adequately covers what it returns (categories, subcategories, counts, slugs) and how to use the result (filter dp_search_tools). This is complete for a simple read-only listing tool.

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 zero parameters, so the baseline is 4. The description does not need to explain parameters and instead focuses on output and usage, which is appropriate for a no-parameter tool.

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 the tool lists the privacy tool directory's category groups and subcategories with tool counts, using a specific verb and resource. It distinguishes itself by noting the returned slugs are used to filter dp_search_tools, clarifying its role among sibling 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 explicitly instructs users to use the returned slugs to filter dp_search_tools, providing a clear integration use case. It does not mention alternatives or exclusions, but the reference to dp_search_tools gives sufficient context for when to use this tool.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value by disclosing the return format (term, definition, and link), which is a behavioral trait beyond annotations. It does not mention nuances like fuzzy matching or empty results, but for this simple read-only operation the disclosure is sufficient.

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?

Two sentences, front-loaded with the core purpose, followed by return details and alternative. Every sentence earns its place with no redundancy 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?

Given the low complexity (2 optional params, no output schema), the description is complete enough: it states what is searched, what is returned, and the alternative for full details. The only minor gap is lack of explicit pagination/result-count behavior, but the limit parameter covers this.

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 coverage is 100% with both parameters (limit and query) described directly in the input schema. The tool description adds no parameter-level detail beyond the schema, so the baseline score 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 clearly states the tool searches the privacy & security glossary for defined terms, with a specific verb ('Search') and resource ('glossary'). It distinguishes from sibling tools by noting the full-entry alternative dp_get_glossary_term.

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?

It explicitly names an alternative (dp_get_glossary_term) for full entries, implying when to use search vs. retrieve. However, it does not explicitly state when not to use this tool or contrast with other search tools (e.g., dp_search_guides, dp_search_tools).

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

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

The readOnlyHint annotation already establishes the safety profile; the description adds value by stating the return format (metadata and links) and defining the content domain. It does not discuss pagination or rate limits, but these are covered by the 'limit' parameter and are not critical for a search 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?

Three tight sentences with no fluff: action, scope, filter, and output/alternative. Front-loaded with the primary purpose, and every sentence earns its place.

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 simple read-only search tool with full schema coverage, the description adequately covers what the tool does, the corpus scope, how to filter, and what results look like. It also mentions the companion dp_get_guide without needing an output schema.

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 coverage is 100%, and the schema descriptions are already clear for all three parameters. The description only adds 'Filter by category,' which does not introduce new meaning beyond the schema; hence the baseline 3 is appropriate.

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 Default Privacy's long-form guides and playbooks, with a specific verb and resource. It also differentiates from sibling tools by noting it returns metadata and links, and points to dp_get_guide for full content.

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?

It provides clear context about the corpus, how to filter by category, and explicitly directs users to dp_get_guide for full content. However, it does not explicitly contrast with other sibling search tools like dp_search_tools or dp_search_glossary, so exclusions are not fully spelled out.

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

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.