Squish

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

Annotations already cover read-only, open-world, idempotent, non-destructive, but the description adds what those can't: the exact returned payload shape, the no-login/public-site constraint, and an explicit honesty boundary that the grade measures visibility, not recommendation likelihood. That is genuine behavioral context beyond structured fields.

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

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

Front-loads the purpose, then the sub-checks, then the trigger conditions, then the caveat — a sensible order. It is on the long side, and the enumerated return-field list and honesty paragraph make it dense, but each part serves a distinct decision the agent must make.

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

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

There is no output schema, yet the description lists the returned keys (domain, grade, score, headline, readability, structure, legibility, posture, findings, remediation), so an agent knows what comes back. Combined with single-parameter input and clear trigger guidance, nothing needed to call it correctly is missing.

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

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

Schema coverage is 100% and already documents the domain format (no protocol or path). The description contributes the additional constraint that it must be a public website requiring no login, which meaningfully bounds which values are valid 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?

States a specific verb (check) and a precisely scoped resource: how legible and citable a business website is to AI answer engines, with an A-F grade. It enumerates the four sub-checks (crawler readability/JS rendering, structured data, Q&A content, crawler permissions), which clearly separates it from siblings like get_my_ai_visibility_coverage and plan_ai_visibility_fixes.

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

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

Gives explicit trigger conditions: someone asks whether AI/ChatGPT can find or read their business, mentions 'AI SEO'/answer-engine optimization, or wants a grade. Also states eligibility ('any public website — no login required'). It stops short of naming the sibling tools it supersedes or excludes (e.g. the coverage/plan tools), so it is clear context without full alternative routing.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the bar is lower, but the description still adds substantial value: the exact return shape, the partial-result edge case when no A record exists (ip null, domain-only lists, note field), and the fact that no login is required. These are behavior facts the annotations cannot express.

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

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

Purpose is front-loaded in sentence one, return shape and the edge case follow, and the usage triggers close. No redundant restatement of the tool name or title; every sentence carries a distinct payload.

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 enumerating the response fields, and it covers the one meaningful failure mode (missing A record). For a single-parameter read tool, an agent has everything needed to call it and interpret the result.

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 required `domain` parameter already documented with an example, so the schema does the heavy lifting. The description clarifies that IP-based lookups derive from the domain's A record rather than being a separate input, which is mild but real added meaning; 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?

Opens with a specific verb+resource ("Check whether a domain or its IP address appears on ... blacklists") and enumerates the actual blocklists consulted, so the agent knows exactly what is and isn't covered. This clearly separates it from siblings like check_email_auth or lookup_dns, which touch adjacent email/DNS territory.

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

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

Gives four concrete triggering situations (deliverability problems, blacklist status, spam folder complaints, IP reputation), which is strong when-to-use guidance. It stops short of explicitly excluding or naming the nearest sibling (check_email_auth) for overlapping email-deliverability questions, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the description's added value is auth/side-effect context: 'Works on any public domain — no login required' and the enumerated return keys. It does not mention rate limits or how partial/missing records are reported, keeping it below a 5.

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

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

Three tight sentences: capability and output first, then when-to-call triggers, then the access precondition. No filler and the most decision-relevant information is front-loaded.

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

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

There is no output schema, but the description enumerates the returned fields (domain, grade, provider, spf, dkim, dmarc, findings, migration), and it covers the sole parameter's constraint and access model. An agent has everything needed to call and interpret results.

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

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

Only one parameter with 100% schema description coverage, and the schema already says not to include protocol or path. The description's 'any public domain — no login required' adds marginal context but no new syntax or format guidance 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?

States a specific verb and resource ('Check a domain's email authentication posture') plus the exact protocols covered (SPF, DKIM, DMARC) and the output form (A-F grade). This clearly separates it from siblings like detect_email_provider, check_blacklist, and get_dns_records.

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

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

Gives concrete invocation triggers: deliverability questions, DMARC policy, SPF records, DKIM setup, spam complaints. It does not explicitly exclude or name alternatives (e.g. 'use get_dns_records for raw records only'), so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds value beyond them by disclosing the return payload keys and that 'No login required,' which tells the agent it can call this unauthenticated. Minor gap: no latency or rate-limit context for an open-world network call.

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 the verb and resource, then contents, return shape, and triggers — every sentence carries information. Slight inefficiency in placing the use-case sentence after the return-shape sentence, which buries the routing signal, and the header list is long but justified.

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

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

No output schema exists, and the description compensates by naming the returned fields ({ domain, grade, score, checks[], server }). Combined with the tested-header list, auth note, and trigger cases, an agent has everything needed to select and invoke this 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 a single parameter at 100% schema description coverage, the schema already fully documents 'domain' with an example. The description adds only the framing 'a website's... headers', confirming the domain is the target, but supplies no format details (protocol, subdomain, path handling). Baseline 3 applies.

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

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

States a specific verb and resource ('Check a website's HTTP security headers'), names the output artifact (A-F grade), and enumerates the exact headers tested. That enumeration distinguishes it from siblings like check_ssl or check_blacklist without needing to reference them by name.

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

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

Gives concrete trigger conditions: 'when someone asks about website security, why their site got a bad security score, how to improve their security headers, or what headers they're missing.' This covers the initiating intents well, though it does not state when to prefer a sibling (e.g. check_ssl for certificate questions) or any excluded case.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety bar is low. The description still adds real value: it states no login is required and that it works on public domains only, and it lists the return fields (validity, issuer, subject, expiry, days remaining, SANs, TLS version) in the absence of an output schema.

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

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

Three short sentences, front-loaded with purpose, then triggers, then scope/access constraint. Every sentence carries information; nothing is restated.

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 read-only lookup with no output schema, this covers purpose, invocation triggers, expected return data, and the no-auth/public-domain scope. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and the schema already documents the single 'domain' parameter with a format example. The description adds a semantic constraint the schema lacks — the value must be a public domain and no authentication is needed — which meaningfully bounds what to pass.

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

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

States a specific verb and resource ('Check the SSL/TLS certificate for a domain') and enumerates what it returns, which cleanly separates it from siblings like check_security_headers, check_uptime, or check_blacklist. An agent can route to it without opening the schema.

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

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

Gives concrete triggering conditions: customer asks about HTTPS, SSL errors, certificate warnings, or an expiring certificate. It stops short of naming alternatives (e.g. use check_security_headers for HSTS/CSP), so there is no explicit exclusion guidance, but usage context is clear.

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

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

Goes beyond the annotations by disclosing that both HTTPS and HTTP are tested, that the response includes timing and redirect detection, the exact return shape, and that no login is required — useful auth context not in the structured fields. It doesn't mention timeout behavior or what happens for non-resolving domains, so not a 5.

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?

Four tight sentences, front-loaded with what is tested, followed by the return shape and then the trigger scenarios. Every sentence carries information an agent would otherwise have to infer.

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 enumerating the returned fields, and it also covers the input meaning, usage triggers, and auth requirement. For a one-parameter read-only probe, nothing essential to correct invocation is missing.

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

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

Schema coverage is 100% and the single 'domain' parameter already carries an example format, so the schema does the heavy lifting. The description adds no constraint (e.g., scheme-less vs. full URL handling) beyond what the schema states — baseline 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?

Specific verb+resource: 'Check whether a website is up and reachable right now,' with the probe scope (HTTPS and HTTP, status code, response time, redirects) spelled out. It is implicitly distinguishable from neighbors like check_ssl or trace_redirects, but never names a sibling to draw that boundary explicitly.

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

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

Gives concrete trigger phrasing — 'is my site down?', 'why is my website not loading?', 'any question about site availability' — so the agent knows when to reach for it. It offers no when-not guidance or named alternative (e.g., when to prefer diagnose_my_server or get_my_site_health instead).

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

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

Annotations already cover readOnly/idempotent/non-destructive, but the description adds real context beyond them: the concrete endpoint called, that a wrong guess only affects post-migration UX and is easily corrected, and how to consume the result downstream. Some phrasing ('idempotent + side-effect-free, safe to call multiple times') merely restates the annotation hints, which keeps it out of 5 territory.

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 trigger timing, then return shape and downstream usage. It runs long and includes some conversational coaching with heavy capitalization, but nearly every sentence carries operational value rather than 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 does the work of describing the return shape ({likelyProvider, confidence, ...}) and how to use it, plus a note on the consequence of an incorrect result. Only a slight gap remains on error/failure behavior when the endpoint cannot classify a domain.

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 is self-evident, so the baseline is 3; the description earns above baseline by explaining the value chain — take likelyProvider and pass it to start_email_migration as `source` — which is semantics the schema cannot express.

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

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

States a specific verb and resource (inspect a customer's email domain via getuserrealm.srf) and a precise decision outcome (Microsoft direct vs. GoDaddy resale). An agent can distinguish it from every sibling check_* tool without opening the schema.

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

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

Explicit timing ('IMMEDIATELY after the customer gives you their email domain'), explicit precondition ('BEFORE asking is it Microsoft Direct or GoDaddy'), and an explicit anti-pattern ('NEVER respond to a you tell me? question with I can't tell'). This is textbook when-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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: 'No login required' (an auth prerequisite the agent couldn't otherwise know) and the concrete return shape. It doesn't mention rate limits, caching, or what an empty result means for an unreachable site.

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

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

Three sentences, front-loaded with the capability and followed by return shape then usage triggers; each sentence carries distinct information. The vendor example lists ('WordPress, Shopify, Drupal, etc.') add mild bulk but are functional for intent matching.

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

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

No output schema exists, and the description compensates fully by spelling out the returned object ({ domain, cms, cdn, server, framework, metaGenerator, analytics[] }). Combined with the auth note, an agent has everything needed to call this correctly on the first attempt.

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

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

There is a single parameter with 100% schema description coverage, and the schema already provides the format example ('example.com'). The description adds no detail on domain normalization, subdomains, or URL-vs-domain input, so it does not exceed the baseline the schema already earns.

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

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

States a specific verb (detect) and resource (technologies of a website) and then enumerates exactly what it covers: CMS, CDN, web server, frontend framework, analytics, with concrete vendor examples. An agent can distinguish this from lookup_whois or check_ssl purely from the description.

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

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

Gives four explicit user-intent triggers ('what platform a site runs on', 'what CMS a competitor uses', 'what CDN a site is behind', 'what stack powers a website'), which is strong positive routing. It stops short of naming a sibling like detect_web_host or lookup_ip_hosting to say when this tool is the wrong choice, so no exclusions are specified.

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 only say read-only/idempotent/open-world; the description adds the critical interpretive constraint that originHidden=true means the real host is unknown and the CDN must not be reported as the host. It also discloses no-login availability and describes the result shape (confidence, evidence, host.kind enum). This is disclosure beyond what structured fields provide.

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?

Purpose and scope are front-loaded in the first clause, followed by return shape, then the caveat, then usage. The inline enumeration of return fields and the host.kind values is dense but useful for a schemaless return; only minor trimming would help.

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

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

There is no output schema, so the description carries the return contract itself — it names every top-level field and the host.kind vocabulary, plus the originHidden interpretation rule. An agent can both call this correctly and report its result honestly without further 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?

Only one parameter and schema coverage is 100%, so the schema already fully documents 'domain' including an example. The description adds nothing about domain format, subdomain handling, or normalization rules, so baseline 3 applies.

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

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

States a specific verb and resource ('Find out WHO HOSTS a website') and enumerates exactly what is resolved: hosting company, CDN, DNS provider, email provider. It explicitly distinguishes itself from the similarly-named detect_technology sibling, which removes the main ambiguity an agent would face.

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

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

Gives concrete triggering questions ('who hosts a site', 'who a competitor hosts with', 'where a site they inherited is running') and an explicit alternative with its condition ('For the CMS/stack running on top, use detect_technology instead'). This is the when-to-use / when-to-use-something-else pattern at full strength.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial behavior beyond them: the not_applicable shared-hosting outcome, the meaning of agentReporting=false (server not confirmed healthy, just unobservable), and the rule to only mention upgrading when upgradeSuggested is true. That is exactly the kind of interpretation guidance 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?

Purpose and scope are front-loaded in the first sentence, followed by usage triggers, alternatives, and output-handling rules in a logical order with no filler. It is on the long side because of the output narration instructions, but each sentence carries actionable content rather than padding.

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

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

No output schema exists, so the description correctly compensates by naming the key return fields (`summary`, `findings`, `agentReporting`, `upgradeSuggested`) and prescribing how to present them. Combined with the plan-scoped diagnostics and hosting-type caveat, an agent has everything needed to call and interpret the result.

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

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

There is a single optional parameter at 100% schema description coverage, so the schema already explains `domain` as the site to diagnose. The description adds only the mild constraint that it is optional when the customer has exactly one site, which is essentially a restatement. 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?

States a specific verb and resource (diagnoses performance of the customer's own VPS) plus the exact signal domains it covers: CPU load vs. plan vCPU count, memory pressure, disk fullness. It explicitly distinguishes itself from check_uptime (reachability) and get_my_site_health (history), so an agent can route without opening a schema.

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

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

Gives concrete trigger phrasings ("why is my site slow?", "do I need a bigger plan?") and explicit exclusions with named alternatives for reachability and uptime history. It also states the shared-hosting case returns not_applicable and instructs the agent to say so rather than guess.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is clear. The description adds the returned field list and repeats that the operation is read-only, but does not discuss PII sensitivity, permissions, or any limits. With annotations covering the safety behavior, this is adequate but modest.

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

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

Three short sentences: field list, usage examples, and read-only note. The content is front-loaded and every sentence contributes useful selection or behavior information.

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

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

For a zero-parameter, read-only profile lookup with no output schema, the description provides enough content by listing the exact fields returned and giving usage examples. It does not need to explain inputs or return structure beyond the field enumeration, though it could mention sensitivity or freshness of the on-file data.

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 parameter semantics are not applicable and the baseline is high. The schema is empty and fully described by virtue of having no inputs, and the description correctly does not invent parameter behavior.

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

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

The description names a specific verb and resource — returning the customer's profile — and enumerates the exact fields returned (name, email, phone, billing address, company, account number). This clearly separates it from sibling catalog, DNS, and diagnostic tools, though it does not explicitly name an alternative.

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

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

It gives concrete user-intent examples such as “what's my address on file?” and “what's my account number?”, which tells the agent when this tool is appropriate. It lacks explicit when-not conditions or named alternative tools, so it is clear but not fully prescriptive.

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, the description explains the catalog shape, SKU-keyed entries, field meanings, pricing comparison caveats, base-tier requirements, bundled-free cases, and how to handle selfServe=false items. It also clarifies that unlisted discounts or cheaper-than-direct claims should not be made unless the catalog shows them.

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

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

The description is front-loaded with purpose and the mandatory call-before-quoting rule, then uses bullets to structure return fields and handling instructions. It is longer than a simple catalog tool might need, but the detail earns its place because no output schema exists and the pricing semantics are nuanced.

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 supplies the return structure, field meanings, pricing interpretation, base-tier constraints, free-bundling behavior, and purchasing caveats. Combined with annotations covering read-only safety, this is complete enough for correct invocation and downstream use.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; the schema is empty and fully covered. The description correctly focuses on return data and usage rather than inventing parameter guidance.

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

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

The description states a specific verb and resource: fetch the canonical Squish email add-on catalog with current pricing. It also names representative products and distinguishes this from get_email_catalog, so an agent can identify its scope without opening the schema.

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

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

It gives a strong imperative usage rule: call this before quoting any add-on price, and do not guess from memory. It references get_email_catalog as related doctrine, but does not explicitly state when to use that sibling instead, so it falls short of full when/when-not 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: the catalog is authoritative and changes over time, domain rate factors are always pass-through 1.0, email is 12-month-only with no multi-year promise, and there are hard constraints on framing vocabulary.

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 the action and the trigger, followed by shape and math sections that earn their place. It is dense but slightly redundant with two 'CRITICAL' blocks and a repeated framing warning, which costs it a point.

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

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

There is no output schema, so the description supplies the return shape, the per-category structure, the rate-factor math, and the domain/email exceptions. That is exactly what an agent needs to call it and use the result 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?

Zero input parameters, so there is nothing to document on the input side and the baseline of 4 applies. The description usefully redirects that space into describing the return shape and math instead.

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

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

Specific verb + resource: 'Fetch the canonical Squish billing-term catalog.' It immediately distinguishes itself from catalog siblings (get_hosting_catalog, get_public_pricing) by declaring this is the rate-factor/term source of truth.

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 trigger: 'CALL THIS before quoting ANY multi-year rate (2-year, 3-year hosting; 2-10 year domain registration).' It also names the prohibited alternative ('never quote a rate factor or percentage from memory') and constrains email to 12-month quotes only.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds real value beyond that: it pre-checks domain ownership and returns a clear error if the domain isn't on the account, which an agent needs to interpret failures correctly.

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

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

Front-loaded with the core behavior, then examples, then pre-check behavior — good ordering with no filler. The three example queries are slightly redundant with each other but each illustrates a distinct lookup style, so the cost is small.

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

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

With no output schema, the description carries return-value burden and does reasonably: it names the record types returned and the error case. It omits response shape/ordering details and doesn't clarify how results differ from lookup_dns, leaving minor gaps for an otherwise simple read 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?

Only one parameter with 100% schema coverage, so the baseline is 4. The description reinforces the ownership constraint ('a domain the customer owns'), matching the schema description without adding contradicting detail.

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

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

States a specific verb and resource ('Returns the DNS records currently set on a domain') and enumerates record types (A, AAAA, CNAME, MX, TXT, NS) with a concrete analogy ('same data as the registrar's DNS panel'). It doesn't differentiate from the sibling lookup_dns, which is the main gap.

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

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

Gives explicit trigger examples ('what's my A record on x.com?', 'show me my MX records'), which directly maps user intent to this tool. It stops short of naming alternatives like lookup_dns or list_my_domains, so the agent must still infer which DNS-related sibling to pick.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the closing 'Read-only, no side effects, safe to call freely' merely restates them. What the description adds beyond annotations is genuinely valuable: the semantic trap between Squish 'Essentials' and Microsoft's legacy 'Business Essentials', and the reseller-markup rule ('never claim we're cheaper than Microsoft if msDirectAnnual < annual') that governs downstream claims.

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 imperative call directive is front-loaded, followed by a clean field-by-field breakdown, so scanning works well. It is on the long side and includes some redundancy (the read-only sentence duplicates annotations, and the 'around $5/mo' illustration could be trimmed), but essentially every block carries operational 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?

There is no output schema, so the description must document the return shape — and it does, field by field (label, msProductName, monthly, annual, msDirectAnnual/msDirectMonthly, selfServe) including the meaning of selfServe=false as E3/E5 sales-led. Nothing material is left for the agent to discover at call time.

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

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

The tool takes zero parameters, so the schema carries no semantics for the description to supplement — baseline 4 applies. The description instead spends its space on return-field semantics, which is the right allocation for a no-arg tool.

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

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

The description names a specific verb and resource — 'Fetch the canonical Squish email product catalog with up-to-date pricing' — and scopes it to email tiers, which separates it from the hosting/addon/public-pricing siblings without needing to name them. An agent knows exactly what corpus of data this returns.

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

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

It gives an explicit, non-negotiable trigger ('YOU MUST CALL THIS BEFORE QUOTING ANY EMAIL TIER PRICE') plus explicit exclusions ('Do not guess prices from memory', 'Do not paraphrase'). The anti-patterns it forbids are concrete, which is better routing guidance than most catalog tools get.

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?

Although annotations already declare readOnly, idempotent, and non-destructive behavior, the description adds substantial operational context beyond them. It discloses the catalog grouping, per-entry fields, the hard self-serve guard, and the server-side refusal to provision or bill selfServe:false add-ons. It also clarifies sales behavior around the Faber Token Pack and Site Patrol, which is exactly the kind of contextual behavior an agent needs.

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 purpose and catalog structure, then uses clear headings for when to mention add-ons and the self-serve guard. It is longer than a typical catalog-fetch description, but most sentences carry actionable policy or routing information; there is little 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 around sales policy, self-serve restrictions, and catalog entry semantics, the description is complete enough for an agent to call it correctly and use the result correctly. No output schema exists, but the description explains the returned fields and the key guardrails in sufficient detail.

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

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

The tool has zero parameters, so schema semantics are not a concern and the baseline is 4. The description instead documents return-entry fields such as family, priceDisplay, monthly, oneTime, grantsEdits, selfServe, and appliesToCategories, which is useful context but belongs more to output semantics than parameter semantics.

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

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

The description states a specific verb and resource: fetch the canonical Squish hosting add-on catalog. It clearly distinguishes this catalog from sibling catalogs by naming what it contains (control panels, backups, monitoring, Faber Token Pack) and by explicitly routing Faber plan questions to get_hosting_catalog. An agent can identify the right tool without opening the schema.

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

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

It gives explicit when-to-use triggers, such as any question about control panels, managed backups, monitoring, or 'can I add' hosting questions. It also names alternatives and exclusions: use get_hosting_catalog for the Faber plan, do not proactively pitch Site Patrol, and route selfServe:false add-ons to sales rather than presenting them as purchasable.

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 this as read-only, idempotent, non-destructive, and closed-world, but the description adds substantial behavioral context. It explains verbatim price quoting, self-serve versus sales-led routing, panel add-on rules, and specific positioning constraints that affect how an agent should act on the returned 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 long but well structured with front-loaded mandatory instructions, headings, and bullet lists. Some details are repetitive, such as repeated emphasis on quoting verbatim and not guessing, but the length is largely justified by the complexity of pricing rules and product positioning.

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

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

There is no output schema, so the description carries the burden of explaining return values, and it does so thoroughly by documenting each catalog entry field. It also covers alternatives, routing rules, and important product constraints, making the definition complete for an agent to call and 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?

The tool has zero input parameters, so there is no parameter semantics burden; the baseline for zero-parameter tools is 4. The description instead explains return-entry fields, which is useful but not relevant to input parameter interpretation.

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

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

The description states a specific verb and resource: fetch the canonical Squish hosting product catalog with up-to-date pricing. It explicitly distinguishes this tool from get_hosting_addons_catalog and get_email_catalog, so an agent can identify its role without inspecting sibling schemas.

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

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

It gives explicit usage rules: call before quoting any hosting price, do not guess, and use get_hosting_addons_catalog for VPS add-ons. It also provides positioning rules for common customer asks, including Cloud Custom, the obsolete Starter tier, and Faber by Squish.

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

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

Beyond the readOnlyHint annotation, the description discloses the downstream consequence of an upgrade (card on file is charged), where confirmation happens (dashboard only), and that proration is computed there. It also enumerates the returned dimensions: tier, monthly sticker, eligibility and reason. This is the kind of context annotations cannot carry.

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

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

Front-loaded with the core answer (what the tool returns) before the caveats, with no filler. The sentences are dense and clause-heavy, which costs a little readability, but every sentence carries information an agent needs.

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

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

No output schema exists, so the description must convey the return shape, and it does: tiers, monthly prices, eligibility and denial reasons, plus the note that the exact amount due is not returned here. Combined with the readOnly annotation and single documented parameter, an agent has everything needed to call it 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?

Only one parameter, and the schema documents it fully (100% coverage: 'The hosting site's domain'). The description reinforces the per-site scope ('one of the customer's hosting sites') but adds no syntax, format, or accepted-value detail beyond the schema. Baseline 3 applies.

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

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

States a specific resource and scope: the higher plan tiers a single customer-owned hosting site can move to, including price and eligibility with reasons. This is functionally distinct from catalog/pricing siblings, but no sibling is named, so an agent must infer the split from wording alone.

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

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

Gives explicit trigger phrasing ('can I get a bigger server?', 'what would it cost to upgrade?') and an explicit boundary: the exact prorated amount due is shown only in the dashboard, and the charge is confirmed there, never by a tool. That tells the agent both when to call this and what it must not attempt.

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=false, and the description's closing 'Read-only.' reinforces rather than contradicts them. Beyond that it discloses what the response contains and the CONSENT_PENDING case, which annotations cannot express; it doesn't cover error behavior for an unknown migrationId.

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 the outcome, then usage triggers, then the safety note. The middle clause is a long comma-separated enumeration, but every listed field earns its place given there is no output schema.

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

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

With no output schema, the description carries the return-value burden and does so thoroughly, including stage state and the consent URL condition. Combined with 100% parameter coverage and a full annotation set, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100% and the single migrationId parameter is already documented as coming from start_email_migration or list_my_migrations. The description adds no further semantics such as format or validity expectations, so baseline 3 applies.

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

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

States a specific verb and resource ('Get the full state of a single email migration') and then enumerates exactly what state is returned (stage, tenant ID, SKU mapping, cutoverAt, consent URL, failure info). The word 'single' plus the required migrationId distinguishes it cleanly from the sibling list_my_migrations, which returns many.

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

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

Gives concrete trigger phrasings ('how is my migration going?', 'give me the consent link') and a positional cue ('before driving the next stage'), so an agent knows when to reach for it. It stops short of saying when NOT to use it or naming list_my_migrations as the alternative for discovering IDs.

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 declare read-only/idempotent, and the description adds genuinely new behavior: the call is refused when AI Visibility is absent from the plan, and a null grade means unscanned, which must be reported as "pending", never "passing". That last instruction actively prevents a plausible hallucination, which is high-value disclosure beyond 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?

Dense and front-loaded: the resource is stated first, then the contents, then the refusal rule. It is a single long sentence with parenthetical asides, but nearly every clause carries operational meaning; only "Read-only" is redundant with the annotations.

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

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

With no output schema, the description does the necessary work of describing the returned fields (domains, verification, grade, slot counts) and the refusal case. It stops short of explaining how slot usage is represented or what verification values look like, which leaves a small gap for a tool whose return shape is undocumented elsewhere.

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 documented parameter ("The hosting plan's domain"). The description only obliquely reinforces this via "the plan's own site", adding no format, validation, or matching detail beyond the schema, so baseline 3 applies.

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

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

Opening clause names the specific resource: the domains an AI Visibility plan watches, plus their verification method, latest grade, and slot usage. It is clearly a read of plan coverage rather than a scan, but it never names the sibling check_ai_visibility that an agent might confuse it with.

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?

'Refused when AI Visibility is not on the plan' gives the agent one useful precondition for calling it. However, there is no statement of when to prefer this over check_ai_visibility or plan_ai_visibility_fixes, so the agent must infer the distinction from the name alone.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely non-obvious behavior: results are plan-dependent, and on shared hosting per-site traffic does not exist (stats: null, perSite: false). That is exactly the kind of surprise an agent needs pre-warned.

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 core answer is front-loaded in the first sentence, then qualified by plan tier, then examples. It is dense but every clause carries signal; the parenthetical restatement '(stats: null, perSite: false)' is slightly redundant with the preceding sentence.

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

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

There is no output schema, and the description compensates by explaining the two possible response shapes and why they differ. A single-parameter read tool needs nothing further to be called correctly.

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

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

Schema coverage is 100% and the single 'domain' parameter is documented there, so the baseline applies. The phrase 'one of the customer's hosting sites' mildly constrains what domain means (a hosted site, not arbitrary domain), but there is no format or error guidance added.

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

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

Opens with a specific verb and resource ('Returns whether the CDN (edge cache) is on...') and enumerates the returned metrics (requests, bandwidth, cache hit rate). An agent can distinguish this from get_my_site_health or get_my_site_runtime without opening the schema.

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

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

Gives concrete user phrasings that should route here ('is my CDN on?', 'how much traffic is my site getting?', 'is the cache working?'), which anchors usage well. It does not name a sibling alternative or state when NOT to use it, so it stops short of a 5.

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

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

Annotations already cover read-only/idempotent/non-destructive, yet the description still adds real behavioral context: what each status means operationally, that refused includes the reason to fix, and that pending_registry usually completes in about five days. The 'never here' note reinforces the read-only contract with an actionable constraint.

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?

Purpose is front-loaded, and the trailing sentences each carry a distinct payload (cartId scoping, when to use, the dashboard-only constraint). The status parenthetical is dense but each definition is load-bearing for interpreting results, so little could be cut without losing meaning.

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

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

One optional parameter, no output schema, annotations covering safety — the description fills the remaining gap by explaining what the returned status values mean. Nothing an agent needs to call or interpret this tool is missing.

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

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

Schema coverage is 100% and the single cartId parameter is already documented as the value returned by prepare_domain_transfers. The description's 'Pass cartId to see one checkout's batch' adds only the framing of a batch view, so the baseline 3 for a fully documented single parameter applies.

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

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

States a specific verb-plus-resource ('where the customer's inbound domain transfers stand, one row per domain, with counts') and enumerates the exact status buckets returned. That distinguishes it cleanly from list_my_domains (all domains) and get_migration_status (site moves) without the agent needing to open a schema.

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

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

Gives explicit trigger conditions: 'Use after prepare_domain_transfers, or when they ask "did my transfers go through?"'. It also draws a hard boundary — 'Codes are entered in the dashboard, never here' — preventing the agent from attempting a mutation this tool cannot do.

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?

Although annotations already declare read-only, idempotent, non-destructive behavior, the description adds substantial operational guidance: lead with each site's `disclosure`, relay `measurementNote` when `measurementHealthy` is false, and never invent figures when `coverage` is 'none'. These are behavioral constraints beyond the structured fields and are essential for correct use.

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, then immediately routes to the alternative tool, then states critical response-handling rules. Despite its length, each sentence serves a distinct selection or usage purpose, with only minor redundancy in the trailing 'Read-only.'

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

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

For a read-only monitoring tool with no output schema, the description supplies the missing behavioral context: historical vs live scope, optional domain behavior, and how to handle `disclosure`, `measurementHealthy`, `measurementNote`, and `coverage`. That is enough for an agent to call and interpret the tool correctly.

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

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

Schema description coverage is 100%, so both `days` and `domain` are already documented in the schema. The description mentions domain scoping and notes that scoping returns recent outages, but this largely duplicates schema wording and does not add new syntax or interpretation beyond it.

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

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

The description uses a specific verb and resource: 'Returns MEASURED uptime history for the customer's own hosted sites' over a trailing window from SLA monitoring. It explicitly distinguishes itself from the sibling check_uptime, so an agent can tell which tool to pick without opening either schema.

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

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

It gives explicit when-to-use examples ('how has my site been?', 'has my site gone down?', 'did you have an outage last week?') and a direct when-not rule contrasting with check_uptime for live 'is my site up?' checks. The optional domain scoping behavior is also described.

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/closed-world, so the bar is lower, but the description still adds real context: data is read from the server, updatedAt means when Squish applied the build, and Squish (not the customer) patches shared servers. It stops short of describing failure behavior for a non-shared or unknown domain.

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 what is returned, then when to call, then exclusions. Dense and largely waste-free, though the quoted-query sentence and the patching-responsibility aside make it longer than strictly needed.

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

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

With no output schema, the description compensates by naming the returned fields and their granularity. Coverage is nearly complete; the only gap is what the tool does or returns when the domain isn't a shared hosting site.

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?

Single required parameter with 100% schema description coverage, so the schema already carries the definition. The description adds only a mild constraint that the domain belongs to the customer's SHARED hosting site, with no format or normalization guidance.

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

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

States a specific verb and resource ('Returns what one of the customer's SHARED hosting sites actually runs, read from the server') and enumerates the exact fields returned (PHP version to patch level, handler, build update date, installed builds, control panel, OS). This clearly separates it from siblings like detect_technology, get_my_site_health and diagnose_my_server.

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 prescribes invocation with 'CALL THIS for "what PHP version am I on", "am I patched for <CVE>", "is my server up to date"' and gives an explicit exclusion ('A Managed Cloud server is not covered here'). It also explains the domain/ownership model, so the agent knows who owns patching.

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, openWorldHint and destructiveHint=false, so safety is covered; the description adds real value on top by noting 'live' data (not a stale snapshot) and 'No login required', which is a genuine auth precondition an agent would otherwise have to discover. It stops short of disclosing rate limits or response shape, but with no output schema and full annotation coverage a 4 is fair.

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 the resource and the section inventory, then the imperative call guidance, then the edge case, then the auth note — a sensible priority order. The parenthetical section glosses are dense but each one carries decision-relevant detail (e.g. 'first-year floor AND renewal prices for the headline endings only'), so little is wasted.

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

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

There is no output schema, so the description must carry the return contract itself, and it does — naming all six catalog sections and summarizing what each contains, plus what a `tld` query returns. Combined with the usage trigger and auth note, an agent has everything needed to call this correctly on the first try.

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, but the description earns above baseline: it explains that `tld` works for ANY ending including ones not in the catalog, that the domains section covers only 'headline endings' while `tld` covers the long tail, and that tld results include first-year, renewal AND transfer-in prices. That is behavioral meaning the enum/param descriptions do not fully carry.

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

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

States a specific verb (fetch) and resource (live public Squish pricing catalogs) and enumerates exactly what each section returns, so an agent knows the payload shape before calling. The one gap is sibling differentiation: get_hosting_catalog, get_email_catalog, get_addon_catalog and get_billing_terms overlap almost one-for-one with this tool's sections, and the description never explains that this is the public/live counterpart to those account-scoped catalogs.

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

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

Gives an explicit trigger ('CALL THIS whenever you are about to state an exact price, renewal, spec, or term rate that you cannot see in the Squish Services block') and an explicit prohibition ('never quote catalog numbers from memory'). It also routes the edge case: for any non-headline domain ending, pass `tld` and the result carries first-year, renewal and transfer-in prices.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the bar is lower; the description reinforces read-only and adds real value by describing exactly which state fields come back (kind, phase, progress, preview, connection existence) and by routing mutating actions to the dashboard. It does not cover auth requirements or behavior when no import exists for the domain, which keeps it short of a 5.

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?

It is front-loaded with the resource and the returned state, then usage cues, then the out-of-scope actions and a one-word read-only confirmation. The first sentence's dense parenthetical enumeration costs some readability, but every sentence contributes.

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

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

With no output schema, the description must convey what comes back and it does: can-start status, run kind/phase/progress, preview awaiting go-live, and WordPress connection presence. Combined with the dashboard pointer for mutations and the read-only annotation, an agent has enough to call this correctly for a simple one-parameter read.

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

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

There is a single required parameter with 100% schema description coverage, so the schema already carries the weight and baseline is 3. The description only indirectly adds meaning by clarifying that the domain identifies 'one of the customer's hosting sites' (i.e., a hosting site, not an arbitrary or external domain), which is a marginal supplement.

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

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

The description states a specific verb and resource: the status of a 'Move a site here' import for one hosting site, and it enumerates what the response covers (whether an import can start, current run kind/phase/progress, pending preview, WordPress connection). This is far more specific than the name alone, though it never names the adjacent siblings get_migration_status or list_my_migrations, so an agent must infer which one to pick when a user says 'migration'.

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

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

It gives concrete trigger phrases ('is my site move done?', 'what is happening with my import?') and an explicit when-not: starting, going live with, or discarding an import is done in the dashboard, not here. It stops short of pointing at the sibling tools that cover list-level or migration-level views, so alternative selection is only partially resolved.

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, non-destructive behavior, and openWorldHint. The description adds useful behavioral context beyond annotations: no login is required, output is grouped by area, each entry includes read/write status, required scope, and availability to the current session. It does not need pagination or mutation details for a zero-parameter 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?

It is front-loaded with what the tool returns, immediately followed by explicit call conditions and relay guidance. Despite being information-dense, every sentence serves a distinct purpose: output scope, triggers, presentation style, and authentication requirement.

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 input parameters, no output schema, and read-only annotations, the description supplies everything an agent needs: what it returns, the grouping and metadata per tool, when to call it, how to relay results, and that no login is required.

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 parameter semantics are not a meaningful source of ambiguity and the baseline is high. The description correctly avoids discussing parameters and instead clarifies the structure of the capability listing.

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 gives a specific verb and resource: lists everything a Squish connection or assistant can do, grouped by areas and annotated with tool metadata. It is unmistakably distinct from all operational sibling tools like check_ssl or list_my_domains because it is explicitly a capability inventory.

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

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

It names exact triggering questions: what you can do, what the connection can do, what a read-write key adds, or whether something is possible over MCP. It also gives a behavioral instruction to relay areas in plain words and name tools only on request.

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 'Read-only' restatement adds little. The description does add real behavioral context beyond the annotations: the shared-hosting-only coverage boundary and the three fields returned (id, timestamp, size).

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 the core action and its scope, then the ordering constraint, then the exclusion. The quoted user-phrasings earn their place by matching likely utterances; no filler sentences.

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

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

With no output schema, the description compensates by naming the returned fields and confirming read-only behavior. For a one-parameter list tool, everything an agent needs to select and call it correctly is 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 description coverage is 100% and the single `domain` parameter is fully documented there with an example and account constraint. The description only reinforces the shared-site constraint implicitly, which is minor added meaning, so baseline 3 applies.

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

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

States a specific verb and resource ('Lists the restore points (daily backups)') plus scope ('one of the customer's SHARED hosting sites') and even the returned fields. It explicitly excludes VPS snapshots, so an agent can distinguish it from adjacent hosting tools without opening the schema.

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

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

Gives explicit triggers ('what backups do I have?', 'can I roll my site back?') and a hard ordering rule ('ALWAYS before restore_my_site_backup so the backupId is a real one'), plus a when-not ('A VPS is not covered here'). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so the bar is lower, and the description adds real value beyond them: newest-first ordering and the exact meaning of openOnly ('still open (not Closed)'). The trailing 'Read-only' merely restates the annotation and the description says nothing about truncation or result-count behavior beyond limit.

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 return fields, then usage triggers, then the behavioral note — a sensible order with no wasted sentences. The four example queries are slightly padded but justified as routing aids for a conversational trigger like 'check on my open support ticket'.

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 correctly compensates by listing the returned fields (number, subject, status, priority, opened date) and the ordering. It is nearly complete for a two-optional-param read tool; only the behavior when limit is omitted versus capped is unspecified, which the schema covers anyway.

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 both parameters are already documented in the schema, including the default 10/max 25 and the openOnly definition. The description restates the openOnly semantics without adding syntax or format detail beyond what the schema already 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?

States a specific verb+resource ('Returns the customer's support tickets (Salesforce Cases)') and enumerates the returned fields, so an agent knows exactly what it gets. No sibling tool touches support cases, so there is no ambiguity with the hosting/DNS/lookup tools in the list.

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

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

Gives an explicit trigger condition ('Use whenever the user asks about a support ticket or case') backed by four realistic user utterances, which is strong routing guidance. It stops short of naming exclusions or alternatives, though none of the sibling tools plausibly overlap.

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, destructiveHint=false and idempotentHint=true, so the trailing "Read-only" adds nothing. The useful addition is the ownership scope ("domains the customer owns through Squish") and the field list, but nothing about ordering, pagination, or empty results.

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

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

Three short sentences, front-loaded with what is returned, followed by usage triggers and safety note. Nothing is redundant or padded.

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 does the work of sketching the return shape (status, order number, purchase date), which is important here. It could say more about ordering or whether inactive/expired domains are included, but it is sufficient 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The schema itself is an empty object, so no semantics are lost.

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

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

States a specific verb and resource - returns domains the customer owns through Squish - and enumerates the fields returned (status, order number, purchase date). This clearly separates it from search_domains or lookup_whois, though it never names a sibling explicitly.

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

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

Gives concrete trigger phrasing ("what domains do I have?", "which domains am I paying for?") that maps user intent to this tool. It stops short of stating when NOT to use it or naming alternatives like search_domains for acquisition-style lookups.

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

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

Annotations already declare readOnlyHint/idempotent/non-destructive, and the description adds real value by enumerating the returned fields and setup-type values, which is the only source of return-shape info since there is no output schema. Minor gap: no mention of pagination or behavior for accounts with zero provisioned sites, but the trailing 'Read-only' confirms rather than contradicts 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?

Three sentences with strict front-loading: payload first, invocation triggers second, safety note last. The quoted user phrasings are compact and each directly earns its place as a routing cue.

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, read-only list tool with no output schema, the description supplies purpose, returned fields, and trigger contexts — everything an agent needs to select and call it. The annotations carry the safety profile, so nothing material is missing.

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

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

The tool takes no parameters (empty object schema), so there is nothing for the description to disambiguate. Baseline 4 applies; nothing is gained or lost 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?

States a specific verb and resource ('Returns the list of hosting sites the customer has provisioned') plus the exact payload fields (panel URL, setup type, Plesk login). This clearly separates it from nearby siblings like list_my_domains, get_hosting_catalog, or get_my_site_runtime.

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

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

Gives concrete trigger phrasing ('what sites do I have?', 'where do I log in to my hosting?', 'what's my hosting panel URL?'), which is strong routing signal. It stops short of naming alternatives or exclusions (e.g., when to prefer get_hosting_catalog for purchasable plans), so it lands at clear-context-but-no-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, idempotentHint, destructiveHint=false and openWorldHint=false, so the trailing "Read-only" sentence is largely redundant. The one genuinely additive behavioral fact is that results include every state rather than only active or only completed ones. Nothing is said about ordering, truncation, or cursor/paging behavior beyond the limit cap that the schema already documents.

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 core purpose and state scope come first, followed by usage triggers, so it is well front-loaded. The closing "Read-only." fragment is dead weight given the annotations, keeping it just short of a 5.

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

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

With no output schema, the description does enough by listing the state values an agent can expect and by flagging that migrationId is retrievable from results. It stops short of describing the returned fields or what happens when there are more migrations than the limit, which an agent composing a follow-up call would want.

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

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

Schema description coverage is 100% and the single limit parameter already carries its default (10) and maximum (25) in the schema. The description adds no meaning about how limit interacts with the listed states, so it neither helps nor misleads — 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?

States a specific verb and resource ("List the customer's email migrations") plus the scope "across all states" with those states enumerated. This distinguishes it from get_migration_status, which is clearly keyed to a single migration, and from the other list_my_* siblings by naming the resource as email migrations.

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

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

Gives concrete triggers, including three verbatim user phrasings and the secondary purpose of resolving a migrationId for a follow-up action like cancel. It never explicitly names get_migration_status as the alternative when the ID is already known, so the routing signal is clear but not fully closed.

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, destructiveHint=false and openWorldHint=false, so the trailing "Read-only." mostly restates structured data. The description does add the return-field set, which is genuine context, but it says nothing about default/max result counts or ordering recency semantics beyond the schema.

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

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

The return contents are front-loaded in the first sentence, followed by usage examples, then a short safety note. Efficient overall, though the closing "Read-only." is largely duplicative of the readOnlyHint annotation and could be dropped.

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-required-parameter list tool with no output schema, the description covers what is returned, when to call it, and its safety profile. Only minor gaps remain (result ordering, pagination beyond `limit`), and none would cause a misinvocation.

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

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

Schema description coverage is 100% and the single `limit` parameter already documents default 5 and max 25, so the schema carries the semantic load. The description adds no additional meaning about the parameter, which is acceptable at baseline for full-coverage schemas.

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

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

States a specific verb and resource ("Returns recent orders on the customer's account") and enumerates the returned fields, so the agent knows exactly what it gets. It is clearly distinguishable from the other list_my_* siblings (cases, domains, hosting, backups) which cover different resources.

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 three concrete example user phrasings ("what did I buy recently?", "show me my last order", "what was my last invoice for?"), which is strong positive routing guidance. It does not name an alternative tool or state when NOT to use it, but no sibling provides overlapping order data, so the gap is minor.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds useful behavioral constraints beyond annotations: it lists only one folder at a time, only shows files within the web root, and excludes hidden files. It does not discuss errors or pagination, but those are minor gaps for this read-only listing 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?

The description is compact and front-loaded: it states what is returned, how to navigate, and why to use it before related tools. Every sentence contributes useful selection or invocation context, with only the final 'Read-only' being mildly redundant with annotations.

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

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

For a two-parameter read-only listing tool with no output schema, the description is complete enough: it explains the return fields, root/path navigation, scope limits, and relationship to read/write file tools. An agent has what it needs to call and interpret 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?

Schema description coverage is 100%, so both parameters are already documented in the schema. The description reinforces root behavior and one-folder-at-a-time navigation but adds little parameter syntax or semantics beyond what the schema provides; 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?

States a specific verb and resource: lists one folder of a shared hosting site's web root, and even names the returned fields (name, type, size). It is clearly distinguishable from related file tools by noting it is for listing folders before using read_site_file or write_site_files.

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

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

Gives explicit operational guidance: start at the root with no path, descend one folder at a time, and use this before read_site_file / write_site_files so paths are real. It also sets clear boundaries by saying hidden files and anything outside the web root are never shown.

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, open-world, and non-destructive behavior. The description adds useful context beyond annotations by stating 'No login required' and emphasizing that lookups work on any domain, not just owned domains. It does not mention rate limits, caching, or failure behavior, but the core behavioral profile is well covered.

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 purpose and supported record types, then gives return shape and usage context. It is efficient overall, though the record types are listed twice—once as supported lookups and again in the returned object—which is slightly redundant.

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

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

For a simple read-only lookup with one required parameter and rich annotations, the description covers purpose, scope, use cases, authentication ('No login required'), and return shape. No output schema exists, but the description supplies the expected response structure, so an agent has enough to call it correctly.

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

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

Schema description coverage is 100%, so the single 'domain' parameter is already documented with an example. The description reinforces that any domain is acceptable, but it does not add format, normalization, or validation details beyond the schema.

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

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

The description states a specific verb and resource ('Look up DNS records') and enumerates the supported record types (A, AAAA, MX, TXT, NS, CNAME). It also distinguishes scope by saying it works for 'any domain (not just domains they own)', which helps separate it from tools like get_dns_records that likely operate on owned domains.

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

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

It gives clear use cases: customer questions about DNS configuration, nameservers, mail routing, or verifying a specific record. It also clarifies the any-domain/not-owned condition. However, it does not explicitly name an alternative sibling tool or state when not to use this tool.

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

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

Annotations already establish read-only, open-world, idempotent, non-destructive behavior, and the description adds substantial context: exact return shape, meaning of asName, countryCode as allocation country rather than server location, BGP-not-geolocation caveat, no city data, CDN nuance, and no login required.

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 dense but front-loaded, first stating the core lookup and return shape, then usage guidance, then important caveats. Every sentence contributes operational meaning without 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?

With no output schema, the description compensates by describing the return object structure and field semantics. It also covers the main interpretive pitfall: BGP network ownership versus actual web hosting/geolocation.

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

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

There is only one parameter, and schema description coverage is 100%, so the schema already documents the domain argument. The description adds no additional parameter syntax or constraints beyond what the schema provides, making 3 the appropriate 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?

States a specific verb and resource: look up IP addresses for a domain and identify the announcing network via ASN, AS name, BGP prefix, registry, and country. It clearly distinguishes itself from detect_web_host by explaining that BGP network ownership is not the same as web hosting.

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 says to call this when asked what IP a domain resolves to or which network owns that IP, and explicitly redirects "who hosts this site?" questions to detect_web_host. This gives both when-to-use and when-not-to-use guidance with a named 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 readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered; the description adds genuinely non-obvious context — which fields come back, that registrant contacts are privacy-redacted post-GDPR, and that no login is required. The redaction note in particular prevents an agent from misreading an empty contact block as a failed lookup. Missing only rate-limit/quotient 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?

Four short sentences, each doing distinct work: what it does, what it returns, a caveat about redaction, when to call it, and auth posture. Front-loaded and free of 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?

No output schema exists, so enumerating registrar, dates, nameservers and status codes is exactly the missing information an agent needs to plan around the response. The GDPR caveat closes the one plausible gap for a WHOIS 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?

Single parameter with 100% schema description coverage, so the schema fully carries the semantics; baseline is 4. The description confirms scope ("any domain") but adds no format detail beyond the schema's example.

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

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

States a specific verb+resource ("Look up WHOIS / RDAP registration info") and enumerates the returned fields, making the tool's output recognizable at a glance. The phrase "for any domain" quietly scopes it away from the own-account siblings list_my_domains/get_my_domain_transfers, though no sibling is named explicitly.

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

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

Gives four concrete triggering questions (who owns it, when it expires, what registrar, whether it's available) that map directly to caller intents. It stops short of pointing at alternatives such as search_domains for bulk availability checks, so routing between the two still requires inference.

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

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

Goes well beyond the read-only/idempotent annotations: it states that nothing is applied live, that every change requires review/approval, that the render/JS fix is a hosting change rather than generated code, and that no engine recommendation can be promised. These are exactly the operational and expectation-setting facts an agent needs before invoking it.

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?

Purpose and usage trigger are front-loaded, followed by return shape and caveats, so the important information is easy to find. It is dense and the trailing mentionByEngine reporting instructions are somewhat tangential to invoking the tool, keeping it just short of a 5.

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 describing the return object structure (domain, grade, reviewRequired, proposals with id/type/title/rationale/autoApplicable/needsInput/artifact, summary). Combined with the no-side-effects guarantee and public-site scope, an agent has enough to call and interpret it 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 domain parameter already has 100% schema coverage, including the no-protocol/no-path constraint. The description adds only mild meaning ('works on any public website — no login required'), so it neither detracts nor contributes substantial parameter guidance beyond the schema baseline.

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

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

States a specific verb (scan and return a reviewable plan) and resource (proposed AI-visibility fixes for a website), and enumerates the artifact types produced. It clearly differentiates itself from the sibling check_ai_visibility by being the remediation-planning step rather than the diagnostic.

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 sequences the tool: 'Call this after check_ai_visibility when someone asks "how do I fix it?" or "what would you change?"'. That names both the prerequisite and the user-intent trigger, leaving little ambiguity about when to choose it over the sibling diagnostic.

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

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

Annotations already declare readOnlyHint/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavior: a 512 KB size cap, that binary files are described rather than returned, and the shared-hosting web root boundary — all useful for an agent predicting output.

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

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

Three tightly packed sentences, front-loaded with what is returned and its scope, followed by the workflow rule and edge-case handling. No filler.

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

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

For a two-parameter read tool with no output schema, the description supplies return type, size limit, and binary-file behavior, which is nearly everything needed to call it. Missing only error/not-found behavior and permission prerequisites.

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

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

Schema description coverage is 100%, so both 'domain' and 'path' are already documented in the schema, including the relative-to-web-root convention. The description adds only marginal meaning ('one file', implicitly scoped to the customer's site), so baseline 3 applies.

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

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

States a specific verb and resource ('Returns the text of one file') and scopes it precisely to a customer's shared hosting site's web root, listing file types. This clearly distinguishes it from list_site_files (enumeration) and write_site_files (mutation) among the 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?

Explicitly instructs to ALWAYS read before changing with write_site_files and to change only what the customer asked for, which ties it to a concrete workflow. It does not state when NOT to use it (e.g. use list_site_files to discover paths first), so it falls short of full alternative routing.

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=false, so the safety profile is covered. The description adds genuinely non-redundant context: the exact 16-port coverage ceiling (so the agent knows MySQL-alt or 6379 is not checked), the return object shape, and an auth precondition. It omits scan duration/timeouts and any rate limiting.

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, then scope, then return shape, then when-to-use. The long port enumeration is verbose but each entry carries real information about coverage. Auth requirement is tacked on at the end rather than placed with prerequisites.

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

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

There is no output schema, but the description compensates by describing the returned { domain, ip, openPorts[], closedPorts[] } shape, and it discloses the auth precondition. Only the temporal aspect (how long a scan takes, whether results are cached) is unaddressed.

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 required 'domain' parameter, which already includes an example. The description confirms the domain-based scope but adds no format, normalization, or validation nuance beyond the 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?

States a specific verb and resource (scan common TCP ports on a domain) and immediately bounds the scope to 16 enumerated ports with their service names. An agent can distinguish it from check_ssl, check_uptime, or check_security_headers without opening any schema.

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

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

Explicitly lists the triggering intents: 'what services are running on a server', 'whether a specific port is open', or 'check firewall exposure'. It also states the prerequisite that the customer must be signed in. It does not name a sibling alternative, so it stops short of a 5.

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

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

Annotations already cover read-only, idempotent, non-destructive, and open-world behavior. The description adds meaningful context beyond them: the enumeration of checked TLDs, brandable variations, the shape of the result (available / price / taken), and that no login is required. It does not discuss rate limits or pricing freshness, keeping it just under a 5.

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 invocation trigger, then structured into numbered routing rules. The long TLD enumeration and some repetition of the full-domain rule cost a little length, but every sentence carries routing or scoping information.

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

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

With no output schema, the description correctly explains what comes back (availability, yearly price, taken). For a single-parameter search tool it covers trigger conditions, parameter form, correction behavior, and a negative case — nothing an agent needs is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it distinguishes a bare base word from a full domain and gives concrete examples of when each form applies, plus a strong "never strip or substitute the TLD" rule for corrections. The schema description largely mirrors this, so it is reinforcement rather than new information.

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

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

States a specific verb and resource ("Search domain-name availability and pricing") and enumerates the exact extensions checked, so an agent can distinguish it from list_my_domains or lookup_whois at a glance. It also states what is returned (availability, yearly price, taken status).

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 says when to call ("CALL THIS whenever the user wants to find, check, buy, or register a domain") and gives three concrete routing rules, including an explicit when-NOT-to-call case for users merely reacting to results. Alternatives (answer from prior results) are named.

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 cover the safety profile (readOnly, idempotent, non-destructive), and the description still adds real behavioral substance: no login required, a hard 15-hop cap, the exact response shape, and the critical 'unmeasured' caveat that a silent port 80 is not the same as no upgrade.

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 the action, then return shape, then semantics, then caller intents — a logical order. It runs long in a single paragraph and the httpUpgrade taxonomy is dense, but each clause carries disambiguating 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?

There is no output schema, yet the description enumerates every returned field and explains the httpUpgrade states, so an agent knows exactly what comes back. Auth requirements are stated and the measurement caveat is covered — 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?

Only one parameter and schema coverage is 100%, so the schema already carries the meaning. The description adds nothing about domain formatting beyond what the schema example 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?

Specific verb 'Trace' plus a precise resource: the full HTTP redirect chain for a domain. The scope (up to 15 hops, each URL and status code) plus the dual chain/httpChain framing makes it unmistakable versus siblings like check_ssl or check_security_headers.

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?

Enumerates concrete caller intents — redirect chains, 'why does my site redirect', SEO redirect issues, mixed-content redirects, forced HTTPS, final landing URL. It gives strong for-when guidance but never names a sibling alternative or a when-not-to-use case.

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