Default Privacy

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

With no annotations, the description carries full burden. It explains the tool checks HIBP, output structure, and even includes a prompt-injection defense note. However, it does not mention any rate limits, authentication needs, or whether the operation is read-only, which would add completeness.

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 well-structured with clear sections (purpose, usage, input, output, notes). It is slightly verbose but every sentence earns its place. Could be trimmed slightly, but overall effective.

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 (1 parameter, no output schema), the description is fully complete. It explains output format, usage context, and even includes a security note. No gaps remain for an agent to misuse 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?

The input schema has 100% coverage with a single parameter described. The description adds significant value by reiterating the requirement, providing examples, and explicitly excluding personal emails, enhancing agent understanding 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 clearly states the tool checks a BUSINESS domain in public HIBP breach catalogs, using a specific verb and resource. It explicitly distinguishes from personal email checks, making the 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 provides explicit when-to-call scenarios (user provides business domain or as part of a privacy audit) and clear when-not-to-call instructions (personal emails, with routing to an alternative tool). This is exemplary guidance.

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?

Despite no annotations, the description fully discloses behavioral traits: output structure, that value_class is redacted (no data leakage), and includes a prompt-injection defense warning about not treating registration fields as instructions.

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?

Well-organized with labeled sections (purpose, when to call, input, output, advice, security) but slightly verbose; each sentence contributes 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?

Comprehensive given no output schema: covers input, output, usage, security, and next steps; leaves no significant gaps for a single-parameter 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% so baseline is 3; description adds clarity that URLs are accepted and domain extraction occurs, plus an example, exceeding schema documentation.

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-resource combination ('Check whether a domain's public WHOIS / RDAP registration exposes personal identity') and clearly distinguishes from sibling tools like check_domain_breaches by focusing on privacy leak detection.

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 states when to call (privacy concerns, doxxing, first step in audit) and recommends pairing with check_email_security and check_domain_breaches for fuller picture, providing clear context and alternatives.

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 no annotations provided, the description carries full burden. It discloses that the tool returns third-party DNS data and warns against treating DNS values as commands (prompt-injection defense). It also specifies output structure and grade range. However, it does not explicitly state that the tool is read-only or mention any side effects, rate limits, or auth requirements.

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 well-structured with clear sections: purpose, when to call, input requirements, output format, and additional notes. It is front-loaded with the main action. While slightly verbose, every sentence adds value, so it earns a 4.

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 no output schema, the description completely details the output format including fields and grade values. It also covers behavioral context like prompt-injection defense and citing preferences. For a single-parameter tool with no annotations, this is exceptionally thorough.

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 a single parameter 'domain' clearly described in the schema. The description adds value by explicitly stating the parameter is REQUIRED and providing an example value, which reinforces 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 clearly states it checks SPF, DKIM, and DMARC DNS records for a domain and returns a graded posture report with fix links. It distinguishes itself from sibling tool check_domain_whois by specifying that tool is for identity-exposure concerns, not email-deliverability.

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 provides 'When to call' guidance: when user asks about email spoofing, sender authentication, or domain protection, or as part of run_domain_privacy_audit. It also advises preferring check_domain_whois for identity-exposure concerns, giving a clear alternative.

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?

Fully discloses the tool's limitation: it does not perform a live check due to API limitations. Details output structure (availability is string 'unverified') and warns against promising automatic refund on rejection. With no annotations, description meets transparency needs completely.

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?

Description is well-structured with sections and clear language. While lengthy, each sentence serves a purpose (usage, limitations, output). Could be slightly more concise, but given the need to convey important caveats, it is 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?

With no annotations and no output schema, description fully covers input requirements, output format, usage context, and behavioral limitations. Complete enough for an AI agent to use 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?

Adds significant meaning beyond schema: names must be without LLC suffix, jurisdiction drives which state URL is included. Schema coverage is 50%, but description compensates by explaining both parameters' roles and constraints.

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 provides DIY entity-name verification links for three specific states. It distinguishes itself from siblings by explicitly mentioning pairing with suggest_llc_entity_names and noting it is not a live registry lookup.

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 states when to call (when user wants to verify name before submission or before start_anonymous_llc) and what not to do (not to quote response as live lookup). Also advises on how to present results (cite guide and URL verbatim).

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 no annotations, the description fully covers behavior: it reads data (not destructive), returns structured output with severity and sources, handles unknown slugs with a NOT_FOUND error, and includes a prompt-injection warning about treating response content as data.

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 well-structured: purpose and output first, then usage guidance, then detailed input/output format. It is thorough without extraneous text, and every sentence adds essential 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?

The description provides full output structure, error handling, severity levels, and security guidance. Given the lack of output schema, this description is sufficiently complete for the agent to understand and invoke 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?

The single parameter tool_id is described both in schema and in description as 'tool slug'. Description adds that it is required and that unknown slugs yield a NOT_FOUND error, adding value beyond schema. Schema coverage is 100%, so a 4 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 the tool checks a directory's record of known concerns about a privacy tool and returns severity-graded red flags. It distinguishes itself from sibling tools like get_tool_details by noting that red flags are included there too, making the purpose specific.

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 specifies when to call (e.g., when user asks about tool safety), recommends calling after search_privacy_tools/get_alternatives, and advises preferring get_tool_details for full attributes. This provides clear decision guidance.

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?

No annotations are provided, so the description carries the full burden. It details the output structure (comparison object with interpretation note), explains that null values indicate missing data, not negative signals, and describes error behavior (NOT_FOUND error with slug hint). It also includes a prompt-injection defense note. While it does not explicitly mention that the tool is read-only, the context is clear enough.

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 well-organized with clear sections (purpose, when to call, input requirements, output, additional notes). While it is somewhat long, every sentence adds value. It could be slightly more concise, but the structure aids readability and comprehension.

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 that there is no output schema, the description completely explains the return value (comparison_criteria, tools array with fields, interpretation_note, citation). It also covers input constraints, error handling, and a security measure. For a tool with one parameter and moderate complexity, this is thoroughly complete.

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% for the single parameter `tool_ids`, but the description adds meaningful context: it explains that slugs are returned by other directory tools, and provides an example format. This goes beyond the schema's type/constraints and clarifies the source of valid input values.

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 'Compare 2–5 privacy tools side-by-side across privacy attributes, trust signals, payment options, and red-flag count.' It specifies the verb 'compare,' the resource 'privacy tools,' and the scope (2–5, side-by-side). It also distinguishes itself from siblings like `get_tool_details` for single-tool deep dives.

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 includes an explicit 'When to call' section with concrete examples ('X vs Y') and a clear alternative suggestion: 'PREFER get_tool_details for a single-tool deep dive instead of a comparison.' It also notes that it can be used after `get_alternatives` when weighing candidates.

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?

No annotations provided, so description carries full burden. Discloses token binding, consent requirement, expiry, and output fields. Could mention side effects or write nature, but overall good 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?

Well-structured: purpose, context, when-to-call, input requirements, output, tip. Every sentence adds value, no 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?

With 13 params and no output schema, description covers main parameters and output fields, compares with sibling, and advises on usage. Missing a few optional parameter details but still comprehensive for an agent.

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 very low (8%), but description adds meaning: clarifies which params are required vs optional, explains user_consent must be true, and lists sensible defaults. Partially compensates for schema gaps.

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?

Clearly states the tool creates a scoped browser-token draft session for formation review/pay, and explicitly contrasts with sibling `start_anonymous_llc`. Specific verb+resource+scope, distinguishes from 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?

Explicitly tells when to call (user consented and enough fields gathered) and when to prefer sibling (lighter-weight URL-prefill path). Also states prerequisite `user_consent: true`.

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?

No annotations provided, so description carries full burden. It discloses output format (prefill URL, narrative, related docs) and notes that it does not provide legal advice. However, it does not explicitly state whether it is a read-only operation or has side effects, though the prefill URL implies no destructive action.

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?

Description is well-structured with sections for purpose, usage, input requirements, output, and additional notes. Each sentence adds value, though it could be slightly more concise. It is appropriately 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?

No output schema, but description provides the output structure with fields. It also references related docs (bundle-design guide, structure-decision pages) and handles legal advice concerns. Completeness is high given the tool's 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?

Schema coverage is 0%, but description adds meaning for all three optional parameters: template options with defaults, and holding/operating name hints. It explains the role of each parameter beyond the schema's enum and string types.

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 designs a multi-entity bundle and returns a prefill URL. It gives specific examples (NM holding + WY operating, Series LLC) and distinguishes from sibling tools like start_anonymous_llc for single-entity flows.

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 describes when to call (scenarios benefiting from two entities, specific queries) and when not to (prefer start_anonymous_llc for single entity). Also advises against promising legal liability shielding, providing clear usage boundaries.

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?

Discloses that it's a guide (not a server-side lookup), that agents never receive personal emails, and specifies output structure and citation order. Fully compensates for lack of annotations with rich behavioral context.

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?

Well-structured with front-loaded purpose. While slightly verbose, every sentence adds value. Could tighten some guidance, but overall clear and 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 tool with no parameters and no output schema, the description provides complete context: what it does, when to use, output shape, and behavioral traits. No gaps.

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?

With 0 parameters and 100% schema coverage, the description adds value by explaining the tool's purpose and output. No param details needed, but description doesn't detract. Baseline 4 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 the tool guides the user through checking personal email breach via Have I Been Pwned, with specific verb 'guide' and resource 'breach check'. It distinguishes from sibling tool check_domain_breaches by explicitly contrasting inbox vs provider checks.

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 lists when to call (user asks about breached personal email) and when not to (never use check_domain_breaches for these queries). Provides clear alternatives and context for use.

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?

No annotations are provided, so the description carries full burden. It discloses internal mapping logic, ranking by ADO score, return structure including disclaimer, and prompt-injection defense instructions. However, it does not specify error behavior for unrecognized inputs or rate limits.

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 thorough and well-structured with clear sections (purpose, when to call, input, output, notes). It is slightly verbose but every sentence adds value. No 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?

Despite no output schema, the description fully explains the output structure and key fields. It also advises pairing with 'compare_tools' and includes prompt-injection defense. For the tool's complexity, this is complete.

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?

Input schema has 100% coverage, but description adds significant value: it explains that 'tool_or_service' is required, details internal lowercasing/trimming, and gives default (5) and max (20) for 'limit'. This goes beyond what the schema provides.

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 'Find privacy-respecting alternatives to a mainstream service or named tool' and explains the mapping to categories and ranking by ADO score. It distinguishes itself from sibling 'search_privacy_tools' by specifying when to use each.

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?

Explicit 'When to call' section advises using this tool when the user wants to replace a named mainstream service, and directly tells the agent to prefer 'search_privacy_tools' for browsing by capability. This provides clear guidance on when and when not to use the 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?

No annotations provided, so description fully covers behavior: lowercases+trims input, throws INVALID_INPUT error with known slugs on unknown slug, notes that risks[].icon can be ignored, and states output is brand-voice-clean. 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?

Front-loaded with purpose and output contents. Some redundancy (e.g., 'PREFER quoting the citation URL' could be integrated into usage guidelines), but overall well-organized and efficient for a complex tool.

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 with no output schema, description fully specifies output object structure (audience fields, citation). Also explains error behavior and how agent should handle responses. Covers all necessary context for agent invocation.

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 slug parameter already described in schema. Description adds that slug is from list_audiences, provides examples, and states internal lowering+trimming. This adds value beyond 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 clearly states the tool fetches the full audience guide for a slug, listing all returned fields (risks, structure, deliverables, FAQs, related links). It distinguishes from siblings by specifying when to call vs list_audiences and run_privacy_architecture_assessment.

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?

Explicit usage guidance: call after list_audiences when audience chosen, or directly if user names known slug; also advises using list_audiences first if unsure, and prefers run_privacy_architecture_assessment for multi-audience situations. Provides clear when-to and when-not-to guidance with an alternative.

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?

Discloses that the tool does NOT perform server-side IP lookup, keeping the agent IP-blind, and emphasizes the client-side nature of the /exposed check. This is valuable transparency beyond the tool's surface function.

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 well-structured and front-loaded, with each sentence adding necessary detail (action, limitations, use cases, input, output, best practices). Slightly verbose but 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?

Given no output schema, the description provides the full output structure ({exposed_url, what_it_checks, etc.}) and explains how to interpret and use it. Covers all essential context for a 0-parameter 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?

Zero parameters and 100% schema coverage. The description adds value by explicitly stating 'Input Requirements: none,' which confirms the absence of needed inputs beyond the 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 clearly states it explains browser/connection leaks (IP, fingerprint, DNS, WebRTC) and links to the /exposed check. It distinguishes itself from the sibling check_domain_whois, making its purpose unmistakable.

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 specifies when to call (user queries on browser fingerprinting, IP exposure, VPN, DNS leaks, etc.) and when to prefer check_domain_whois for domain-related identity exposure. Provides clear contextual guidance.

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 no annotations, the description carries the full burden. It discloses that parent categories include child counts and that include_empty defaults to false. However, it does not explicitly state that the tool is read-only or idempotent, but that is implied.

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 well-structured with clear sections (When to call, Input Requirements, Output). It front-loads the main purpose. Slightly verbose but each sentence contributes useful 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?

Despite lacking an output schema, the description fully documents the output format including fields like slug, name, tool_count, usage_hint, and citation. It also explains the relationship with search_privacy_tools, making the tool self-contained.

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?

Description adds value beyond the schema: clarifies the default value of include_empty (false) and explains that it returns categories with 'zero published tools.' The schema only says 'Include categories with zero tools.' So the description adds nuance.

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?

Description starts with a specific verb and resource: 'List every privacy-tool category in the directory with a tool count per category.' It distinguishes from sibling tools like search_privacy_tools by noting that categories are a discovery aid and that agents need slugs for filtering.

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 states when to call: 'BEFORE search_privacy_tools when the user has not specified a category slug' and when the user asks about categories. Also provides a preference: 'PREFER search_privacy_tools if the user has already named a topic.' This is excellent guidance.

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?

No annotations are provided, so the description carries full burden. It describes the output as a structured service catalog with package tiers, EIN options, jurisdictions, and addons, which is transparent about what the tool returns. It also notes a behavior of not quoting prices to avoid drift. However, it does not explicitly state that the operation is read-only or discuss error handling, but given the context, the transparency is above average.

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 concise and well-structured: a clear opening listing services, followed by usage guidance, input requirements, output description, and a preference note. Every sentence adds value, no 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?

Given the tool's moderate complexity (returns structured catalog with multiple tiers and options), one optional parameter, and no output schema, the description is complete. It covers what the tool does, when to use, input semantics, output details, and limitations (no prices). It provides sufficient context for an agent to invoke 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% with one optional parameter already documented. The description adds extra meaning by explaining the 'formation' value scopes to LLC formation only and confirms 'all' as default. This adds value beyond the schema, justifying a score above the baseline of 3.

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 that the tool retrieves Default Privacy's first-party services, listing specific types like LLC formation, crypto checkout, SSN-free EIN, and Dead Drop document delivery. It distinguishes itself from sibling tools like start_anonymous_llc by explaining the sequential relationship.

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 states when to call: when the user asks about Default Privacy directly, wants integrated privacy stack, or needs business-formation services. It specifies to call BEFORE start_anonymous_llc for unconfirmed users and advises against quoting prices, providing clear when-to-use and when-not-to-use guidance.

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 no annotations, the description fully discloses behavior: it returns warnings with severity, is a soft gate (not a hard block), empty inputs give generic checklist, and ready_for_checkout becomes true when no high-severity warnings remain. It also mentions surfacing tradeoffs in plain language.

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 well-structured with clear sections (purpose, usage, input, output, guidance) and front-loaded with key info. It is slightly verbose but every section adds value; minor trimming could improve conciseness.

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 complexity (8 optional params, no output schema), the description is thorough: it covers input requirements, output format, usage context, and behavioral traits. It also references additional guides for structural mismatches, making it complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates by listing the fields checked (entity name, jurisdiction, package tier, EIN option, alt names) and advising to pass all decided fields. However, it does not explain each parameter's meaning or enum values, leaving some ambiguity.

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: 'Pre-checkout review of every field about to be submitted on a formation intake,' listing specific fields (entity name, jurisdiction, package tier, EIN option) and flagging combinations. It distinguishes itself from siblings by positioning it between name suggestion and draft creation.

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 states when to call: 'AFTER the user has picked names, jurisdiction, and tier — usually after suggest_llc_entity_names and before start_anonymous_llc / create_formation_draft_session.' It also explains the tool is a soft gate and that warnings should be resolved before proceeding, providing clear context for decision-making.

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?

No annotations provided, but the description fully discloses behavior: it fetches a term, returns a structured output including url, and on unknown slugs returns a NOT_FOUND error with a hint. This covers all relevant behavioral aspects.

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 very concise and well-structured with clear sections (When to call, Input Requirements, Output). Every sentence adds necessary information 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 read tool with one parameter and no output schema, the description fully covers the purpose, prerequisites, input, output structure, and error handling. No gaps are present.

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 schema includes a description. The description adds value by providing concrete examples (e.g., 'beneficial-ownership-information') and reiterating that slug is required, which is already in 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 clearly states the verb 'Fetch' and resource 'one glossary term by slug', and specifies the output fields. It distinguishes from the sibling 'search_glossary' by positioning itself as the tool to call after a slug is known.

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 states when to call: after search_glossary returns a slug or when slug is already known. It also advises to prefer search_glossary first, providing clear guidance on alternative 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?

Describes output structure in detail, error behavior (structured NOT_FOUND error with hint), and that the URL is MCP-attribution-tagged. No annotations exist, so description fully covers behavioral aspects for this read-only 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?

Well-organized with clear sections for purpose, when to call, input requirements, output, and error handling. Every sentence adds value and 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?

Complete for a single-parameter read tool without output schema: covers error handling, relationship with sibling, and expected output structure. No gaps identified.

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 single parameter 'slug' is fully described in the schema with an example. The description reiterates it's required and gives examples, adding marginal value beyond schema. 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 fetches a full Default Privacy guide by slug, listing returned fields. It distinguishes itself from sibling tools like search_guides by specifying that it should be called after a candidate slug is known.

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 states when to call: after search_guides has returned a candidate slug, or when slug is known from prior context. Also advises to prefer search_guides first for topics, and notes error handling for unknown slugs.

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?

No annotations provided, so description bears full burden. It describes outputs (checklist, links, citations) and states input requirements are none. It doesn't explicitly state it is read-only, but the 'get' nature and content imply no side effects.

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?

Well-structured with clear sections: description, when to call, input requirements, output, and additional guidance. Every sentence adds value 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 tool with no parameters or output schema, the description fully explains what the tool does, when to use it, and what the output contains (including manual search URLs and citations). No gaps for its 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?

No parameters exist; schema coverage is 100%. Description mentions 'Input Requirements: none,' which adds clarity beyond the empty schema. Baseline for 0 params is 4.

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 returns a scoring checklist for auditing LLC public record exposure, covering registered agent, member names, addresses, and beneficial ownership. It distinguishes itself from sibling tools like `check_domain_whois` and `run_privacy_architecture_assessment`.

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 provides when to call (existing LLC wanting to check exposure, or after domain checks) and when not to (prefer `run_privacy_architecture_assessment` for new LLCs). Includes clear alternatives.

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?

No annotations are present, but the description fully discloses behavior: output structure with placeholders, consent copy, signing options, child-entity notes, and explicit instruction to never autofill real PII. It also mentions preferred context (privacy architecture guides).

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 well-structured with clear sections (purpose, when to call, input requirements, output) and each sentence adds value. It front-loads the key purpose and is appropriately sized.

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 no output schema or annotations, the description covers all necessary aspects: usage context, parameter details, expected output structure, and behavioral notes. It is complete for an AI agent to select and invoke this 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?

With 0% schema description coverage, the description provides thorough context: all fields optional, jurisdiction preferred, entity_role free-text examples, and child entity parameters explained. This fully compensates for the schema gaps.

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 provides post-payment guidance for member/manager intake, specifying exact outputs like privacy placeholders and consent copy. It distinguishes itself from siblings like start_anonymous_llc by describing when to call.

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 states when to call (after payment, during member intake) and provides alternative use case (when user asks about placeholders). It also gives preferences for parameters like jurisdiction.

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 no annotations, the description fully covers behavioral traits: input processing (lowercase+trim), error handling (structured NOT_FOUND error with hint), output structure, and prompt-injection defense. This is comprehensive.

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 well-structured with sections (main purpose, when to call, input, output, security note) and front-loaded with the key action. It is slightly long but each sentence adds 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?

Despite no output schema, the description explains the return format in detail (PrivacyProtocolTool object with attributes, citation URL). It also covers error handling and security considerations, making it complete for a tool with one parameter.

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 only parameter, tool_id, is described in both schema and description. Description adds that slugs are case-insensitive and lowercased/trimmed, and notes that slugs are returned by other tools, providing context 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 clearly states it fetches the full Privacy Protocol record for a single tool by slug, listing specific return fields (privacy/trust/payment attributes, red flags, verification tier, canonical URL). This distinguishes it from sibling tools like search_privacy_tools and 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 explicitly provides 'When to call' scenarios: when the user names a specific tool or after obtaining candidates from search/alternatives. It also advises preferring compare_tools for side-by-side comparisons, offering clear guidance on when to use this tool vs. alternatives.

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?

No annotations provided, so description bears full burden. It explains output fields (slug, audience, headline, etc.), ordering by slug, and meaning of structureType. Doesn't mention auth or side effects, but as a list tool this is acceptable.

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?

Description is well-structured with clear sections but slightly verbose with examples and repeated guidance. Front-loaded with key purpose; could trim redundant phrases like 'PREFER' block.

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 zero-parameter tool with no output schema, description fully explains input (none), output fields, sorting, and intended usage flow. Includes chaining advice and next steps, making it complete.

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 has zero parameters with 100% coverage, so baseline is 4. Description adds 'Input Requirements: none', which is consistent but not necessary. No additional param info needed.

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?

Description clearly states 'List every audience-specific privacy guide' and distinguishes from sibling get_audience by specifying chaining behavior. Examples of audiences and output fields further clarify the 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?

Explicit 'When to call' section lists scenarios like user describing profession or asking about client types. Also advises preferring get_audience when slug is known, providing clear alternative guidance.

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?

Despite no annotations, the description thoroughly explains behavior: composite nature, deterministic rule engine, confidence bands, error handling for empty calls, normalization of fields, and output semantics. It warns against quoting `estimated_total` as a guarantee and specifies citation preferences.

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 well-structured with clear sections, but it is lengthy. Every sentence provides value, but could be slightly more concise. It front-loads purpose and usage.

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?

Without an output schema, the description fully explains the output structure: all fields, confidence bands, and usage of `narrative` and citations. It ensures the agent understands every aspect of the tool's response.

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 description adds context beyond schema: `scenario_text` uses regex extraction, `audience_type` should come from `list_audiences`, and the requirement that at least one field must be provided despite all being optional. This adds meaning not in 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 clearly states the tool's purpose: to recommend the best LLC structure based on user situation via audience matching and rule engine. It differentiates from siblings like `start_anonymous_llc`, `design_entity_bundle`, `request_consultation`, and `run_privacy_architecture_assessment` by specifying when to call each.

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?

Explicit 'When to call' section details use cases and alternatives. It advises preferring `run_privacy_architecture_assessment` for guided flows and only calling `request_consultation` when confidence is 'consultation_recommended'. Input requirements specify which fields to prefer and when.

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?

No annotations provided, but the description fully discloses that it does not trigger formation, queues human follow-up, requires consent, and describes rate-limiting behavior with retry-after 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 well-structured with clear sections (summary, when to call, input requirements, output). Every sentence adds value 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?

Given no output schema, the description thoroughly explains output fields (status, reference_id, expected_response_time, related_docs). All input requirements and behaviors are covered.

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%, baseline 3. The description adds meaning by explaining that consent must be true, email is contact, context is from prior checks, and message is optional free-text.

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 'Submit a consultation request to the Default Privacy team' and distinguishes from siblings by noting it is for ambiguous/legally-sensitive situations, not self-serve formation.

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 specifies when to call (ambiguous, multi-entity, legally-sensitive) and when not to (prefer self-serve for straightforward formation). Also advises not to promise specific outcomes.

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?

No annotations are provided, so the description carries the full burden. It describes input requirements and output structure, and gives behavioral notes like 'Be honest when the recommendation is consultation.' However, it stops short of explicitly stating idempotency or read-only nature, which would be helpful for an agent to understand side effects.

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 well-structured and front-loaded: first purpose, then when-to-use, then input requirements, then output structure. Every sentence provides unique value, and there is no redundancy or filler. It's concise while being comprehensive.

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 fully compensates by detailing the return structure: `{ recommended_path, rationale, suggested_next_tool, narrative, related_docs }`. It also mentions that `suggested_next_tool` names the MCP tool to call next, and gives guidance on citing audience landing pages and being honest. The tool is simple (1 param), and the description covers all essential aspects for correct agent usage.

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%, but the description adds significant value beyond the schema by specifying that `answers` is required and must be a record keyed by question ID with string values. It provides concrete example values (e.g., hide-from-public-records) and tells the agent to pass at minimum the user's primary goal. This greatly aids correct parameter construction.

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 'Determine which Default Privacy product family fits the user' and identifies the resource (decision quiz). It distinguishes itself from sibling tool `run_privacy_architecture_assessment` by specifying this is upstream (which product?) and that one is downstream (which structure within formation?).

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 states when to call: 'when the user asks what should I do? or where do I start? and has not committed to any product family yet.' Also provides a clear alternative: 'PREFER run_privacy_architecture_assessment once the user has chosen formation as the path forward.' Additionally advises honesty when recommending consultation.

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 no annotations, the description carries full burden and delivers comprehensive disclosure: it is composite, runs sub-checks, includes optional website scan, and provides output structure. Notably, it includes a prompt-injection defense warning, adding behavioral context beyond basic functionality.

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 structured into clear sections (when to call, input requirements, output) and is reasonably concise for the information conveyed. A marginal reduction in length could improve conciseness, but it effectively front-loads 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?

Despite no output schema, the description fully describes the output structure (domain, grade, findings, fix_links, etc.), explains the composite nature, and addresses contextual needs like prompt-injection defense and citing guides. It is 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?

Schema coverage is 100% (both parameters described), so baseline is 3. The description adds value by stating 'domain is REQUIRED', 'include_scan is OPTIONAL (default true)', and 'set false for a faster check', providing behavioral context beyond schema 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 explicitly states it is a composite tool that runs WHOIS, email-security, and breach checks, returning a single graded audit. It clearly distinguishes from siblings like check_domain_breaches, check_domain_whois, and check_email_security by noting it chains three primitives.

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 explicit guidance: call when the user wants a one-shot audit or before recommending entity formation when multiple exposure layers are suspected. It also advises preferring individual primitives when the user has a specific concern, demonstrating clear when-to-use and when-not-to-use instructions.

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?

No annotations exist, so description carries full burden. It discloses output fields, caching behavior via force_refresh, heuristic nature, and includes a prompt-injection defense warning. This is thorough for a tool with no 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?

The description is somewhat long but well-structured: purpose first, then usage guidelines, input requirements, output summary, and additional advice. Each section earns its place, though minor trimming could improve conciseness.

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 listing output fields and explaining score_label. It also addresses potential issues (heuristic, prompt injection). For a complex tool with no annotations or output schema, this is very complete.

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 baseline is 3. The description adds context by explicitly stating url is REQUIRED, and explaining force_refresh bypasses cache. It also clarifies that url is a website URL or domain, adding value beyond 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 clearly states the tool analyzes a privacy policy text and returns summary, score, red flags, and positives. It distinguishes from sibling tools like get_tool_details and check_red_flags by specifying when to use this auto-analysis versus curated data.

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 states when to call: when user pastes a policy or before recommending a non-directory tool. Also tells when not to call by preferring get_tool_details/check_red_flags for directory tools, providing clear guidance on alternatives.

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?

No annotations are provided, so the description carries the full burden. It accurately describes the tool as a read-only assessment that returns a recommendation. It does not disclose any side effects, destructive actions, or required permissions, but for a non-mutating analysis tool, the description is sufficiently transparent about its behavior.

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 well-structured with clear sections for purpose, usage guidelines, input requirements, and output description. It is concise yet comprehensive, with every sentence adding value. Front-loads the core purpose.

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 one complex parameter and no output schema, the description thoroughly explains the input requirements, provides an example of minimum input, and describes the output structure (recommended_structure, rationale, etc.). It also mentions follow-up actions, making it complete for an AI agent.

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% (the 'answers' parameter is described). The description adds value by stating that the parameter is required, suggesting a minimum 'intent' field, and noting that richer answers yield more specific recommendations. This additional semantic detail goes beyond the schema alone.

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?

Description clearly states it takes answers from a Privacy Architecture Assessment questionnaire and returns a structure recommendation with rationale. It specifies the tool's role in helping users uncertain about business structure, and distinguishes from siblings like 'recommend_entity_structure' by mentioning preference for 'design_entity_bundle' after multi-entity recommendations.

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 provides 'When to call:' conditions, including user uncertainty about business structure and willingness to answer questions, or when answers are already gathered. Also advises preferring 'design_entity_bundle' after multi-entity recommendations, offering clear guidance on tool sequencing.

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?

No annotations provided, so description carries full burden. It explains output format (slug, term, short_definition, etc.), that entries cross-reference each other, that empty results return broadening suggestions, and recommends follow-up with get_glossary_term. Missing mention of rate limits or auth, but these are not needed given context.

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?

Description is well-structured in three clear paragraphs: glossary context, usage guidelines, input requirements/output. Every sentence adds value without redundancy. Appropriate length.

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 3 parameters, no output schema, and no nested objects, the description thoroughly covers usage context, input constraints, output structure, and recommended follow-up actions. It is self-contained and actionable.

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% but description adds significant value: requires at least one of query or category, warns about empty call error, and specifies default/max for limit. This goes beyond the schema 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 tool's purpose: searching a glossary of privacy and LLC terminology for definitions. It distinguishes from sibling tool 'search_guides' by noting that 'search_guides' is for procedural/explanatory content, while this tool is for definitions.

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 states when to call: when user asks 'what is X', 'what does Y mean', or 'define Z'. Says to prefer search_guides for how-to content, providing clear guidance on alternatives.

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?

No annotations provided, so description carries full burden. Clearly describes output (fields like slug, title, url), error handling (VALIDATION_ERROR if neither query nor category provided), and empty results with suggestions. Also advises on using returned urls and following up with get_guide. Could mention if any state changes occur (none apparent).

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?

Well-structured with clear sections. Slightly long but each part adds value. The 'When to call' and behavior descriptions are necessary given the context of many sibling tools.

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 no output schema, description thoroughly explains return format, error conditions, and recommended follow-up actions. Fully covers the tool's complexity with 3 parameters and multiple usage scenarios.

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% but description adds important usage constraints: at least one of query or category required, limit defaults to 8 with max 25. This goes beyond what schema properties describe.

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?

Describes searching guides by topic, category, or tags, with clear verb ('Search') and resource ('Default Privacy's library of guides and playbooks'). Distinguishes from sibling tools `get_guide` and `search_glossary` in the 'When to call' section.

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?

Explicit 'When to call' section provides criteria for using this tool versus `get_guide` and `search_glossary`. States when to call before or after `get_guide`, and directs glossary queries to `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?

With no annotations, the description carries full burden. It details output structure, sorting by ADO score, empty results behavior, and prompt-injection defense. Implicitly a read operation, but could explicitly state read-only nature.

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 well-structured with clear sections (purpose, when to call, input requirements, output, prompt injection). Every sentence is purposeful and adds value, no 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 tool with 9 optional parameters, no output schema, and no annotations, the description is comprehensive. It covers output fields, sorting, empty results handling, and follow-up actions, making it sufficient for an agent to use 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% (baseline 3). The description adds value by explaining parameter usage preferences (prefer at least query or category), defaults (limit=10, max=50), and how filters narrow results. This goes beyond the schema 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 tool searches a privacy tools directory and returns Privacy Protocol records. It differentiates from siblings by specifying when to use this tool before get_tool_details or compare_tools, and when to prefer get_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?

The description provides explicit 'When to call' guidance, including examples like user asking for privacy alternatives or browsing by capability. It also gives input preferences and recommends alternative tools for specific 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?

With no annotations provided, the description carries full burden. It discloses that the tool does NOT submit the filing but builds a URL for the user, and mentions silent context notes to preempt agent over-promises. However, it does not explicitly state if the operation is read-only or destructive, though the non-submitting nature implies safety.

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 well-structured with clear sections: purpose, when to call, input requirements, output description, and warnings. While it is long, each section is relevant and adds value. Front-loads core purpose effectively.

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 13 parameters with full schema coverage and no output schema, the description adequately explains the output components (intake URL, checklist, name suggestions, context note). It also covers usage context and warnings, making it complete for selection and invocation.

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 baseline is 3. The description adds value by explaining which parameters to prefer prefilling, the use of `finding` to carry diagnostic context, and the legacy note for `wants_hands_off_compliance`. This goes beyond the schema to guide effective usage.

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 starts a privacy-structured LLC formation flow with a prefilled intake URL and checklist. It distinguishes from siblings like `design_entity_bundle` and `suggest_llc_entity_names`, specifying it is action-oriented and does not submit the filing.

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 provides when-to-call scenarios (after diagnostic tools, name suggestions, preflight checklist) and when to use alternative `design_entity_bundle` for multi-entity bundles. Also specifies input preferences (e.g., prefer prefilling jurisdiction, package_tier) and warns against promising automatic refunds or turnaround times.

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 no annotations, the description fully discloses behavior: it does not initiate scans automatically, builds a URL for user consent, and sets expectations about the ongoing nature of data-broker removal. 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 well-structured with clear sections (purpose, when-to-call, input, output) and all sentences provide useful information. Slightly verbose but still 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?

Despite lacking an output schema, the description details the output structure (`{ scan_url, what_it_checks, expected_steps, related_docs, citation }`) and adds important context about implicit consent flow and ongoing process.

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 single parameter `email` is fully described in the schema (100% coverage) and the description adds value by explaining the behavioral difference when provided versus omitted.

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: 'Link the user into the data-broker-removal funnel with MCP-attribution tracking.' It explicitly contrasts with the sibling `run_domain_privacy_audit`, ensuring distinction.

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?

Provides explicit guidance on when to call ('when the user asks about data brokers, people-search sites') and when to prefer an alternative ('PREFER run_domain_privacy_audit if...'), setting clear usage boundaries.

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?

No annotations provided, so the description fully bears the burden. It details default opaque naming for privacy, other styles, input requirements, output structure, and caveats like not performing live availability checks and never claiming a name is available. This gives agents a complete behavioral model.

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?

Well-structured with clear sections: purpose, when to call, input requirements, output, and guidance. However, it is somewhat verbose and contains some redundancy (e.g., repeating that contextual requires context_hint). Overall front-loaded and organized.

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 no output schema and no annotations, the description covers all necessary aspects: input parameters with details, output fields (jurisdiction, style, suggestions, etc.), caveats, and relationships with sibling tools. It is fully self-contained for agent understanding.

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?

Despite 100% schema coverage, the description adds significant value: explains defaults, dependencies (context_hint only used when style is contextual), and the meaning of enum values (opaque, nature, abstract, contextual). This goes well 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 clearly states it generates neutral LLC entity-name suggestions for privacy formation. It specifies the verb 'Generate' and the resource 'LLC entity names', and distinguishes from the sibling tool 'check_llc_name_availability' by noting it does not perform live availability checks.

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 states when to call: when forming an LLC with no names, needing help, or using a personal name. Also says to call BEFORE 'start_anonymous_llc' and directs to 'check_llc_name_availability' for live checks, providing clear when-to-use and alternatives.

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