DropTheHassle

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds real value beyond them: the account-token auth prerequisite, the fact that it does not charge, and that each returned item includes a fix hint (important since there is no output schema). It still does not describe pagination or response shape explicitly.

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

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

Front-loads the core purpose, then the criteria list, then short behavioral notes. Slightly padded by 'Read-only' repeating readOnlyHint and by listing eight criteria in one breath, but nothing is wasteful.

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

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

With no output schema, the description usefully discloses the return content (per-item fix hints) and the auth/cost profile, so an agent knows what it gets back and what it needs. Only the exact response format and any rate limits remain unspecified.

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 host parameter is already well documented in the schema; the description only adds the scoping phrase 'a site on this account', 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 and resource (returns award readiness for a site) and enumerates the exact criteria checked (favicon, share image, title/description, mobile viewport, page weight, custom domain, https, placeholder detection), which cleanly separates it from siblings like site_status or check_live.

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 context ('needs account token', read-only, no charge) and implies the use case, but never states when to prefer this over siblings such as site_status or check_live, nor any when-not conditions.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds real value on top by stating the account-token requirement, that the check is performed live at call time, and that the backend variant issues exactly one request.

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

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

A single dense sentence with the prerequisite front-loaded in parentheses and the read-only property at the end; no wasted clauses, though the parenthetical and mid-sentence 'backend true' phrasing is slightly awkward to parse.

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

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

With no output schema, the description should clarify what the live check returns (a boolean, a status object, per-check results?) and it does not. The auth requirement and backend mode are covered, but the response shape an agent needs to interpret results is left implicit.

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, and the description largely restates the backend flag ('sends one request to the linked backend instead') without adding format or syntax detail. Baseline 3 applies when the schema does the heavy lifting.

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

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

Specific verb+resource with the exact checks enumerated: address points here, valid certificate, loads. That is far more informative than the name alone. It does not, however, contrast itself with the sibling site_status, leaving the agent to infer which diagnostic to pick.

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

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

The '(needs account token)' prerequisite and the 'backend true sends one request to the linked backend instead' branch give usable context, but there is no explicit when-to-use or when-not-to-use guidance relative to site_status or the other site inspection tools.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial behavior: no charge, no account required, conditional EUIPO coverage, an explicit list of registers that did and did not answer, a TMview fallback link for national offices, and a 'not legal advice' disclaimer.

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 constraints, then output behavior in distinct sentences with no filler or repetition. It is on the longer side (eight sentences) but every sentence carries a distinct fact.

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 takes on return-value disclosure and does it well: hits include Nice classes and an optional relevance note, the result lists answering and unchecked registers, and national offices get a TMview link. An agent has enough to call it and report results correctly.

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

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

Schema coverage is 100% and both parameters are already documented in the schema, including the second-level-label rule and the relevance-note effect of intended_use. The description restates these effects without adding format syntax, so the baseline of 3 applies.

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

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

States a specific verb and resource ('look up live identical or very similar word marks for a name') plus the exact scope ('USPTO and EUIPO'). No sibling covers trademarks, so the agent can tell this apart from domain/site tools like search_domain without ambiguity.

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 clear conditions for how the tool behaves: EUIPO 'checked only when keys are set', national offices not checked, and intended_use changes the output. It implies the use case (pre-naming lookup) but never states a when-to-use vs alternative formulation, so it stops short of full routing 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?

Beyond the annotations (which only say non-readonly, destructive, non-idempotent), the description discloses the key side effect that the previous link redirects to the new one, that the operation is free ('Does not charge'), and that confirm=false acts as a dry run whose reply describes what would change. These are exactly the behavioral facts an agent needs before invoking a destructive mutation.

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?

Five short sentences, no filler: the outcome is front-loaded, then the identifier branching, then the confirm semantics and cost note. Every sentence carries operational content and the ordering matches how an agent would reason about the call.

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 still covers the post-call state (redirect behavior, preview reply text) and the cost dimension, which is sufficient for a 5-parameter mutation tool. It does not clarify interaction with custom or primary domains, a minor gap given the sibling set.

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 per-parameter meaning is already documented and the baseline is 3. The description adds orchestration logic the schema does not: the account/no-account branching that decides whether site or claim_url/site_token applies, plus the confirm-as-dry-run framing, which is value beyond the individual field docs.

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 concrete verb and resource — renaming a site's link to name.dropthehassle.app — and specifies the resulting URL form, which is more precise than a generic 'rename' tool. It does not explicitly name or exclude the adjacent siblings (connect_domain, make_primary_domain, split_domain), so an agent must infer the boundary rather than being routed to it.

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 real selection conditions: without an account use claim_url or site_token, with an account use site, and confirm=true applies the change while false previews it. That is genuine when/how guidance for the parameters, though it stops short of naming an alternative tool or stating when this tool should not be used.

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 the safety profile (mutation, idempotent, non-destructive, closed-world). The description adds genuinely useful context beyond that: account-token auth requirement, a single-claim constraint, the 'not already on another account' restriction, and 'Does not charge.' Return behavior is not described, but that is minor for this 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?

Roughly three sentences with no filler; the auth requirement leads and the action follows immediately. The leading parenthetical is slightly awkward but front-loads a critical prerequisite.

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 mutation tool with full schema coverage and rich annotations, the description covers auth, the single-use constraint, eligibility, and the no-charge fact. No output schema exists, and the description does not explain the response, but it is complete enough to invoke correctly.

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

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

Schema description coverage is 100%, so the claim_url parameter and its 'full link or code after the #' format are already documented. The description's mention that the link 'ends with # and a code' reinforces but does not substantially extend 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 verb and resource: 'Attaches an unclaimed site to this account using its claim link.' Claiming is naturally distinct from siblings like connect_domain or transfer_domain_out. It is clear and specific, though it does not explicitly name or differentiate against any sibling tool.

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

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

Provides clear preconditions: a valid account token, an unclaimed site, a claim link, and 'not a site already on another account.' This tells the agent when the tool is applicable. It stops short of naming an alternative tool for related scenarios.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the mutation profile is covered. The description adds value beyond them: an authentication requirement ("needs account token"), a billing note ("Does not charge"), and the public-visibility consequence of removing the password.

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

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

Two short sentences, with the prerequisite front-loaded in parentheses and no redundant restatement of the name or title. Every clause carries distinct 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 single-parameter mutation with annotations covering safety and no output schema, the description covers the essentials: auth need, effect, and cost. It could still note behavior when no password is set, but nothing critical for invoking 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 description coverage is 100% for the single required "site" parameter, which is fully documented with an example in the schema. The description adds nothing about parameter format or syntax, 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 and resource ("Removes the password from a claimed site") plus the resulting effect ("so anyone can open it"), which clearly distinguishes it from the sibling set_site_password. It does not explicitly name that sibling, but the operation is unambiguous.

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

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

The parenthetical "(needs account token)" supplies a prerequisite, which is genuine usage context. However, it never states when to prefer this over set_site_password or any alternative, and gives no when-not conditions, leaving usage only implied.

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

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

Adds substantial context beyond the annotations: '(needs account token)' flags an auth prerequisite, 'Does not charge' rules out billing, and the 301-redirect and re-check semantics explain what actually happens on repeat or multi-domain sites. This is exactly the kind of detail openWorldHint/destructiveHint 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?

Five short, front-loaded sentences with no filler; the auth note is prefixed so it is seen first, and each sentence carries a distinct fact (scope, non-transfer, response contents, redirect behavior, idempotency, cost).

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 payload (A record and TXT ownership record), and it covers cost, auth, idempotency, and multi-domain behavior. Nothing an agent needs before calling 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 description coverage is 100%, so both parameters are already documented with examples in the schema. The description implies the site/domain relationship but adds no format or constraint detail beyond the schema, 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 and resource ('Attaches a domain registered at another registrar to a site') and immediately scopes it by negation ('Nothing is transferred or bought'), which separates it from transfer_domain_out, point_domain, and search_domain without the agent needing to open another 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 clear triggering context (domain held at another registrar) plus two edge-case behaviors: on a site that already has a domain the name becomes a 301 redirect, and a repeat call re-checks ownership rather than duplicating. It never names a sibling alternative by name, so routing is inferred rather than explicit.

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 flag destructiveHint=true and idempotentHint=true, but the description adds substantial non-structured context: irreversibility, that files and versions are destroyed, the account-token prerequisite, the three refusal preconditions, and that no charge is incurred. This is exactly the behavioral detail 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?

Five short sentences, front-loaded with the irreversible destructive action and the auth prerequisite, then the refusal conditions, then the confirm mechanics. No filler or redundancy.

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

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

For a two-parameter destructive tool with no output schema, the description covers preconditions, irreversibility, side effects (files/versions, no charge), and the confirm gate. Nothing an agent needs before invoking it is missing.

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

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

Schema description coverage is 100%, so both 'site' and 'confirm' are already fully documented in the schema. The description's 'confirm=true applies it' merely restates the schema's declaration of the same semantics, adding no new syntax, format, or default 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 (Deletes) and resource (a site) and immediately scopes what is removed: 'including its files and versions.' This is clearly distinguishable from siblings such as rollback_site, deploy_site, or turn_off_email, none of which remove a site.

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 refusal conditions (domain registered here, email still on, suspended site) and the confirm=true requirement, so the agent knows when the call succeeds versus fails. It does not, however, name an alternative tool (e.g. turn_off_email or transfer_domain_out) for the blocked cases, leaving that routing 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?

Adds substantial context beyond the annotations (destructiveHint/openWorldHint): anonymous operation, returned links, the fact that the server cannot read the caller's filesystem, and concrete size limits (25 MB / 1,000 files unclaimed vs 100 MB / 5,000 signed in). These are exactly the operational facts an agent needs before invoking a destructive write.

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

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

Front-loads the core action and return values, then layers in constraints with no filler sentences. It is a dense single paragraph, so a bulleted grouping of limits/conventions would read slightly better, but every sentence earns its place.

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

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

For a destructive, account-optional publishing tool with no output schema, the description covers returns (live link, claim_url), auth modes, file conventions and quotas. Nothing material is left for the agent to infer before calling.

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 genuine meaning: the name-vs-site interaction (with an account, site targets an existing site and name is omitted; without site the oldest reserved address is filled), how slug relates to name, and email's purpose. This clarifies behavior the schema describes only per-field.

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 ("Uploads site files") plus the return artifacts (live HTTPS link, claim link), which cleanly separates it from siblings like edit_site_file, rollback_site and claim_site. An agent can tell what this does 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?

Provides strong context on when it applies: works without an account, cannot read a local folder, and which entry files are published (index.html or dist/, build/, out/, _site/, .output/public, docs/). It also flags an exclusion ("Does not buy a name"), but never names an explicit alternative sibling for edge cases, so it falls just short of 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 the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description nonetheless adds two facts not in the annotations: that it works without an account (auth requirement) and that the return is a link. 'Read-only' is redundant with readOnlyHint but harmless.

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, front-loaded sentences with no wasted prose — the core return value leads. Minor deduction because the trailing 'Read-only' restates the readOnlyHint annotation rather than earning its place.

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

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

With no output schema, the description carries the burden of describing the return, and it does ('a link to the gallery'). For a zero-parameter, read-only tool it is essentially complete; only the missing distinction from sibling gallery tools leaves a small gap.

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 per the rubric the baseline is 4. There is nothing for the description to clarify beyond the empty schema, and it 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?

States a specific verb and resource: 'Returns a link to the gallery of customer sites picked as Site of the Month.' An agent immediately knows this yields a curated gallery URL, not site data. It does not, however, differentiate itself from plausible siblings like gallery_preference or site_of_the_day_badge, which is the only thing keeping it from a 5.

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

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

The description implies the use case (getting design inspiration / a gallery link) and notes 'Works without an account,' which is useful context, but it gives no explicit when-to-use guidance and never contrasts itself with the similar-sounding gallery_preference sibling. Usage is inferable rather than stated.

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

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

Annotations declare readOnlyHint=true, yet the description says the tool 'turns on email for a domain' and 'anything is enabled' — an unambiguous state-changing mutation that contradicts the read-only annotation. Useful extras (sign-in required, price shown and confirmed first, €5/$5 per month incl. EU VAT) do not offset the direct contradiction.

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 with the core action front-loaded. The pricing detail (€5/$5 incl. EU VAT) and confirmation behavior are somewhat tangential to tool selection, but nothing is egregiously verbose.

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

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

For a zero-parameter tool with no output schema, the description covers the action, the precondition (domain must already exist), auth requirement, and that price is confirmed before enabling. What it lacks is consistency with its own annotations, which undermines rather than omits information.

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; per the rubric this is the baseline 4. The description adds no parameter semantics because none exist.

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

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

The description names a concrete verb and resource: turning on email for a domain already on DropTheHassle, with an example address (info@yourdomain.com). It is distinguishable from turn_off_email and email_status, though it never explicitly contrasts itself with those 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?

Usage is only implied. It states a precondition ('a domain already on DropTheHassle') and that sign-in is required, but gives no explicit when-to-use guidance or alternatives (e.g., turn_off_email, remove_email_address, rename_main_inbox) and 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?

Beyond the annotations (destructive, idempotent, non-readonly), the description discloses the account-token requirement, that autorenew=true is refused because it commits a charge, the confirm-gating, and 'Does not pay.' It adds real behavioral context the annotations cannot convey, though it does not detail error responses.

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, front-loaded with the auth prerequisite, then read behavior, then the write/refusal rules. Every sentence carries distinct information with no 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?

For a mutation-capable tool with no output schema, it explains what is returned (renewal timing, price, auto-renew state), the auth need, and the confirm/refusal behavior. Only minor gaps remain around error handling and the effect of confirm on read-only calls.

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

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

Schema coverage is 100% (baseline 3), but the description adds the interaction semantics the schema only lists separately: autorenew=false only acts when confirm=true, autorenew=true is refused, and absent autorenew means read-only. This extra coupling meaning lifts it above baseline.

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

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

The description states a specific dual purpose: returning per-domain renewal dates, prices, and auto-renew status, plus optionally stopping renewal. The verb+resource is concrete, though it does not explicitly name which siblings (e.g. connect_domain, transfer_domain_out) it complements or replaces.

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

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

It clearly conditions each mode: 'autorenew false with confirm=true stops the renewal,' 'autorenew true is refused,' and 'Absent means only read.' This tells the agent exactly which parameter combination to use for read vs. write, but no alternative tool is 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 already declare destructive/idempotent/readOnly=false. The description adds value beyond them: auth requirements (needs account token; site token works even before the site is claimed), the explicit 'Does not charge', and the restore/undo relationship. It could still say more about what is destroyed, but it meaningfully extends the structured hints.

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 primary purpose is front-loaded, which is good, but the prose is a sequence of short, somewhat disjoint run-on statements (e.g., 'Restore undoes the last Update or Edit files save') that are grammar-awkward and cost clarity. Every sentence is relevant, yet the delivery is less tight than it could be.

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 mutation tool with no output schema, the description covers the key operational facts: token/claim prerequisites, single-file scope, and no-charge behavior. Combined with annotations carrying the safety profile, it is largely complete, though return/confirmation behavior is left unstated.

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 schema already documents site, path, content, and the utf8/base64 encoding. The description restates these ('site is the address', 'path is the file', 'content is the new text') without adding format or constraint detail beyond the schema, fitting the baseline of 3.

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

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

States a specific verb ('Replaces... or adds') on a precisely scoped resource ('one file on a live site') and explicitly contrasts it with a sibling concept ('not a full folder Update'). An agent can immediately tell this is a single-file write apart from folder-wide operations.

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?

Explains the selecting condition versus a 'full folder Update' and requires that a site be claimed first when no token is present, giving real when-to-use guidance. It stops short of naming specific sibling tools (e.g., get_site_file or deploy_site) as alternatives, so it is clear but not exhaustive.

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

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

Annotations already cover readOnly, idempotent, non-destructive, and non-open-world, so the description adds real value with '(needs account token)' for the auth requirement and 'Does not charge' to signal no billing impact. 'Read-only' merely restates readOnlyHint and 'No passwords' is a mild oddity, but overall it contributes context beyond the 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-loaded with the auth note and the primary action, then the returned fields. Slightly run-on and contains some redundancy ('Read-only' duplicating the annotation), but no sentence 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?

With no output schema, the description carries the burden of explaining return values and does so well (addresses, mailbox vs forwarding, status, price, next step). Auth requirement is flagged, so an agent has enough to call it correctly, with only sibling routing left unstated.

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 'site' parameter is fully documented there, so the description need not explain it. It adds nothing about parameter format beyond the schema, giving the baseline 3 for a well-covered single param.

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 (Returns) and resource (the email on a site's own domain) and enumerates the returned fields: address, mailbox vs forward, status, monthly price, and next step. It does not explicitly differentiate itself from siblings like site_status or the email-management tools, so it lands just below the top tier.

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

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

The description implies a read/status-check use case but never says when to call it versus alternatives such as turn_off_email, remove_email_address, or site_status. Usage is inferable but no explicit condition or exclusion is given.

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 mutation (readOnlyHint=false), idempotency and non-destructiveness, so the description rightly spends its words elsewhere: auth requirement, site-claim prerequisite, what messages are collected, where they go (owner mailbox + dashboard), and the no-charge fact. It adds real behavioral context beyond the structured fields, though re-enabling behavior and rate limits are unstated.

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 auth requirement and the core action, then layered prerequisite and cost notes. Sentence fragments are slightly choppy but every clause carries information; nothing is 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-param toggle with a full schema, no output schema, and annotations covering safety, the description supplies prerequisites, effects, and cost. An agent has enough to invoke correctly; only post-condition details (what the response confirms, effect on existing submissions) are omitted.

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 both parameters are self-explanatory in the schema ('site' with an example host, 'enabled' with true/false semantics), so the description need not re-explain them. It adds no parameter-level detail beyond what the schema provides, which is the expected 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 — 'Turns lead collection on or off for a claimed site' — and immediately clarifies what the feature does (visitors send name/email/message, messages emailed and stored). An agent can distinguish this toggle from read-oriented siblings like list_form_submissions and list_site_leads 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 a clear prerequisite ('claim the site first') and an auth precondition ('needs account token'), which is more than most toggles offer. It stops short of naming alternatives or stating when-not to use it (e.g. disabling an already-disabled form), so it is clear context without explicit 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 declare the safety profile (not read-only, idempotent, non-destructive), and the description adds genuinely new context: it requires an account token (auth need), the consent gating model, and that it does not charge (no billing side effect). These go beyond what the annotations 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?

Three short sentences, front-loaded with the auth requirement and the core action. 'Does not charge' is a useful aside but slightly tangential; overall tight with little waste.

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-boolean mutation tool with annotations already covering the safety profile and no output schema, the description supplies the key missing context: consent semantics, auth requirement, and absence of cost. Nothing essential is missing, though return behavior is unstated (acceptable given no output schema).

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

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

Schema coverage is 100% and the single boolean 'featured' is fully documented in the schema itself ('true: sites may be considered. false: sites are not considered.'). The description adds no additional parameter meaning, so the baseline of 3 applies.

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

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

States a specific verb ('Sets') and a precise resource/behavior (whether the account's sites may be considered for Site of the Month), with the opt-in condition made explicit. An agent can distinguish this from siblings like site_of_the_day_badge or award_readiness 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?

The description implies usage through context ('A site is featured only after the account holder agrees') but never states when to call this versus alternatives, nor describes prerequisites beyond the account token. Usage is inferable rather than explicit.

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 annotations by disclosing the account-token requirement, the Stripe payment flow, what owner info is collected, the post-payment outcome (registration, HTTPS, no DNS settings), the claim-first ordering, and critically that it does not charge a card. This is exactly the behavioral context annotations can't 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?

Five sentences, but each adds distinct value, and the auth prerequisite is front-loaded in parentheses. Slightly long, yet nothing is clearly 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?

With no output schema, the description still explains what is returned (a payment link) and the full downstream flow. Auth, prerequisites, and post-conditions are all covered for a mutation-style tool.

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

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

Schema description coverage is 100%, so name, site, and extras are already documented in the schema. The description adds flow context but no per-parameter meaning beyond what the schema provides, making the baseline 3 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 — returns a payment link to register a domain and attach it to a site. This clearly separates it from siblings like get_email_checkout_link, connect_domain, and claim_site.

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 clear context: use it to register a domain and put it on an account's site, and notes that for a site not yet on the account the claim happens first. It does not explicitly contrast with alternatives such as connect_domain or point_domain, so the when-not guidance 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?

Beyond the annotations, the description discloses substantial behavior: the link is opened and paid by the account holder, a saved card is not charged, the mailbox and DNS records are set up after payment, and mail can be read/sent via webmail or IMAP/SMTP with credentials shown in the dashboard. This adds meaningful operational context that annotations alone do not 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?

The description is front-loaded with the core action and key auth prerequisite, and every sentence contributes useful context for a tool that lacks an output schema. It is a single dense paragraph, but the length is justified by the complexity of the email setup flow.

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

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

For a tool with no output schema, the description is nearly complete: it covers the return value (a payment link), prerequisites, billing behavior, and post-payment setup. It does not address link validity, reusability, or failure cases, which are minor gaps rather than critical omissions.

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

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

The schema already documents both parameters with examples and a default, achieving 100% description coverage. The description reinforces the meaning of the 'address' field (main inbox like hello@yourdomain.com) but does not add syntax or format details beyond what the schema provides.

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

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

The description states a specific verb and resource: it returns a payment link that turns on email for a site's own domain. It is clear what the tool does, but it never explicitly contrasts itself with the sibling get_checkout_link, so an agent must infer the distinction from the word 'email'.

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

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

The description gives prerequisites ('needs account token', 'site needs an active domain registered here first') and describes the payment flow, which implies when to use it. However, it does not explicitly say when to use this tool versus alternatives like get_checkout_link, email_status, or turn_off_email.

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

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

Annotations already declare read-only, idempotent and non-destructive, so the bar is lower; the description still adds the return encoding (utf8 or base64), token/auth semantics, and the cost signal 'Does not charge.' It stops short of error behavior or size limits.

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

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

Front-loaded with the return type, then parameters, then auth, then safety/cost. Sentences are short and mostly earn their place; the parenthetical '(needs account token)' is a touch abrupt but not wasteful.

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 covers the return format (text or base64) plus auth requirements and cost, which is what an agent needs before calling. Missing only failure modes such as a nonexistent path or binary handling.

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; the description's 'site is the address' and 'path is the file' merely restate them, adding only the token note. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource: 'Returns one file from a site you can update, as utf8 text or base64.' The singular 'one file' implicitly separates it from list_site_files, and the token note hints at edit_site_file, but 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 clear prerequisites: an account token is needed, a site token works (including before the site is claimed), and 'Without a token, claim the site first.' It does not explicitly contrast with list_site_files or edit_site_file, so the when-to-choose gap keeps it off 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 destructiveHint=false, so the description earns credit only for what it adds. It does: the account-token auth requirement, 'Does not charge' (billing side-effect disclosure), 'Does not promise a ranking' (an explicit limitation on the output), and the single-claimed-site scope. Return format and error behavior for unclaimed sites remain unstated.

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

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

Three tight sentences with no filler. The prerequisite and scope lead, the returned data is enumerated, and the two negations ('does not charge', 'does not promise a ranking') are short and load-bearing 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?

With no output schema, the description usefully enumerates the returned sections and states the period default and auth prerequisite, which is most of what an agent needs to call it. It stops short of explaining what 'claimed' means, what happens for an unclaimed site, or how this differs from site_analytics.

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 'site' and 'period' are already fully documented including the enum and the month default. The description merely restates the period values and default verbatim, adding no syntax, format, or constraint 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?

The description names a specific resource and enumerates exactly what comes back: visitors, page views, top pages, referrers, countries, devices, plus a one-sentence summary, scoped to 'one claimed site'. That is far more concrete than a generic 'get metrics'. However, it never differentiates itself from the sibling tool 'site_analytics', which an agent would reasonably consider interchangeable with this one.

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?

'(needs account token)' states a prerequisite and 'for one claimed site' scopes applicability, which is useful implied guidance. But there is no when-to-use versus when-not, and no routing to or away from 'site_analytics' or 'get_site_readiness', so the agent must guess which analytics-family tool 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 open-world, so the safety profile is covered. The description adds genuinely new behavioral context: the account-token requirement, that the call is not a purchase ("Does not charge"), and that it does not guarantee a ranking — a meaningful expectation-setting boundary 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?

Front-loaded with the auth requirement, then the substance of the checklist in one dense sentence, followed by three short qualifiers. Tight and well ordered, though the checklist enumeration is long enough that readability could be improved with structure.

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 helpfully enumerates what the checklist evaluates, effectively previewing the result set, and it states the token prerequisite and the non-purchase/non-ranking caveats. Only the sibling-overlap question is left unresolved.

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 both parameters (site, host) are documented there, including the host-vs-site distinction, so the schema carries the burden. The description only says "one claimed site" without adding format or validation detail beyond the schema, making 3 the correct baseline.

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

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

The description names a specific verb+resource (readiness checklist for a site) and enumerates the exact checks performed (favicon, share image, title/description, mobile viewport, page weight, custom domain, https, real page), so an agent knows precisely what comes back. It does not, however, distinguish itself from the similarly named sibling award_readiness, leaving real disambiguation work undone.

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?

"for one claimed site" implies the precondition that the site must already be claimed, which is useful context. But there is no explicit when-to-use guidance and no mention of the overlapping sibling award_readiness or check_live, so the agent must infer routing on its own.

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 'Read-only' restates structured data. The description does add two useful non-redundant facts: an account token is required, and the call 'does not charge', which no annotation conveys.

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

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

One tight sentence with the auth prerequisite front-loaded and the returned fields listed afterwards. Nothing is padded, though the abbreviation-dense phrasing reads like internal shorthand.

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 enumerate the fields an agent would care about (liveness, domains, renewals, email, restorability). It omits failure modes for unclaimed sites or invalid tokens, which is a minor gap for a single-parameter 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?

Schema description coverage is 100% with a single 'site' parameter that already carries an example value. The description adds nothing about the identifier's format or validity, 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 and resource and enumerates exactly what state it reports — liveness, domains and renewals, email, and rollback availability. It is clear what the agent gets back, though it never distinguishes itself from close siblings like site_status or check_live.

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

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

The only usage signal is the parenthetical prerequisite '(needs account token)'. There is no statement of when to reach for this tool versus check_live, site_status, domain_renewal, or email_status, all of which overlap with the state it returns.

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 "Read-only" is largely redundant. The description does add genuine context beyond them: the account-token auth requirement and the word "recent," which hints at a bounded result window. It says nothing about rate limits, pagination, or how many messages are returned.

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

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

Two short fragments with no filler, and the prerequisite plus operation are front-loaded before the read-only note. It is appropriately tight, though the parenthetical auth note leads rather than the tool's purpose, which slightly weakens the opening.

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

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

For a one-parameter, read-only tool whose annotations cover the safety profile, the definition is close to sufficient. However, with no output schema, "recent" is left undefined (count, time window, ordering), leaving the agent unsure what the call will actually return.

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, including a concrete example address, so the schema carries full parameter meaning. The description adds nothing about the site argument beyond what the schema already states; 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 ("Lists") and a precise resource ("recent messages from a claimed site's contact form"), which separates it from the similarly named list_site_leads and list_site_files. It never explicitly names or contrasts a sibling, so it stops short of a 5.

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

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

The description implies usage (read contact-form messages for a claimed site) and gives one prerequisite, the account token, but offers no explicit when-to-use, when-not-to-use, or alternative such as list_site_leads. Guidance is inferable rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered structurally. The description still adds real value beyond that by naming the authentication requirement ('needs account token') and preempting the obvious billing-related fear with 'Does not charge', though it says nothing about pagination or result limits.

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

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

Three short clauses, front-loaded with the prerequisite and the core action, then the return contents, then the non-effect reassurance. Zero 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?

Even with no output schema, the description enumerates what comes back (date, amount, printable link), and the auth requirement is stated. For a zero-argument read-only listing tool this covers everything an agent needs.

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

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

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate. Per the zero-parameter baseline, a 4 is appropriate; no misleading parameter hints are given.

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 account's invoices') and even summarizes the returned fields (date, amount, printable link). It does not need to differentiate against siblings, since none of the listed tools overlap with invoice retrieval, but it also does not explicitly position itself relative to any related tool.

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

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

The prerequisite '(needs account token)' gives a usable trigger condition, and the fact that no sibling deals with invoices means there is no real alternative to disambiguate. There is, however, no explicit when-to-use or when-not-to-use statement, only implied context.

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

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

Annotations already cover readOnly, idempotent and non-destructive, so repeating 'Read-only' earns little. What the description does add beyond structured fields is the token semantics (site token valid pre-claim) and the billing trait 'Does not charge', which no annotation expresses. Return payload shape and any path-count limits remain undisclosed.

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?

Short and largely front-loaded, leading with the auth requirement and the resource, then the address format, then the token rules. The trailing 'Read-only. Does not charge.' is two fragments that partially duplicate annotations, modest waste but defensible for a billing-sensitive operation.

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

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

For a one-parameter, no-output-schema read tool whose annotations already declare the safety profile, the description covers the remaining unknowns an agent needs: auth path, the pre-claim token exception, and the absence of cost. Nothing blocking a 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 description coverage is 100% and there is a single parameter, so the schema already defines 'site' fully. The description merely restates the schema's own example ('myproject.dropthehassle.app') verbatim, adding no format, constraint or validation detail beyond it. 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 file paths on a site' — which an agent can separate from get_site_file (single file) and edit_site_file (mutation). However, it never names those siblings explicitly, so the differentiation is inferable rather than stated.

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 real preconditions: an account token is needed, a site token works including before the site is claimed, and without a token the site must be claimed first. That is clear context for when the call will succeed, though it never contrasts with the sibling read tools (get_site_file) that might also return file content.

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?

'Read-only. Does not charge.' largely restates the readOnlyHint and destructiveHint=false annotations already supplied, earning little extra credit. The '(needs account token)' note does add real, non-annotated context about authentication, and 'Latest' hints at ordering, which keeps this above a bare restatement.

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 the prerequisite and the resource. Minimal waste, though the 'Read-only' sentence is redundant against the annotations 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 two-parameter read-only list tool with full schema coverage and no output schema, the description is adequate. The gap is the unresolved overlap with list_form_submissions and the absence of any pagination or return-shape note, which the annotations do not cover.

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 schema already documents both 'site' (with an example address) and 'limit'. The description's 'limit is how many to return, at most 50' duplicates the schema text verbatim without adding format or edge-case meaning, so the baseline of 3 applies.

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

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

It names a concrete resource ('Latest form messages for one claimed site'), so an agent knows what it retrieves. However, the sibling tool list_form_submissions covers closely overlapping territory and the description makes no attempt to distinguish the two, leaving 'leads' vs 'submissions' ambiguous.

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

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

The only guidance is the parenthetical prerequisite '(needs account token)', which is a precondition rather than a usage rule. There is no statement of when to pick this over list_form_submissions or any other listing tool, and 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 and non-destructive behavior, so the safety profile is covered. The description adds genuinely new context by flagging the auth requirement '(needs account token)' and listing which fields come back, which matters given there is no output schema.

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

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

One compact sentence with the prerequisite parenthetical attached, so the agent gets the key constraint immediately. Slightly awkward punctuation but no wasted words.

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

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

For a zero-parameter read-only listing tool with no output schema, the description covers the auth prerequisite and the shape of the return. Only the missing routing against sibling inventory/status tools keeps it from being fully complete.

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

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

The tool takes zero parameters, so the schema has nothing to document and the baseline is 4. The description correctly avoids inventing filtering syntax that does not exist.

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

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

States a specific verb and resource ('Lists the account's sites') and enumerates the returned fields (live link, status, domains per site), which separates it from single-site siblings like site_status or check_live. It is clear, though it never explicitly names a sibling for contrast.

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?

No when-to-use or when-not-to-use guidance is given, and no alternative is named (e.g., site_status, check_live, site_analytics). The plural 'sites' only implies a broad inventory call; the agent must infer the selection condition.

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 destructive=true, idempotent=true, readOnly=false, and the description adds real behavior on top: other domains 301-redirect to the chosen one, confirm=true applies while confirm=false is a dry run that reports the diff, and no charge is incurred. It does not describe reversibility or permission scope beyond the account token, so it is strong but not exhaustive.

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 prerequisite token requirement and the core action, with the confirm gate and cost note following. Dense and mostly waste-free, though the 'main name' clause and the search-engine/shared-link explanation are slightly redundant with each other.

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

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

With no output schema, the description usefully covers the prerequisite, the dry-run/report behavior, and the redirect side effect, which is what an agent needs to call it safely. The remaining gap is the lack of any indication of failure modes (e.g., unknown domain or missing token) or how to verify the result afterward.

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 all three parameters (site, domain, confirm) are already documented with examples and semantics. The description restates the confirm semantics ('confirm=true applies it') without adding syntax or constraints beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('chooses which of a site's domains is its main name') and spells out the concrete effect (the domain that serves the site and is used by search engines and shared links). An agent can distinguish this from connect_domain, point_domain, or split_domain 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 clear context for use: it needs an account token, it operates on a site that already has multiple domains, and it notes 'Does not charge.' It does not, however, name or exclude alternatives such as split_domain or connect_domain, so the routing guidance stops short of explicit when-not-to-use.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false. The description adds real value beyond those: the '(needs account token)' auth requirement, the dry-run semantics of confirm, and the fact that it 'Does not charge' — pre-empting a billing assumption. It doesn't spell out what happens to the domain's state on the old site, keeping it from 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 short sentences, front-loaded with the auth note and core purpose, then scope exclusions, then confirm behavior and cost. Every sentence carries signal; only the confirm restatement borders on redundancy with the schema.

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

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

For a mutation tool with no output schema, it covers auth, dry-run, cost, and scope — the essentials an agent needs to call it correctly. It stops short of describing post-move effects on the previous site's content or explicit reversibility guarantees.

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 all three parameters are already documented in the schema. The description restates the confirm=true apply behavior (already in the schema) and adds only marginal semantics, like the 'back onto a site it was split from' framing for to_site. 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 (move/point) and resource (domain) plus scope: 'a domain that is already on the account to another of its sites, or back onto a site it was split from.' This separates it from purchasing and from external-registrar DNS work, though it doesn't name sibling tools like split_domain or connect_domain outright.

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?

Clearly frames when to use it (re-homing an already-owned domain between sites, including reversing a split) and gives exclusions ('Does not buy a name and does not edit DNS at another registrar'), which implicitly routes buyers/DNS tasks elsewhere. No explicit sibling-tool alternative is named, so not a full 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?

Goes well beyond the annotations (destructiveHint/readOnlyHint/idempotentHint) by disclosing concrete consequences: mail stops, the mailbox's stored mail is deleted, the main inbox is untouched, confirm gates the mutation, an account token is required, and 'Does not charge' addresses cost.

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?

Short, front-loaded fragments with zero filler; the critical consequences and the confirm gate come first, and every sentence carries 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 destructive, no-output-schema tool, the description plus annotations give an agent what it needs: scope, consequences, dry-run behavior, and auth/cost notes. Minor gaps remain around error conditions (e.g., nonexistent address) but nothing critical.

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 site/address/confirm are already documented in the schema. The description's 'confirm=true applies it' largely restates the schema's confirm description, adding little new semantic detail; 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+resource+scope: 'Removes one email address from a site's domain.' It also carves out what it is not ('The main inbox is not removed here'), distinguishing it from siblings like rename_main_inbox and turn_off_email.

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 clear context for use: it removes a single address, mail to it stops, the main inbox is excluded, and confirm=true actually applies the change. It stops short of naming an explicit alternative tool for full-account email shutdown, but the exclusion rule is stated.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is partly covered. The description adds real value beyond that: the account-token auth requirement, the dry-run/apply split via confirm, and the reassurance that it is the same mailbox and same mail (the address changes, the inbox does not). It does not contradict the hints outright, though 'same mail, same price' softens the destructive framing without explaining 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?

Three short sentences, front-loaded with the auth prerequisite and then the action and the apply flag. The 'same price' clause is mildly promotional, but overall there is little waste.

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 3-parameter mutation with full schema coverage and no output schema, the description covers purpose, prerequisite, commit behavior and outcome. It is nearly complete; only the absence of any note on what happens to the old address afterward is a minor gap.

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 site, address and confirm are already documented in the schema, including the exact dry-run semantics of confirm. The description only re-states the confirm behavior and adds the hello@ to info@ example, so it sits at the baseline of 3 rather than adding new syntax or format 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 (renames) and resource (the main email address of a site's domain) and pins the scope with a concrete example, hello@ to info@. That example cleanly separates it from siblings such as remove_email_address, turn_off_email and email_status without needing to name them.

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

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

The parenthetical '(needs account token)' gives the prerequisite, and 'confirm=true applies it' tells the agent how to actually commit the change versus previewing it. There is no explicit when-not-to-use or named alternative, but the context is clear enough to select correctly.

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 readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false. The description adds genuinely new context: an account token is required, the action triggers a human email follow-up rather than an automated result, and it is free of charge. It does not describe timing or rate limits, keeping 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?

Three short clauses with zero waste; the auth requirement is front-loaded in parentheses and the key caveat ('Does not charge') closes it. Every sentence earns its place.

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

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

For a one-parameter request tool with no output schema, the description covers auth, what happens next, and cost. Minor gaps remain (expected turnaround, whether the request is repeatable), but 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 'site' parameter is fully documented in the schema, including an example address. The description adds nothing about the parameter, 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 and resource: sends a request to set up a Google Business Profile for a site. No sibling tool covers this action, so it is trivially distinguishable from the rest of the catalog.

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

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

The description gives clear context for use (setting up a Google Business Profile for a site on this account) and explains the outcome (team follows up by email). It does not state explicit when-not conditions or name an alternative, but no sibling offers a competing path.

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 the auth requirement (account token) and the billing consequence ('Does not charge'), plus who completes the loop (the account holder confirms from that email). It does not explain rate limiting or what happens on repeated calls, which matters given idempotentHint=false, but the added context is substantive.

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 the precondition and the core action, with zero filler. Every clause carries 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 two-parameter, non-idempotent email-trigger tool with no output schema, the description covers the action, the auth need, and the cost implication. What the call returns or whether it can be re-triggered freely is left unspecified, but the essentials for correct invocation are present.

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

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

Schema description coverage is 100%, so both parameters (site and domain) are already fully documented with examples. The description adds no further semantics about their formats or relationship, which is acceptable at this coverage level.

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 (resends) and resource (the registry's owner-confirmation email for a domain registered here), which cleanly separates it from the similarly-named sibling resend_receipt. An agent can identify the operation 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?

The scenario is implied — the account holder has not yet confirmed ownership and the email must go out again — and the parenthetical '(needs account token)' signals the precondition. However, it never explicitly states when to use this versus alternatives (e.g. asking for status via email_status) or when it should not be called.

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 (non-read-only, non-idempotent, non-destructive), and the description adds genuinely useful context beyond them: it requires an account token, it always targets the account email address rather than an arbitrary recipient, and it does not incur a charge. It stops short of disclosing failure behavior (e.g. no receipt on file) or any rate limit on repeated sends.

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

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

Two short sentences, zero padding, and the auth prerequisite is front-loaded before the action so an agent sees the constraint first. Every clause carries distinct information (auth, action, target, cost).

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, no-output-schema action with annotations carrying the safety profile, the description covers auth requirement, exact effect, fixed recipient, and cost. Only edge-case behavior (what happens when no recent receipt exists, repeat-send throttling) 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?

The tool takes zero parameters, so the baseline is high. The description still adds value by making explicit that the recipient is fixed to the account email address, so an agent knows there is nothing to supply and no targeting option exists.

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 ("Emails ... again") plus the exact resource ("the most recent receipt") and the destination ("the account email address"). It implicitly distinguishes itself from the neighboring resend_owner_verification tool by naming 'receipt' rather than a verification message.

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

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

Usage is only implied — an agent can infer 'use when the account holder needs another copy of the latest receipt' — but there is no explicit when-to-use, no exclusions, and no named alternative. The 'Does not charge' clause helps rule out billing intent but is not routing 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 destructiveHint=true, readOnlyHint=false and idempotentHint=false, but the description adds genuinely new context: the account-token auth requirement, the refusal conditions, that it 'Does not charge', and that repeating the call restores the version it replaced (reinforcing the non-idempotent behavior). It stops short of return format or any rate/claim-state caveats.

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 auth note and the core action, then the sequencing and constraints. The final sentence about the human Restore screen is the weakest link and slightly disrupts flow, but every sentence carries substantive 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 two-parameter mutation with no output schema and full annotation coverage, the description supplies auth, refusal, cost, and repeat-call behavior, which is close to complete. The claim-screen sentence is a bit tangential and the response content is never hinted at.

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 with examples. The description only restates the confirm=true effect, adding no syntax or format detail beyond the schema, which matches the baseline of 3 when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Restores the previous version of a site') and clarifies the underlying mechanism (undoes the last Update or Edit files save). It does not explicitly name a sibling, but the rollback semantics are distinctive enough against delete_site, update_site_settings, and edit_site_file that the agent can pick it correctly.

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

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

Gives a clear trigger (recovering the prior version after an Update/Edit save) and an explicit exclusion ('Refused for a suspended or inactive site'). It also flags that confirm=true is required to actually apply it, though it names no alternative tool for adjacent recovery tasks.

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 past the annotations (readOnly/idempotent) by disclosing what the tool does NOT do ('Does not register, reserve or charge'), that it works unauthenticated, and how results are classified: Unavailable, For sale by another party, premium as distinct from a marketplace listing, plus a trademark note caveat that is 'not legal advice'.

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 return in the first sentence, with the operational rules following. It is several sentences long, but nearly every one carries distinct information (pricing, availability states, trademark caveat); the bare-name rule is stated twice across description and schema, a minor redundancy.

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

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

With no output schema, the description carries the full burden of explaining return values, and it does so explicitly (available/cost, Unavailable, For sale, premium, trademark note). Combined with the read-only and no-account statements, an agent has everything needed to call and interpret this tool.

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

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

Schema coverage is 100% and the single parameter is fully documented in the schema, including the .com/.nl/.app expansion that the description also repeats. The description adds no syntax, normalization, or invalid-input guidance beyond the schema, so this sits at the baseline.

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

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

States a specific verb and resource ('Checks one domain name with the domain registry') and the exact return payload ('whether it is available and what it costs'). It further distinguishes scope with 'One name per call' and explains the bare-name multi-TLD behavior, which no sibling tool offers.

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 clear operating context: 'One name per call', 'Works without an account', and an explicit downstream instruction: 'When the exact name is taken, offer the human the free variant names.' It does not, however, name the alternative sibling (e.g. connect_domain for registration, check_trademark for marks), so routing is implied rather than stated.

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

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

Annotations already declare it non-read-only, non-destructive, and idempotent. The description adds value beyond them by disclosing state behavior ('The site stays unclaimed until the link in the mail is opened') and cost ('Does not charge'), which an agent cannot get from 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?

Four tight sentences, front-loaded with the action and immediately followed by parameter provenance ('site_id and site_token are the values from the deploy reply'). No filler, though the sentence count is slightly higher than strictly necessary.

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 three-parameter action tool with no output schema, the description covers the key behavioral facts an agent needs: the site remains unclaimed, the mail drives a link-based claim, and no charge occurs. Only the relationship to sibling claim tools 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 description coverage is 100%, so the schema already documents all three parameters, including their deploy-reply provenance and the email target. The description largely restates those facts, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource ('Sends the claim mail for an unclaimed site'), so the action is unambiguous. It does not name its closest sibling (claim_site), leaving the boundary between sending the mail and performing the claim to inference, which keeps it at 4 rather than 5.

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 implies the deployment context by requiring values 'from the deploy reply' and scopes usage to 'an unclaimed site', which suggests this is a post-deploy step. However, it never states when to call this versus claim_site or resend_owner_verification, so usage is only implied.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the description does not need to restate safety. It usefully adds two facts not in the annotations: the account-token auth requirement and 'Does not charge', which rules out an unintended billing side effect. It stops short of describing delivery/confirmation behavior, keeping it shy 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?

Three compact clauses, front-loaded with the auth precondition and the core action; nothing is padded or repeated. Every sentence earns its place.

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

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

For a two-parameter, non-destructive send tool with full schema coverage and no output schema, the description covers action, audience, auth precondition and the no-charge guarantee. Only minor gaps remain (no mention of submission limits or what the caller sees on completion).

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

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

Schema description coverage is 100% for both parameters, so the schema already carries the meaning of 'site' (with an example address) and 'message' (character bounds). The description merely echoes the concept of a note tied to a site, adding no format or constraint 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?

The description names a specific verb and object ('Sends the DropTheHassle team a note about a site') and adds a qualifier about authorship ('in the account holder's words'). It is clearly distinguishable from the surrounding siblings (delete_site, deploy_site, list_sites), though it never explicitly names or contrasts 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 states a precondition, '(needs account token)', which is real context for invocation, but gives no when-to-use vs alternatives guidance or exclusions. With no close sibling performing the same job, the implicit usage is reasonably inferable, so this lands at minimum-viable rather than poor.

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 destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is provided structurally. The description usefully adds that enhanced 'changes what visitors see', requires an account token, and 'does not charge', but does not detail reversibility or side effects beyond the annotations' coverage.

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

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

Front-loaded and free of filler; the auth prerequisite, the two levels, and the confirm gate each appear once. Parenthetical asides make it slightly dense but nothing 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?

For a destructive mutation tool with no output schema, the description covers impact ('changes what visitors see'), auth requirement, cost, and the confirm=false reply behavior. It leaves out only reversal/rollback specifics.

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

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

Schema coverage is 100%, so baseline is 3. The description earns above baseline by expanding the bare enum values into real meaning (standard = cookieless/no banner/default; enhanced = banner + heatmap) and clarifying confirm=true 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?

States a specific verb (Switches) and resource (a site's statistics level), and defines the two states (standard vs enhanced) concretely. An agent knows exactly what changes, though no sibling (e.g. site_analytics) is named to sharpen the boundary.

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 clear context for choosing enhanced (adds cookie banner + heatmap) vs standard (cookieless, no banner, default), and explains the confirm=true gate. It stops short of naming an alternative tool or an explicit 'when not to use' rule.

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

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

Adds meaningful context beyond annotations: the token requirement, split-mode routing rules, the unlink behavior of empty url, the confirm-only-for-existing-site rule, and 'Does not charge.' Annotations already declare destructive/readOnly/openWorld/idempotent, so the description is not carrying that burden alone. Minor gap: it doesn't describe the response aside from confirm=false returning a change description.

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 auth requirement and core action lead, then usage branches. No filler sentences, though the run-on style (many short clauses) slightly reduces scannability.

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 5-param, no-output-schema, destructive mutation tool, it covers auth, branching, destruction (unlink via empty url), and cost. Missing only an explicit statement of what the call returns on success and any rate/limit notes.

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

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

Schema coverage is 100%, so baseline is 3. The description goes beyond the schema by tying parameters together: empty url + site unlinks, confirm applies only to existing sites, paths default to /api/* and only apply in split mode. That cross-parameter semantics is genuinely additive.

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 ('Links an HTTPS backend ... to a DropTheHassle name') and enumerates the hosting providers accepted. Distinguishes itself from siblings like connect_domain or split_domain by naming the backend-linking operation 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?

Explains the main branches clearly: with/without uploaded files, with/without site, empty url removes the link, and confirm semantics for existing vs new sites. It does not name sibling alternatives (e.g., connect_domain vs set_backend) for an agent choosing between them, which keeps this at 4.

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 destructive=true and idempotent=true, but the description adds real context beyond them: the account-token requirement, the domain precondition, and that the operation "does not charge". Auth and cost constraints are exactly the kind of non-annotated 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?

Four tight sentences, front-loaded with the auth note and the core action, with no filler. The trailing "Does not charge" is slightly peripheral but genuinely useful for an agent deciding whether to invoke a billing-adjacent tool.

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

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

For a mutation tool with no output schema, it covers the essentials: auth, precondition, the two image kinds, the removal path, and cost. It omits what a successful set returns or how content conflicts with file/clear are resolved, but the schema-annotated surface keeps it close to complete.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters, including base64 content and the clear flag. The description restates content-as-base64 and clear-true-removes but adds no format or constraint detail beyond the schema, 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 (sets or removes) and resource (favicon / share image) with the two image kinds named explicitly. An agent immediately knows this tool manipulates a site's icon/preview image, and no sibling tool overlaps that purpose.

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

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

Provides a clear precondition ("Available once the site has its own domain") and the switch that selects removal ("clear true removes the current image"). It does not name an alternative tool, but none of the siblings serve this purpose, so the routing guidance is effectively complete.

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 idempotent, non-destructive, non-open-world behavior, and the description adds context not in the annotations: the account-token requirement, the prerequisite that the site must already be claimed, and 'Does not charge' (billing impact). It still doesn't state whether the change is reversible from the tool itself or how search engines ack the request.

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 the auth note and the core action, then the mode values, then the prerequisite and billing note. 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 tool with full schema coverage and annotations covering safety, the description supplies the remaining essentials: auth, prerequisite state, mode meaning, and cost. Nothing critical is missing, though a note on latency or propagation of the search-engine change would make it fully complete.

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

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

Schema coverage is 100% and the enum values are already documented in the schema, including what allow vs noindex mean. The description's 'mode is allow or noindex' simply restates that, adding no new syntax or format meaning beyond the structured data.

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 and resource: it tells search engines to skip a claimed site or to list it again, which is a distinct action from siblings like claim_site, delete_site, or update_site_settings. An agent can identify the operation 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 the key precondition ('Claim the site first') and names the two mode outcomes, so the agent knows when the call is valid and what each mode selects. It does not name a sibling alternative or an explicit when-not-to-use condition, which keeps it 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 the mutation/idempotent/destructive profile, and the description adds genuinely new context: it requires an account token, works on both the free link and a custom domain, and does not charge. It stops short of explaining why the operation is flagged destructive (e.g., that an empty password exposes the site), but the added auth and scope notes are real value.

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

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

Four short sentences, with the auth precondition front-loaded in parentheses and no filler. Each clause conveys a distinct fact, though the empty-password and scope notes could be tightened into fewer lines.

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 2-parameter mutation with full schema coverage and annotations covering the safety profile, the description is close to complete: it discloses auth needs, behavioral effect of empty input, and scope. The one omission is the relationship to clear_site_password, which an agent would benefit from knowing.

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, and the description largely echoes the schema's own 'empty makes the site public' wording. The domain/free-link scope note is mildly additive but does not extend parameter syntax or format. Baseline 3 is appropriate when the schema carries the load.

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: it sets a visitor-facing password that gates a claimed site before it opens. The scope is clear. However, it never distinguishes itself from the sibling clear_site_password, and the 'empty password makes the site public' clause actually overlaps with that sibling's job, leaving a routing ambiguity.

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

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

Usage is implied (protect a site with a visitor password) and the empty-password behavior is noted, but there is no explicit when-to-use or when-not-to-use guidance and no mention of clear_site_password as the alternative for removing a password. The agent must infer the boundary from sibling names 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 declare readOnlyHint and idempotentHint, but the description adds genuinely relevant context beyond them: the two-step user flow (email then 6-digit code then approve), the session-state side effect on the following call, and the anti-pattern warning 'Nothing to copy.' It does not cover link expiry or failure behaviour, keeping 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?

Four short sentences, front-loaded with the return value, then the user flow, then the outcome, then a one-line warning. Tight and readable; the only slack is that the user-flow sentence is marginally more detail than the calling agent strictly 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?

There is no output schema, so the description appropriately tells the agent what comes back (a link) and what the agent should and should not do with it. The gap is the unaddressed 'pending' recovery path and the absence of any failure/expiry note.

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 'pending' parameter's meaning is already fully documented in the schema. The description adds nothing about this parameter (e.g. that recovering a lost session is when you'd supply it), 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 and resource ('Returns a link the user opens to sign in to DropTheHassle') and immediately clarifies the downstream effect ('The next call in this chat is signed in'), which distinguishes it from session/credential siblings like whoami, clear_site_password and set_site_password. An agent can tell at a glance what this does and what state it produces.

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

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

The description explains the mechanism well but never states when to invoke it versus alternatives, nor any preconditions such as being signed out or a session having been dropped. For a sign-in tool the usage is largely self-evident, so this is implied usage rather than explicit 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 and idempotentHint, so the 'Read-only' clause is partly redundant, but the description adds real value beyond structured fields: the account-token authentication requirement and the guarantee that these are 'the same numbers as the dashboard' (data provenance/consistency). No destructive or side-effect behavior to disclose for a pure reader.

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

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

A single dense sentence that front-loads the auth prerequisite before the returned data. No filler; the metric enumeration is informative rather than padding, though the sentence is long enough that structure could be slightly tighter.

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 by enumerating every metric returned plus the one-sentence summary, which is exactly what an agent needs. Prerequisite and read-only nature are covered, leaving only minor gaps like pagination/limits.

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 both parameters (site, period with enum) are fully documented in the schema. The description adds no syntax or format detail beyond that, 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 and resource ('Returns visitor numbers for a site on this account') and enumerates the exact metrics returned (visitors, page views, top pages, referrers, countries, devices, summary). This clearly separates it from siblings like set_analytics_level and site_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?

The prerequisite ('needs account token') is stated, which is genuine usage context, but there is no explicit when-to-use/when-not guidance and no routing to alternatives such as site_status or set_analytics_level. Usage is only implied.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds real context: an account token is required, the call does not charge, and the no-parameter case degrades to a listings response rather than an error. No return-format or pagination detail is given, keeping it at 4.

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 the auth requirement, then the return content, then parameter roles, then the fallback and cost note. Each sentence carries information an agent needs; nothing is 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?

With no output schema and only two optional parameters, the description covers the return payload (embed line/ribbon contents), the auth prerequisite, the fallback behavior when no parameters are passed, and the non-billing guarantee. Nothing needed to invoke 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%, so the baseline is 3, but the description adds semantic meaning the schema does not: 'site' must be a site on this account, 'host' must be a confirmed winner, and both are optional with a defined fallback. That exceeds what the schema alone conveys.

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 embed line for a Site of the Month award, and describes what the returned ribbon contains (award name, period, verification link). It never explicitly distinguishes itself from siblings such as award_readiness, so it lands at 4 rather than 5.

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 selection logic: 'site' targets a site on this account, 'host' targets a confirmed winner, and with neither the tool lists the account's earned awards. That is clear when-to-use context, though no alternative tool is named for these cases.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the redundant 'Read-only' adds little. The description does add genuine behavioral context beyond the annotations: the account-token authentication requirement and the full scope of what the read surfaces (deploy history, restore availability, domain renewal state).

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

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

A single sentence with the prerequisite front-loaded and the returned fields grouped as a scannable list. It is slightly run-on but every listed item corresponds to a distinct aspect of the read, 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?

With no output schema, the description compensates by enumerating the return content (liveness, links, deploys, restorability, domains, email), and annotations cover the safety profile. It is close to complete for a one-parameter read tool; only pagination/response-shape detail is absent.

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 'site' parameter is fully documented in the schema with an example address. The description adds no syntax or format detail beyond that, 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 and resource ('One read of a site') and enumerates what the read covers: live status, links, deploys, restorability, domains, email. This clearly separates it from list_sites (plural) and check_live (single concern), though it never names a sibling to reinforce the distinction.

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

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

Usage is implied by 'One read of a site' versus the list-oriented siblings, and the '(needs account token)' prerequisite is stated. However, there is no explicit when-to-use vs when-not guidance and no pointer to the alternative tools for the same data.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds real value: authentication requirement, the explicit 'Does not charge' cost disclosure, and the fact that the domain lands on a new site showing a coming-soon page. It still does not describe failure modes or whether the domain is removed from the original site immediately.

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, prerequisite front-loaded, no filler. Every clause carries information an agent needs: auth, effect, dry-run control, and cost.

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 3-required-parameter mutation tool with no output schema, the description covers auth, cost, side effects, and the dry-run switch, so an agent can call it correctly. Minor gaps remain around what happens if the site has only one domain or whether the move is reversible.

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 all three parameters are already documented, establishing a baseline of 3. The description reinforces the 'site that has several' constraint on the domain parameter and the confirm semantics, but adds no format or edge-case detail 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 ('Moves one domain off a site that has several, onto a new site') with a clear precondition (site must have multiple domains). It is distinguishable from siblings like connect_domain, point_domain, and make_primary_domain by the 'moves off ... onto a new site' framing, though it never names an alternative 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 a prerequisite ('needs account token') and the semantics of confirm=true/false, which implies the usage pattern (dry-run first, then apply). It does not say when to prefer this over siblings such as connect_domain or transfer_domain_out, nor any 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 declare destructiveHint=true and idempotentHint=true. The description adds key context: needs account token, auto-renew turns off, transfer code emailed within a day, domain keeps working until it moves, and no charge. This goes well beyond annotations and covers the mutation's side effects.

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

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

Densely packed with useful information in four sentences, front-loaded with the action and prerequisites. Every sentence adds value.

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

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

For a destructive, open-world tool with no output schema, the description covers side effects, timing, and cost. It could mention what happens on failure or whether the transfer can be cancelled, but it's quite complete.

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

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

Schema coverage is 100%, so baseline is 3. The description explains that confirm=true applies it and false leaves unchanged, adding meaning beyond the schema description which already states this. It also implies the token requirement, though not a parameter.

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

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

Specific verb+resource: 'Starts moving a domain registered here to another registrar.' Clearly distinguishes from siblings like domain_renewal or connect_domain by naming the transfer-out action.

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

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

Provides strong context on what happens (auto-renew off, code emailed) and the effect of confirm=true/false, but doesn't explicitly say when to use this vs alternatives like domain_renewal or point_domain.

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 annotations: discloses the auth requirement (account token), the cancellation timing (keeps working until month end, stops renewing), the dry-run behavior of confirm, and that no charge occurs. This adds real operational context on top of destructiveHint/idempotentHint.

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?

Five short sentences, front-loaded with the auth prerequisite and core action, then billing timing, then confirm semantics. Every sentence carries information; nothing is 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 destructive two-parameter mutation with no output schema, the description covers the key behaviors an agent needs (auth, timing, no charge, apply switch). The only gap is not naming where re-enablement happens, which would round out the lifecycle picture.

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. The description reinforces confirm=true as an apply switch and clarifies the billing consequence, but adds little syntax or format meaning beyond what the schema provides.

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

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

States a specific verb (turns off) and resource (email for a site's domain), with scope made explicit. It is clearly distinguishable from siblings like email_status, remove_email_address, and rename_main_inbox, which handle different email operations.

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 clear context: cancellation takes effect at end of the paid month, confirm=true applies the change, and turning it back on is not handled here. It lacks the explicit name of the sibling tool that re-enables email, so routing is implied rather than stated.

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

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

Annotations already declare readOnly=false, destructive=true, idempotent=true, and openWorld=false, so the safety profile is covered. The description adds meaningful context beyond them: the account-token auth requirement, the 'site must have its own domain' precondition, and 'Does not charge'. It does not warn that setting these fields overwrites existing values, which would help given destructiveHint=true.

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 a compact, front-loaded block: the prerequisite leads, then purpose, then scoping conditions. Nearly every clause earns its place, though the inline '(needs account token)' parenthetical is slightly awkward packaging.

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 an 8-parameter mutation with no output schema, the description supplies the essential context: what it changes, scope, availability precondition, and that it costs nothing. The only gap is the absence of any note about overwriting existing values, which annotations flag as destructive.

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 every parameter (site, domain, serp_title, brand_color, share_title, display_name, serp_description, share_description) is already documented in the schema. The description maps fields to concepts but adds no syntax or format detail beyond what the schema provides, so baseline 3 applies.

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

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

The description gives a specific verb (sets/updates) and resource (site settings), enumerates the actual fields affected (name, brand colour, search/share title and description), and distinguishes itself from siblings like set_analytics_level, set_backend, and set_site_image. An agent can tell what this tool mutates 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 states scope conditions clearly: applies site-wide, or to a single domain when 'domain' is set, and is only available once the site has its own domain. It also flags the account-token prerequisite. It stops short of naming explicit alternatives, but the when-to-use context is strong.

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 (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description's job is to add context — which it does by disclosing that the response content changes based on authentication state. It stops short of describing exact return fields, but that is a minor gap against a fully annotated 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?

Three short sentences, zero waste, and the core statement of what is reported is front-loaded before the two conditional behaviors. Nothing is repeated and every sentence adds 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 parameterless, fully annotated, read-only identity tool with no output schema, the description covers both branches of behavior (authenticated vs. not) and what each yields. An agent has everything needed to decide to call it and to interpret the difference in responses.

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 to document and the baseline for a parameterless tool is 4. The description correctly implies no input is required, matching the empty 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 ('Reports') and resource (the DropTheHassle connection/account identity), and then spells out the two distinct outcomes: a list of sign-in-free actions when unauthenticated, or the account name when authenticated. No sibling tool touches identity or connection state, so the purpose is unambiguous by contrast as well.

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

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

The conditional phrasing ('Without an account... With an account...') implicitly tells the agent when this is the right call: to determine identity or available unauthenticated capabilities. It doesn't name an alternative, but no sibling offers comparable identity information, so there is little to route against.

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