Unphurl

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

Beyond the annotations (idempotentHint=true), the description discloses crucial behaviors: duplicates are silently skipped, maximum domain counts per account and per request, subdomain coverage, and rejection of non-registrable formats. This goes well beyond what annotations provide and prepares the agent for expected outcomes.

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 (five sentences) and front-loaded with the main action. Each sentence adds distinctive value: purpose, scoring effect, format rules, subdomain behavior, and limits. No fluff or 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 one-parameter add tool with no output schema, the description is fully adequate. It covers what the tool does, when to use it (scoring context), format constraints, limits, and edge-case handling (duplicates, subdomains). No critical gaps remain for the agent to select and 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?

Although the schema already describes the 'domains' parameter with 100% coverage, the description adds significant nuance: registrable domain only, subdomains automatically covered, and per-request limit of 100. This extra information is essential for correct invocation and was not fully captured in the schema description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Add one or more domains to this account's trusted allowlist,' using a specific verb and resource. It clearly distinguishes from sibling tools like list_allowlist and remove_from_allowlist by stating the add action and the domain format requirements.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context by explaining the effect of allowlisting (suppresses compound signal and brand impersonation floor) and that the full pipeline still runs. It does not explicitly name alternatives or exclude when not to use, but the purpose is unambiguous given the sibling names.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral details: pagination behavior, 90-day retention, and the distinction between free checks and those using pipeline credits. This goes beyond what the annotations state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short paragraphs, front-loaded with the main purpose, followed by concise pagination and retention details. Every sentence provides useful information with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description explains the return fields at a high level (URLs, scores, phishing status, free/credit) and covers pagination and retention. It lacks exact field names or sorting order, but is sufficient for a simple read-only list tool.

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

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

Schema description coverage is 100%, with both 'page' and 'limit' fully documented including defaults and max. The description repeats this information ('Default is 20 results per page, maximum 100') without adding new semantic meaning beyond the schema, so a 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 'View recent URL check history' with a specific verb and resource, and enumerates the fields shown (URLs, scores, phishing status, free/credit). This distinguishes it from sibling tools like check_url/check_urls which perform 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?

The description provides clear context by explaining pagination (default 20, max 100) and the 90-day retention period, with a note that account stats never expire. While it doesn't explicitly name alternatives, it implies when to use this tool (for recent history) versus get_stats (for permanent account-level data).

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

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

The description goes far beyond annotations by disclosing billing behavior (free vs. credit-charged lookups), the meta.pipeline_check_charged field, scoring dimensions, and the interpretive nature of the score ('a signal, not a verdict'). It also covers error handling (402) and caching semantics, which are valuable behavioral details.

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 a summary sentence, followed by clear sections on scoring, billing, and usage. Every sentence adds meaningful information, and the length is justified by the tool's complexity. No filler or repetition.

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 (multi-dimensional scoring, billing, custom profiles, error conditions) and lack of an output schema, the description provides a comprehensive picture. It covers return values, scoring dimensions, credit costs, response meta field, and 402 errors, making it sufficient for an AI agent to select 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?

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the profile parameter's purpose with a concrete example ('cold-email' profile) and clarifying that the url must be http/https. It also explains the billing implications of the url parameter, which enriches 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 single URL for security and data quality signals, distinguishing it from the sibling tool check_urls (plural) and other related tools. The verb 'Check' is specific and the resource (URL) and purpose (risk score) are explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool (single URL lookup) and references related tools like list_profiles and show_defaults for custom scoring. It does not explicitly compare against check_urls, but the 'single URL' phrasing implies the distinction. Billing and 402 error guidance helps with usage decisions.

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior. The description goes well beyond this by disclosing async processing, automatic polling with a 5-minute timeout, partial result behavior, deduplication, invalid URL handling, billing/credit charges, and 402 error conditions. This adds substantial contextual value.

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 long but well-structured into logical paragraphs covering purpose, processing dimensions, timeout behavior, billing, deduplication, and profile usage. Every sentence carries necessary information for using this complex batch tool effectively. It is front-loaded with the core purpose and adds details 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 the tool's complexity—async processing, billing, limits, error handling, and partial results—the description covers all critical facets. It explains what happens on timeout, how duplicates and invalid URLs are treated, credit requirements, and the return error message. The absence of an output schema is compensated by the detailed behavioral description. The coverage is comprehensive.

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 documentation covers 100% of parameters with descriptions, including max 500 items for `urls` and a description for `profile`. The description adds extra meaning by explaining the `profile` parameter's purpose ('score all results with custom weights') and describing deduplication behavior that affects `urls`. This goes beyond the schema but does not need to compensate for missing schema info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Check multiple URLs in a single batch.' The verb 'check' and resource 'URLs' are specific, and the plural form distinguishes it from the sibling `check_url`. It also adds unique handling details like async processing and auto-polling, fully differentiating it from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool, such as batch checks, and gives explicit guidance for large datasets ('call this tool multiple times'). It references `check_history` for retrieving results later and mentions billing affecting batching. However, it does not explicitly state when to prefer the sibling `check_url` (singular) over this tool, though the name and content imply it.

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

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

The description goes far beyond the annotations (readOnly=false, idempotentHint=true) by explaining that existing profiles are fully replaced (not merged), weights are points not percentages, and there's a 20-profile limit with a reserved 'default' name. This rich behavioral context is directly useful for the agent.

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?

While lengthy, every sentence earns its place: core action first, then key overrides, weight semantics, constraints, and practical examples. The structure with paragraph breaks and bullet-like lists makes it scannable. No fluff or repetitions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, but the description covers the full lifecycle: creation, update behavior, limits, reserved names, and how to verify results (check_url). It also points to external docs for more examples. This is complete for a create/update 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 already describes both parameters with 100% coverage, but the description adds crucial semantics: weights as points, not percentages; they need not total 100; the meaning of conservative vs aggressive totals; and examples of weight selections. This is a masterclass in parameter explanation 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 opens with a specific verb+resource: 'Create or update a custom scoring profile,' clearly distinguishing it from sibling tools like delete_profile, list_profiles, and show_defaults. It also clarifies the sparse override semantics, leaving no ambiguity about what the tool does.

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 usage guidance: use show_defaults before creating, use check_url or check_urls with the profile parameter to score results. It also includes common profiles for different use cases (cold email, security bot, lead gen, SEO audit), which is exemplary when-to-use guidance. No other tool in the sibling list overlaps with this function.

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

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

Annotations already indicate destructiveHint:true and idempotentHint:true. The description adds valuable context beyond annotations: it states deletion is permanent and that future requests using the profile name will fall back to default weights. This fully discloses the behavioral impact.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first states the action and permanence, the second gives usage guidance. It is front-loaded, concise, and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one param, no output schema) and comprehensive annotations, the description covers all necessary aspects: what it does, permanence, fallback behavior, and prerequisite guidance. No gaps remain.

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

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

The schema description coverage is 100%—the only parameter 'name' is already described as 'Name of the profile to delete' with a pattern. The description adds no additional parameter semantics beyond what the schema provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Delete a custom scoring profile', which is a specific verb and resource. It also differentiates from siblings like list_profiles and create_profile by focusing on deletion. The permanent nature and fallback behavior further reinforce the action.

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 advises 'Use list_profiles to see your current profiles before deleting', providing a clear prerequisite. It also explains the consequence of deletion ('fall back to default weights'), which helps the agent decide when this tool is appropriate.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses valuable behavioral traits: it is free and consumes no credits, classifies URLs into three gates (tranco, cached, unknown), does not follow redirects, and returns credits_min/max equal to the unknown count. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear opening, bullet-point details on gates, and a numbered typical flow. Every sentence adds necessary information—no filler or redundancy. It is appropriately sized for the tool's complexity.

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 a single parameter and no output schema, the description supplies all necessary context: purpose, free behavior, gate classifications, return fields, limits, and a recommended workflow. Annotations cover safety, so the tool is fully specified for the 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?

The input schema already lists the urls parameter with a clear description, so baseline is 3. The tool description adds meaning by explaining how the URLs are classified (tranco/cached/unknown) and the maximum batch size, giving the agent deeper understanding of what should be passed.

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 is a 'Pre-flight credit estimator for a list of URLs' with a specific verb ('estimate') and resource ('URLs'). It also distinguishes itself from siblings by explicitly instructing 'Call this before check_urls', making its unique role clear.

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 usage guidance: 'Call this before check_urls' and a 'Typical agent flow' with sequential steps. It also mentions concrete constraints like max 500 URLs and rate limit of 10 requests per minute, giving clear when-to-use and operational context.

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

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

The description reveals that the tool returns a '24-hour download link', which is a useful behavioral detail not present in annotations. However, it does not mention any side effects (e.g., resource consumption, storage) or error conditions. Given annotations are all false, the description carries some burden but remains limited.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the purpose, followed by a compact instruction and a clear statement of the return value. Every sentence earns its place with no redundancy or 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?

Given the tool has 5 parameters (3 required), a nested object, and no output schema, the description covers the essential context: what it does, what input to provide, and what to expect (24-hour link). It could mention prerequisites like email verification or cost, but it is adequate for this complexity.

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

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

The schema provides 100% coverage of parameter descriptions, so the baseline is 3. The description adds minimal extra meaning by grouping 'reseller details' and emphasizing the 'complete audit JSON object', but this largely duplicates the schema descriptions without adding new format or syntax details.

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 generates a 'branded PDF audit report', using a specific verb ('generate') and resource ('PDF audit report'). This distinguishes it from sibling tools, which focus on URLs, profiles, and purchases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear instructions on how to use the tool: 'Pass the complete audit JSON object and your reseller details.' It implies the tool is used after an audit is complete, but does not explicitly mention alternatives or when not to use it. This is clear context without exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description goes beyond by disclosing the criteria for credit consumption, the free lookup eligibility, and the behavior at zero credits. This adds valuable behavioral context that annotations cannot convey.

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 and front-loaded with the core purpose. Three paragraphs efficiently cover the purpose, consumption policy, and fallback behavior. Every sentence provides distinct value, with no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no parameters and no output schema, the description carries the full burden of explaining what the tool returns and when it is useful. It lists the return fields and explains the edge case of zero credits, making the tool fully understandable in context.

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

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

The tool has zero parameters, so the schema is trivially complete. The description does not need to explain parameters, and none of the text is spent on them. Baseline for 0 params is 4, which is appropriate here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Check your pipeline check credit balance.' It explicitly lists the output fields (credits remaining, total purchased, total used, lifetime free lookups), making the tool's purpose unmistakable and distinguishing it from all sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear when-to-use guidance by explaining the credit consumption model (unknown domains cost credits, known/cached are free). It also states what to do when credits are exhausted and directs users to the 'purchase' tool, an explicit 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond these annotations, such as 'This tool does not require an API key' and the explanation of when credits are consumed (only for unknown domains). This enriches the agent's understanding of the tool's behavior and domain 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?

The description is front-loaded with the main purpose, then presents the package list in a clear bullet-point format, followed by crucial usage details about free lookups and API key requirements. Each sentence earns its place; no unnecessary filler or 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 simplicity (no parameters, no output schema), the description is fully complete. It explicitly lists all packages with credit counts and prices, explains the credit consumption model, and notes the absence of an API key requirement. This is sufficient for an agent to understand the tool's behavior and return value without needing a formal output schema.

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

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

The tool has zero parameters, so the schema gives no parameter information. With 0 params, the baseline is 4. The description doesn't need to explain parameters and instead focuses on the return content, which 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's purpose: 'Show available pipeline check credit packages and pricing' and 'Returns all packages with credit counts and prices.' This is a specific verb+resource that distinguishes it from siblings like get_balance (which probably shows current balance) and purchase (which actually buys credits).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by listing pricing packages and noting that credits are only consumed for unknown domains, but it does not explicitly state when to use this tool vs alternatives like get_balance or purchase. No when-not or direct alternative comparisons are provided, so it relies on implied context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds meaningful context beyond annotations by explaining the semantics of the statistics (e.g., free rate = value per credit, score threshold counts). It does not contradict annotations, and the behavioral traits are transparent for a read-only stats endpoint.

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: a concise opening sentence, a clarifying second sentence, then a tight bullet list of use cases. All content earns its place, though the bullet list could be slightly condensed. It is front-loaded with the primary purpose, making it easy to scan.

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 (no parameters, no output schema), the description completely explains what the tool returns and how to interpret it. It also places the tool in a practical context (cost efficiency, scoring profile). No critical information is missing for an 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?

The tool has zero parameters, so the schema is trivially complete (100% coverage). The description adds no parameter-specific info because none exists, but it does explain the meaning of the output metrics, which is the relevant semantic value. 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's purpose: 'View your account usage statistics.' It lists specific metrics (total URLs, breakdown by gate, free rate, score thresholds, credit balance), which distinguishes it from siblings like get_balance (simple balance) and get_pricing (pricing). The verb+resource structure is specific and 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 'useful for' scenarios (checking scoring profile, understanding cost efficiency, reporting metrics), which gives clear context on when to use it. It does not explicitly mention alternatives or when not to use it, but the context is sufficient given the sibling set and the tool's self-contained nature.

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

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

Annotations already convey read-only, idempotent, non-destructive behavior. The description adds valuable context: allowlisted domains suppress the compound signal and brand impersonation floor, the full pipeline still runs, and monitoring remains possible. It also discloses return contents (list, count, limit). 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 three short sentences with the core purpose front-loaded. Every sentence earns its place, providing meaningful context without excess.

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, zero-parameter read-only tool, the description fully covers what it returns (list, count, limit), the behavioral effect of allowlisting, and the fact that it is a read operation. No output schema is needed because the return values are described.

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

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

There are zero parameters, so the baseline of 4 applies. The description correctly omits parameter details since none exist.

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 verb 'List' and resource 'all domains on this account's trusted allowlist' make the purpose unambiguous. It clearly distinguishes from sibling tools like add_to_allowlist and list_profiles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states 'Use this to see which domains are currently trusted' and explains the context of allowlisting effects. It does not mention when not to use it or alternatives, but the sibling names and the specificity of the description make the use case clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds valuable context beyond annotations: scoping to 'this account', the fact that profiles only override specific weights, and that unspecified signals fall back to defaults. This enriches the agent's understanding without contradicting 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 front-loaded with the core purpose in the first sentence. The subsequent paragraphs provide useful domain context, though the cold email/security bot examples are slightly illustrative and could be trimmed. Overall, it is well-organized and not overly verbose for the amount of context it delivers.

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 simplicity of the tool (no parameters, no output schema), the description covers the essential points: what is returned, the meaning of profiles, and how they relate to defaults. It references show_defaults for further detail. It could mention edge cases (e.g., empty list behavior) but that is minor for such a simple read-only 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 tool takes zero parameters and the schema is an empty object, so there is nothing for the description to add about individual parameters. Per the baseline for 0-param tools, a score of 4 is appropriate, and the description does not waste space on parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the exact verb+resource: 'List all custom scoring profiles on this account' and specifies what is returned ('profile names and their custom weight overrides'). It clearly distinguishes from siblings like list_allowlist (which lists allowlist entries) and show_defaults (which shows default weights), by focusing on custom profiles and overrides.

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 explains when profiles are useful ('Different use cases need different scoring') and explicitly points to an alternative: 'Use show_defaults to see all 25 signals and their default weights.' It also clarifies the relationship between profiles and defaults, giving the agent clear context for choosing this tool over show_defaults.

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

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

The description thoroughly explains the tool's behavior: it returns a URL the user must open, the AI cannot complete the payment, and credits are added asynchronously after Stripe confirmation. This goes well beyond the sparse annotations and provides essential operational 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?

The description is concise and front-loaded with the core purpose. Each subsequent sentence adds necessary guidance about the payment flow and follow-up, with no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides a complete operational picture: it explains the return value (a URL), the user's required action, and the post-purchase verification step. It lacks explicit error handling details but is sufficient for this straightforward purchase tool.

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

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

The schema fully describes the package parameter with an enum that maps to prices and credit amounts, so the description doesn't need to add more. It meets the baseline for high schema coverage, but no additional parameter guidance is given in the description.

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 purchase pipeline check credits and return a Stripe Checkout URL. It uses a specific verb and resource, and distinguishes itself from siblings like get_balance and get_pricing by focusing on the purchase action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use the tool (to buy credits) and directs the user to verify with get_balance afterward. It doesn't explicitly state when not to use it or offer alternatives, but the flow is well-defined.

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

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

With annotations already marking the operation as non-read-only, non-destructive, and idempotent, the description adds useful context: removal causes domains to 'resume normal scoring on the next check.' This explains the consequence and timing without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: the first states the action, the second explains the effect and offers a helpful precursor step. No wasted words, and the structure 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?

For a simple, single-parameter tool with complete annotations and no output schema, the description covers the action, consequence, and a usage recommendation. Nothing essential is missing.

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

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

The schema provides full documentation for the 'domains' parameter (description, constraints, examples). The description's phrase 'one or more domains' adds no new parameter-level meaning. Given 100% schema coverage, the baseline of 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 the action: 'Remove one or more domains from this account's trusted allowlist.' It uses a specific verb (Remove) and resource (allowlist), and differs from sibling tools like add_to_allowlist and list_allowlist.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context by recommending using list_allowlist before removal, but it does not explicitly mention when not to use the tool or alternatives beyond the implicit inverse of add_to_allowlist. This is strong guidance but falls short of explicit when/when-not coverage.

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?

Goes beyond annotations by disclosing critical behavioral traits: the response is always identical regardless of email existence/status to prevent account enumeration, and there is a rate limit of 3 per email per hour. Also states that no API key is required, which is not present in the 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 compact yet complete. It front-loads the purpose in the first sentence, then uses short paragraphs for usage context, security behavior, rate limiting, and authentication. Every sentence adds unique 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 single-parameter tool with no output schema, the description covers all essential context: what it does, when to use it, security considerations, rate limits, and authentication requirements. The absence of an output schema is mitigated by explicitly noting the uniform 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 single parameter 'email' already has a clear description matching the tool's purpose. The tool description does not add new parameter-level detail beyond what the schema provides, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence clearly states the action: "Resend the email verification link for an existing Unphurl account." This uses a specific verb (resend) and identifies the exact resource, distinguishing it from sibling tools like signup or create_profile.

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 when-to-use guidance: "Use this when a user signed up but their verification link expired... and they need a new one." It also notes the consequence of unverified email (API key won't work), which reinforces the use case. Does not explicitly mention alternatives, but none exist among siblings, so it is sufficient.

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

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

Annotations already mark the operation as read-only and idempotent. The description adds valuable context not present in annotations: 'does not require an API key' and 'defaults are hardcoded and always available.' This clarifies access and reliability without contradicting any 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 concise and front-loaded with the primary purpose in the first sentence. The subsequent sentences add context about the tool's role and accessibility with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with no parameters, the description fully covers its purpose, usage context, and accessibility. Even without an output schema, the first sentence explicitly lists the content of the output, making the description 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?

The tool has zero parameters, so the baseline is 4 per the rubric. The description appropriately focuses on what the tool returns (25 signals with weights and descriptions) rather than parameters, which are non-existent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb and resource: 'Show all 25 scoring signals with their default weights and descriptions.' It also distinguishes this from sibling profile-related tools by framing it as the baseline scoring for custom profiles.

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 actionable guidance: 'Use this to understand what each signal means and how much it contributes to the score before creating custom profiles.' This implies the tool is a prerequisite for profile creation, although it does not explicitly list alternatives or exclusion cases.

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

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

The description adds substantial behavioral context beyond the annotations: API key shown once, email verification required before use, free credits, and no API key needed for this tool. It does not contradict annotations; readOnlyHint=false aligns with the writing 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 appropriately sized for a tool with a multi-step workflow. It is front-loaded with the core purpose, and every sentence adds useful information about post-signup requirements, credits, or next steps. 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?

Given no output schema, the description fully covers the return value (API key), the verification process, expiration handling, credit behavior, and the auth requirement. It is complete for an account creation tool with these side effects.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific semantics beyond what the schema already provides; it focuses on the account creation flow rather than individual field meanings.

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 'Create a new Unphurl account' with a specific verb and resource. It explicitly differentiates from siblings like resend_verification and purchase by describing the account creation flow and pointing to those alternatives for different needs.

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 post-signup steps, including email verification and the 24-hour expiry. It names 'resend_verification' as the alternative for expired links and 'purchase' for additional credits, making the usage context and alternatives clear.

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