Default Privacy

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

Goes well beyond the readOnly/idempotent/openWorld annotations: it discloses the external data source (HIBP catalog), the shape of the results (dates, exposed data classes, account counts), the privacy scoping (no email ever requested), and a prompt-injection warning about third_party_fields written by others. That injection guidance is materially useful behavior an agent would not get from 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?

Front-loads purpose, then returns, then scope, then a safety directive — a sensible order with little waste. The final third_party_fields sentence and the awkward 'pass on personal_check:' clause are slightly dense and could be tightened without losing meaning.

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 compensates by naming the returned fields, and it covers scope limits and injection safety. The only gap is the ambiguous personal-email pointer, which leaves the precise alternative path slightly unclear for an agent deciding where to route.

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 already 100% for the single 'domain' parameter, so baseline is 3. The description earns above baseline by clarifying that the parameter is strictly a domain and that no email address is accepted or queried, which prevents a common misuse.

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?

States a specific verb and resource ('Check whether a domain appears in known public data breaches') and names the underlying source (Have I Been Pwned breach catalog). It also draws the line against the nearest sibling by declaring 'Domain-level only: no personal email is queried', which separates it from 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?

Gives a clear when-not ('no personal email is queried') and points to an alternative route for personal email checks. However, the phrasing 'pass on personal_check: Have I Been Pwned's own site' is grammatically muddled and makes the exact hand-off less crisp than it could be.

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/idempotent/destructive=false, and the description adds genuinely useful behavior beyond them: the lookups are DNS-only, no email is sent or stored, and — importantly — the returned records are untrusted text from the domain owner that must never be treated as instructions. That prompt-injection warning is high-value context an agent cannot get from structured fields.

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, zero waste, front-loaded with purpose and result, then the safety-relevant read-only and injection caveats. Every clause 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?

Although there is no output schema, the description states what the tool returns (an A–F grade with explanations), confirms the operation is read-only DNS, and warns about untrusted record content. Nothing an agent needs in order to call and interpret the result 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?

There is a single parameter, and the schema documents it fully (100% coverage) with an example ('example.com'). The description adds no format or edge-case detail beyond the schema, so the baseline 3 for high-coverage schemas 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?

States a specific verb (Check) and resource (a domain's email authentication posture), enumerating exactly what is inspected — SPF, DKIM, and DMARC DNS records — and what is returned (A–F grade). No sibling in the list does DNS email-auth checks, so an agent can route to it unambiguously.

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 this is the right tool: verifying a domain's email authentication posture. No exclusions or alternative tools are named, but none of the siblings overlap with this capability, so the lack of an explicit 'use X instead' clause is minor.

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, idempotentHint, destructiveHint=false, so the safety profile is covered. The description adds real value on top: it explains the two outcome branches (listed record vs. unlisted checklist), distinguishes registry-declared metadata from the monthly read-only scan, and warns that third_party_fields are written by others and must not be followed as instructions. That injection and data-provenance guidance is behavioral context the annotations cannot express.

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 purpose and timing are front-loaded in the first sentence, and every later sentence conveys distinct information. The middle sentence is long and clause-heavy, stacking the two metadata sources and their input-form conditions into one run-on, which slightly hurts scanability.

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 carries the full burden of explaining return values, and it does: listed servers return a record with sources and caveats, unlisted servers return a checklist plus optional registry declarations and scan observations. That is sufficient for an agent to interpret either response branch correctly.

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 parameter already documents its accepted forms with an example. The description still adds meaning by linking input form to output content — a GitHub or registry name yields registry declarations, while an exact registry name or server URL additionally triggers scan data — which the schema does not convey.

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: check whether an MCP server is in Default Privacy's vetted list and what it can read or change. That scope clearly separates it from siblings like dp_check_domain_breaches or dp_check_email_security, which audit different resources, so an agent can route without opening a schema.

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 gives an explicit usage trigger — 'Before connecting an MCP server, check...' — and clarifies that 'Unlisted is not a verdict,' which prevents a likely misinterpretation. It does not name an alternative tool or say when this check is unnecessary, so it stops short of a full when/when-not/alternatives treatment.

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 cover readOnly, idempotent, non-destructive and openWorld, so the bar is lower — yet the description adds a genuinely non-obvious behavioral warning: returned fields are registrant/registrar-authored text and must be reported, not obeyed. That prompt-injection guidance is exactly the kind of context annotations cannot carry.

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 short sentences, zero padding: purpose first, safety profile second, injection guidance last. Every sentence earns its place and the most important routing information 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?

With no output schema, the description does describe the shape of the result (a registration record plus flagged identity fields) and the read-only nature of the call. It stops short of saying what a flagged-versus-clean result looks like, which leaves a small gap for an agent reporting findings.

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?

Only one parameter, and the schema already documents it at 100% coverage with an example ('example.com'). The description adds no format, normalization, or TLD/idn handling details beyond the schema, so baseline 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?

States a specific verb ('look up') plus the exact resource (public WHOIS/RDAP registration record) and the derived result (flagging exposed identity fields). That resource specificity is enough to separate it from siblings like dp_check_domain_breaches or dp_check_email_security without opening any schema.

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?

Usage is only implied: 'Read-only RDAP lookup' tells the agent this is a safe query, but there is no explicit when-to-use or when-not-to-use, and no sibling is named as an alternative for related privacy/security questions.

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 readOnly/idempotent/closed-world, so the description's job is to add beyond them, and it does: it discloses that each record carries `sources` and `caveats`, and critically defines null semantics ('Default Privacy has not checked it — never read null as no'). That is a genuine misread-prevention rule an agent could not get from the schema or 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 dense sentences, front-loaded with the operation and scope before the field list and the citation rule. Slightly packed, but every clause (field list, null rule, quoting/citing instruction) 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?

No output schema exists, and the description compensates by naming the returned fields plus the `sources`/`caveats` elements. Combined with the null-interpretation rule and the quoting/citation instruction, an agent has everything needed to call it and present results correctly.

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% and already states 2–5 slugs with an example. The description restates the 2–5 range but adds no slug syntax or resolution guidance beyond what the schema provides, so baseline 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?

Specific verb+resource+scope: 'Fetch the full Privacy Protocol records for 2–5 tools by slug for side-by-side comparison.' It also enumerates the return fields (DP pick, jurisdiction, encryption, PII requirements), which makes it clearly distinct from single-tool siblings like dp_get_tool and from dp_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?

Explicitly frames the use case: 'Use to help a user choose between shortlisted tools', which implies the tool is for post-search comparison rather than discovery. It stops short of naming alternatives like dp_get_tool or dp_find_alternatives, so the when-not guidance is inferred rather than stated.

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 annotations covering safety (readOnly, idempotent, non-destructive), the description adds meaningful behavioral context: trackers return a curated swap list, consumer products return a hand-picked list with DP picks first, plus what_changes, related guides, and stacks. It stops short of describing rate limits or error handling.

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 front-loaded with usage guidance, then moves logically through input and output details. The long parenthetical example lists add some bulk, but each sentence contributes useful information and no major redundancy is present.

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 tool with full schema coverage and rich annotations, the description covers the key behavioral and return-value information an agent needs. The absence of an output schema is compensated by explaining what_changes, related guides/stacks, and dp_url, though error cases (e.g., unknown product) are not addressed.

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 the 'product' and 'limit' parameters are already documented in the schema. The description says 'Pass the product's name' and gives examples, but adds no meaning beyond the schema and never mentions the limit parameter.

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 ('find alternatives') and resource ('product') and clearly explains its two modes: consumer products vs. trackers. It implies differentiation from sibling tools like dp_get_related_tools or dp_search_tools, but does not explicitly name or contrast with them.

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 opening 'Use when a user wants to replace a mainstream product' gives clear situational guidance, including example product categories. It does not state when not to use this tool or name alternative tools for other scenarios.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered. The description adds only that the response contains the "full definition and content," which is useful but thin — no word on behavior for a missing slug or whether the record is cached/static.

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?

One sentence, front-loaded with the verb and scope, with zero filler. Nothing could be removed without losing 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?

For a one-parameter read tool with rich annotations and full schema coverage, the description is nearly sufficient; output shape is hinted at ("full definition and content"). The remaining gap is the absence of any pointer to dp_search_glossary for slug discovery.

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 single `slug` parameter is documented with a concrete example ('end-to-end-encryption'). The description restates "by slug" without adding format, casing, or derivation rules, so the schema does the real work — baseline 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?

Specific verb ("Fetch") plus specific resource ("glossary term") scoped to a single item retrieved "by slug". The singular-plus-slug framing implicitly separates it from the bulk dp_search_glossary sibling, though it never names that sibling.

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?

Usage is only implied: an agent infers this is the exact-lookup path once it has a slug. There is no explicit guidance on where the slug comes from (e.g. dp_search_glossary) nor what to do when the slug is unknown, which is the main decision point an agent faces here.

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, idempotentHint, destructiveHint false, and openWorldHint false. The description adds useful behavioral detail about the default summarized response versus section text versus full markdown, though it does not describe error behavior for invalid slugs.

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 concise sentences, front-loads the core operation, and every sentence adds useful information about output modes.

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 clearly explains what is returned by default and how section/full alter the response. Combined with annotations covering the safety profile, it gives enough context to call the tool correctly.

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%, so the schema already documents all three parameters. The description still adds meaning by explaining that section should be one of the provided headings and that full overrides the default summary-only behavior.

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: fetch one guide by slug. The phrase 'one guide' also implicitly distinguishes single-guide retrieval from sibling search tools such as dp_search_guides.

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 clearly explains the default behavior and how to request a section or the full guide. It does not explicitly name dp_search_guides as the way to discover a slug, so it lacks full when-to-use routing but provides clear operational 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 readOnly/idempotent/non-destructive/non-open-world, so the safety profile is covered. The description adds useful behavior the annotations don't: result ordering (DP picks first, then alphabetical) and that X is excluded from results.

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 dense sentence with the use case front-loaded, then the return behavior, then the fallback. No filler or repetition of schema/annotation data.

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?

No output schema exists, yet the description conveys what comes back (peer tools, ordering, exclusion) and where to go when the lookup doesn't apply. Limit defaults are covered by the schema, so nothing an agent needs 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?

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by constraining slug to a directory slug (not any product name) and noting X is excluded from results, which prevents a common misuse.

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?

States a specific verb and resource: returns other tools in the same directory category, with ordering (DP picks first, then A-Z) and the exclusion of the input tool. This clearly distinguishes it from dp_find_alternatives mentioned in the same sentence.

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?

Gives an explicit trigger ('Use after dp_get_tool for "what else is like X?"') and names the alternative with its condition: for products the directory doesn't list, use dp_find_alternatives. Nothing is left to inference.

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 readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description still adds real value beyond them by describing the default payload shape (summary plus layers plus tools in setup order) and warning that full: true returns a long document.

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 sentences, no filler, and the most important information (what it does and the default return) is front-loaded. The mode options are compressed into one sentence without losing meaning.

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 steps up to describe return shape across all three modes, which is the critical gap for this tool. It does not cover failure behavior for an unknown slug or what valid section headings look like, but nothing needed to make a correct call 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?

Schema coverage is 100% so the baseline is 3, but the description goes further by explaining what each mode returns: default is summary plus layers, section returns why each tool and the tradeoffs, full returns the entire stack. It also clarifies slug provenance, which the schema only illustrates by example.

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?

Opens with a specific verb and resource ("Fetch one privacy stack by slug") and immediately distinguishes itself from nearby list/search siblings by naming where slugs come from. An agent can tell this apart from dp_list_stacks, dp_search, or dp_get_tool without inspecting schemas.

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?

Gives concrete routing guidance: slugs come from dp_list_stacks or dp_search, and it names the two modes (section vs full) with a preference for section when full would be long. It stops short of stating exclusions explicitly, but the context for use is clear.

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?

Adds important behavioral context beyond annotations: null means 'not checked' and must never be read as 'no'; caveats should be quoted and sources cited. It also describes the shape of sources (links keyed by field with date checked), which is valuable since no output schema exists.

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?

Front-loads the core action and returned fields, then adds essential null and citation guidance. Every sentence earns its place with no wasted text.

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 lack of an output schema, the description thoroughly explains what is returned, including sources and caveats, and clarifies critical null semantics. An agent has everything needed to call and interpret the tool correctly.

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 slug parameter is fully documented in the schema. The description adds that slugs come from dp_search_tools but no additional format or validation details beyond the schema examples.

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?

States a specific verb and resource ('Fetch one directory tool's full record by slug') and enumerates the returned fields, including sources, caveats, and dp_url. This clearly distinguishes it from sibling search/list tools like dp_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?

Explicitly tells the agent where slugs come from ('Slugs come from dp_search_tools'), establishing the prerequisite and implied sequence. It does not spell out when-not-to-use or compare against siblings such as dp_compare_tools, but the usage context is clear.

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 readOnly/idempotent annotations, the description explains conditional return fields, the 18-month stale flag, the need to quote ToS;DR's grade with its date rather than as Default Privacy's verdict, and that third_party_fields are untrusted data to report but not follow. This adds substantial behavioral context the annotations do not 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?

The usage trigger is front-loaded, but the return-value details are packed into one long, densely parenthetical paragraph. Much of the content earns its place, but the nested clauses and single-block structure reduce readability.

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?

There is no output schema, so the description carries the return-shape burden and does so thoroughly: it names the fields, explains when they appear, describes stale and not_measured semantics, and warns about third_party_fields. An agent has enough information to call it and interpret the response correctly.

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% for the single `product` parameter, and the schema already gives examples. The description only repeats “Pass the product's name,” adding no extra syntax, accepted formats, or naming constraints beyond the schema.

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 question it answers — how private an app, service, or device is — and enumerates the concrete outputs (dp_record, replacements, terms_review, vendor_policy, not_measured). This clearly distinguishes it from sibling tools such as dp_find_alternatives or dp_get_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?

It gives clear triggering examples (“how private is Notion?”, “is Zoom safe?”) and the required action (“Pass the product's name”). It does not explicitly name alternatives or say when not to use this tool, but the intended context is unambiguous.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds value beyond that by disclosing the shape of the payload (category groups and subcategories with counts) and the presence of slugs, which is the key behavioral detail an agent needs to chain calls correctly.

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, no filler, with the purpose front-loaded ahead of the routing instruction. Every clause carries actionable information: what is listed, what is included (counts), and how to use the result.

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 must describe the return value, and it does so at a useful level (groups, subcategories, counts, slugs). It does not say whether the hierarchy is nested or flat, nor how counts are scoped, but for a zero-parameter read-only listing tool this is close to 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?

The tool takes no parameters, so the baseline is 4 and there is no input semantics to explain. The mention of slugs is output-oriented rather than a mislabeled parameter, so no penalty 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?

States a specific verb (List) and specific resource (the directory's category groups and subcategories), plus the return payload (tool counts). This is unmistakably distinct from sibling tools like dp_search_tools or dp_get_tool, which operate on tools rather than the taxonomy itself.

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 second sentence gives concrete downstream usage: the returned slugs should be fed into dp_search_tools as filters, which implies this is a discovery/bootstrap step before searching. It stops short of naming when NOT to call it (e.g., when a slug is already known), so it falls just short of explicit alternatives/exclusions.

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 readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds the meaningful behavioral fact that it enumerates *every* stack (no filtering or paging) and enumerates the returned fields (title, slug, short description, url), which is valuable given there is no output 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?

Two sentences, front-loaded with the action, and the trailing routing pointer is short. The parenthetical example list is longer than strictly necessary but does real disambiguation work for a non-obvious domain term.

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 parameters, no output schema and full annotation coverage, the remaining burdens are the meaning of 'stack', the shape of the result, and the handoff to the single-stack tool — all three are addressed. Nothing an agent needs before calling it 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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for no-param tools applies. The description correctly signals there are no filter arguments by saying it lists everything.

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?

States a specific verb and resource ('List every privacy stack') and then defines the domain term with concrete examples (starter kit, de-Googling, journalist's kit, Windows hardening), so an agent unfamiliar with 'stack' still knows what it retrieves. It is cleanly distinguishable from dp_get_stack, which retrieves a single stack.

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 closing clause explicitly names the alternative, dp_get_stack, and the condition that selects it ('for one stack's full content'). It lacks any guidance on when a stack is the right entry point versus dp_list_categories or dp_search_tools, so the routing is helpful but not exhaustive.

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 cover read-only, idempotent, closed-world and non-destructive behavior, and the description adds genuinely new context: the user's words must never be forwarded, and 'the standard starting set is always included' regardless of input. It stops short of describing result ordering or what a 'stack' contains, but the privacy-handling and always-included behavior are the important disclosures here.

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 behavioral rules and routing alternatives are front-loaded in the first three sentences, and the long id glossary is a scannable, parallel-structured list. It is verbose, but each gloss earns its place by disambiguating an enum value.

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 closed-enum tool with no output schema and strong annotations, the description covers selection rules, privacy handling, guaranteed inclusions, and next steps. The only gap is that it doesn't hint at the shape of the returned guides/stacks, which is acceptable given no output schema exists.

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%, so the baseline is 3, but the description goes well beyond it by glossing every enum value with a natural-language situation ('harassment (Someone is watching or harassing me)'), which is exactly what an agent needs to map user phrasing to an id. It also restates the 1-to-3 constraint from the schema plus ordering guidance ('best fit first').

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?

States a specific verb and resource ('Pick the 1 to 3 situations ... get the guides and stacks') and enumerates every valid situation id, so the agent knows exactly what the tool returns. It is clearly distinct from siblings like dp_search and dp_get_guide, which are named as different actions.

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?

Explicitly names the alternative ('For a keyword lookup use dp_search instead') and the follow-up path ('Open a result with dp_get_guide or dp_get_stack'). It also constrains selection ('1 to 3', 'Choose the ids yourself from what the user said'), leaving nothing to inference.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds behavior annotations cannot express: AND semantics across keywords, filler-word stripping, per-type result caps, and the exact fields returned (type, title, slug, one-line summary, Default Privacy url). With no output schema, that return-shape disclosure is genuinely load-bearing.

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 routing instruction and core semantics are front-loaded in the first two sentences. The final sentence is dense — it carries both the return-field list and a five-way sibling handoff — which is packed but every clause does work. Slightly long for a single paragraph, but no 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 two-parameter search with no output schema, the definition covers invocation semantics, result shape, and routing to every relevant sibling. An agent has everything needed to decide whether to call it and to interpret what comes back.

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%, so the baseline is 3, but the description adds real meaning: every keyword must match, filler words like 'how'/'best'/'private' are ignored, and 'top few results of each type' clarifies that limit is applied per result type rather than globally. Only the limit bounds are left to the schema, which already handles them.

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?

States a specific verb and resource: one keyword search across the whole hub, covering checked answers, directory tools, guides, stacks and glossary. It explicitly enumerates what it searches and names the type-specific siblings it is not (dp_search_tools, dp_get_tool, etc.), so an agent can distinguish it without opening any schema.

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?

Opens with 'Start here for a general privacy question', an explicit entry-point condition. It then names each alternative and the condition that selects it: dp_search_tools for filters, dp_get_* for full content, dp_find_alternatives for replacing a named product. When and when-not are both covered.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real value absent from annotations: it discloses what is returned (term, definition, link) and that results are a summary, with the full entry in a separate 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?

Two front-loaded sentences: the first states purpose and returns, the second routes to the sibling. No filler, nothing repeated from the schema.

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 usefully explains return contents and how to get more detail. Minor gap: it doesn't mention the result cap (limit max 50) or that searches may be partial, but that is largely covered by the 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%, with the query and limit parameters fully documented including an example and a default. The description adds no parameter-level meaning beyond the schema, so baseline 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?

States a specific verb (search) and resource (privacy & security glossary) plus the returned fields. It explicitly names dp_get_glossary_term as the sibling it is not, so an agent can route without opening either schema.

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?

Gives a clear routing condition: use dp_get_glossary_term for the full entry, implying this tool is for term discovery. It doesn't state when-not to use it relative to dp_search or dp_search_guides, but the alternative is named explicitly.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds genuinely useful behavior: it returns metadata and links only, not full guide text, and points to the follow-up tool. It does not discuss pagination or result ordering, but the limit default is in 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?

Three tight sentences: scope with examples first, filtering second, return shape and next step last. No filler, and the most decision-relevant information 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?

With no output schema, the description appropriately states what comes back (metadata and links) and how to get the body content. Scope, filterability, return type, and follow-up path are all covered for a zero-required-parameter search 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 description coverage is 100%, so the matching rules for query and the category examples are already fully documented in structured fields. The description only restates 'filter by category,' adding nothing beyond the schema. Baseline 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?

Specific verb (Search) plus a precisely scoped resource (Default Privacy's long-form privacy how-tos), reinforced by concrete content examples like GrapheneOS switching and data-broker removal. It also names dp_get_guide as the full-content sibling, so an agent can separate the two without opening either schema.

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?

Gives a clear routing rule: this tool returns metadata and links, dp_get_guide fetches full content. It also states category filtering as a usage mode. It stops short of explicitly distinguishing itself from the broad dp_search sibling, which is the one remaining ambiguity an agent faces.

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 readOnly/idempotent annotations, it discloses matching logic (AND across all query words), default ordering (DP picks first, then A–Z), default page size, the `pick` field meaning, and the critical caveat that null never means 'no' and that unchecked fields produce picks_not_checked. That is substantial behavioral context an agent would otherwise have to guess.

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?

Usage guidance is front-loaded in the first sentence and the paragraph proceeds from query strategy to filters to return shape in a logical order. It is dense and somewhat run-on, but nearly every clause carries operational 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?

With 8 optional parameters and no output schema, the description steps in to describe the result shape: default 10 results, up to 50, ordering rules, the `pick` field, jurisdiction/logging/encryption/dp_url fields, and null semantics. An agent can call and interpret this correctly without further docs.

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%, so the baseline is 3, but the description adds real semantics: query word-AND matching, category slugs sourced from dp_list_categories, filter behavior ('a filter matches only a sourced yes'), and limit up to 50. It doesn't explain offset/pagination beyond the schema, keeping it at 4 rather than 5.

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 first sentence names a specific verb and resource ('privacy tool recommendations') and enumerates the domain (VPNs, email, browsers, messengers, password managers). It is clearly separable from dp_get_tool (detail) and dp_list_categories (browsing), both of which are named.

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 gives explicit when-to-use context, plus concrete keyword guidance ('1–2 keywords ... a full sentence usually returns nothing') and names the alternative for browsing a whole kind of tool: `category` with slugs from dp_list_categories. It also routes to dp_get_tool for sources and caveats.

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