Scopeweb

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

Annotations already convey read-only, idempotent, open-world, and non-destructive behavior, and the description reinforces these with 'Read-only' and 'Cannot spend money.' The added behavioral detail about performing a live fetch of observable surface signals goes beyond the annotations and gives the agent useful safety and cost expectations.

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

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

The description is compact and front-loaded: it opens with usage guidance, then lists the fetched fields, then states safety/cost constraints. Each sentence serves a purpose, though the two 'Use...' sentence stems could have been merged without loss of clarity.

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 with no output schema, the description is well-rounded: it covers input semantics, operation scope, the exact observable signals returned, and safety/spend constraints. Minor gaps like error handling for non-resolving domains and input normalization are acceptable given the simple, safe nature of the operation.

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 contains only a required 'domain' string with no descriptions, so the description must compensate. It adds meaningful semantic context by clarifying the domain is the user's existing/owned site, not a new candidate name. However, it does not specify the expected input format (e.g., bare domain vs protocol, trailing slash, punycode), leaving some ambiguity for invocation.

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/resource: 'Fetch a live domain's observable surface' and lists concrete outputs (HTTP status, redirect target, title, meta description, h1 headings, tech hints). It also distinguishes the domain from siblings by noting this is for names the user already holds, not for finding new ones.

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

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

The description explicitly tells the agent when to use the tool: when the user asks what is wrong with a site they own, wants an existing name assessed, wants to compare deployment against a spec, or wants to know if a domain serves anything. It signals when not to use it by saying 'rather than a new one found,' though it does not name specific sibling tools as alternatives.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds substantial behavioral context: 'Cannot spend money', returns 404 for reserved/premium names, only checks registration not site status ('registered' vs 'active' or 'dormant'), and warns that a clean result says nothing about name quality. No contradiction with annotations.

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

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

The description is long but front-loaded with the key directive 'THE LAST GATE, NOT THE FIRST STEP'. Each sentence adds distinct value: usage timing, scope, caveats, and limitations. It is more verbose than necessary but not repetitive; the structured flow from purpose to interpretation to exclusions is effective.

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

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

For a tool with one parameter and no output schema, the description is exceptionally thorough. It covers what the tool does (checks registration), what it returns in different cases (404 for reserved/premium, 'registered' not active/dormant), how to interpret results (clean result says nothing about quality), prerequisites (names from suggest_names or scan_namespace), and usage timing. Nothing an agent needs for 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 0%, so the description must compensate. It adds the 10-domain limit ('up to 10 domains') and clarifies the parameter is a list of domain names for registration checking. While it doesn't specify array format explicitly, the single obvious 'domains' parameter is adequately contextualized given the description's focus on domain checking.

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

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

The description clearly states the tool's purpose: 'Real-time authoritative registration check' and 'It answers only "is this registered"'. It distinguishes itself from siblings by positioning as 'THE LAST GATE, NOT THE FIRST STEP' and explicitly stating it does not evaluate name quality or price, unlike suggest_names or score_name.

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

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

Explicitly specifies when to use: 'immediately before you recommend buying anything' and 'any time an earlier answer said "unknown", "pending" or "unprobed"'. It also gives exclusions: does not fetch the site, so not for active/dormant; does not tell price or buyability. It even describes behavior for unvetted names ('If none of the names you pass have been seen by suggest_names or scan_namespace, the response says so').

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 behavioral context beyond the annotations: drafts persist across conversations, every version is content-screened, and flagged drafts still return a draft_id but serve a 451 preview. No contradiction with idempotentHint or destructiveHint exists.

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

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

The description is compact and front-loaded with the key usage condition. Every sentence adds a distinct fact: storage location, return values, persistence, and screening behavior.

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, it names the persistent draft_id and live preview_url return values, explains the flagged-content behavior, and provides lifecycle routing to list_drafts. Combined with sibling names, an agent has the needed context to call it correctly.

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

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

Schema description coverage is 100%, including the note that index.html is required for a browsable preview, so the description does not need to add much param-level detail. The description's 'for a name' aligns loosely with name_hint but adds no new semantics.

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

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

States a specific action (creating a draft site/page/landing) and resource (user's Scopeweb portfolio). It distinguishes from sibling update_draft through the 'nothing to edit yet' condition and from list_drafts via the 'future sessions to resume work' pointer.

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

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

Explicitly states when to use: when the user wants a draft and there is nothing to edit yet. It also names list_drafts for future resumption, but could go further by explicitly saying 'use update_draft to edit an existing draft.'

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

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

With no annotations, the description carries full burden for behavioral disclosure. It lists what is returned (registration, cost, renewal, provenance) and implies a read-only operation via 'fetch', but it does not explicitly state that no mutations occur, nor does it mention error conditions or input validation. The information is useful but not comprehensive; a clear 'does not modify anything' would have raised this score.

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

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

The description is two succinct sentences: the first enumerates the returned data types, the second gives a concrete usage example. It is front-loaded with the core value proposition, contains no redundant phrases, and every sentence earns its place.

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

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

For a single-parameter tool with no output schema, the description adequately explains how to call it (id) and what to expect in return. It does not cover potential limits, errors, or currency specifics, but given the simplicity and the fact that the returned data categories are listed, it is sufficient for an agent to invoke correctly. Slight gap in not mentioning any prerequisites or restrictions, but not 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?

The schema already provides 100% coverage with the description 'A domain name.' The tool description adds an example ('atlas.io') and clarifies the id should be a domain name, which is slightly more helpful than the schema alone. However, since schema coverage is complete, the baseline 3 applies and the added example is marginal but not transformative.

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

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

The description clearly states the tool fetches comprehensive information about a single domain, listing specific data points (registration status, cost to claim, renewal cost, and provenance). This distinguishes it from siblings like quote_domain (pricing only) or audit_domain (history) by emphasizing the complete profile. The verb 'fetch' and resource 'domain' are explicit, and the example clarifies the input.

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 use for retrieving all available data on one domain but does not explicitly contrast with alternatives or state when not to use it. No mention of sibling tools for narrower queries, leaving selection somewhat to inference. It provides clear context (single domain lookup) but no exclusions or comparisons, so it's adequate but not directive.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only. Cannot spend money.' It adds behavioral context beyond annotations by stating that it returns metadata and file list, or file content, which is not covered by the schema. No 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?

Three sentences, each serving a purpose: first explains the primary use case, second describes the functional behavior, third adds safety and context. It is slightly wordy but front-loads the key usage guidance and remains efficient overall.

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

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

For a simple read-only tool with only two parameters and no output schema, the description provides enough information: what the tool does, when to use it, and what it returns. It doesn't detail response format, but for a get operation without an output schema, this is acceptable.

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 50%, and the description compensates by explaining that 'path' returns file content and that without it, the tool returns metadata and file list. The draft_id parameter is self-evident but not explicitly described; the description adds value for the optional parameter.

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

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

The description clearly states the verb 'Get' and the resource 'draft', and specifies exactly what is retrieved (metadata, file list, or file content). It distinguishes itself from siblings like update_draft and list_drafts by emphasizing read-only retrieval and the specific use case of resuming work on a draft.

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 explicitly says 'Use this before editing a draft you did not create in this conversation' and 'Use to resume work on a draft from a previous conversation,' giving clear when-to-use guidance. It does not explicitly name alternatives or exclusions, but the context is sufficient to infer that it's for reading drafts, not creating or modifying them.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only nature is clear. The description adds valuable context about the `partial` flag indicating headroom is an upper bound, and explains the meaning of `reason: foreign_registrar_pricing` for unknown costs. It also clarifies that transfer prices are not renewal prices. This goes beyond the annotations, though it does not describe the exact output structure (no output schema), but that is partially covered by describing the 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?

The description is moderately long but every sentence serves a purpose, covering usage context, output specifics, and caveats. It is front-loaded with 'Use this before recommending anything with a price', which immediately tells the agent when to invoke. No filler or repetition.

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

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

Given the tool's complexity (multiple financial concepts, partial data, unknown costs), the description covers the essential caveats: headroom upper bound when partial, unknown cost reasoning, and transfer price distinction. The single parameter is clear, and the output schema is absent, so the description's field listing helps the agent understand what to expect. It is complete enough to avoid misinterpretation.

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

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

Schema has only one parameter, `project_id`, with no description. The parameter is self-explanatory, so the description adds minimal value by not detailing what project_id references if ambiguous. However, since there is only one required parameter and it is standard, the agent can infer meaning. The description itself does not elaborate on the parameter, but the schema coverage is 0%, so the description does not need to compensate for missing param descriptions; the baseline is 3 because the single param is trivially named.

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

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

The description clearly states the tool's purpose: to retrieve the fiduciary readout for a project, including budget, costs, headroom, and unknown counts. It specifies the verb 'get' and the resource 'finance', and the context 'Use this before recommending anything with a price' distinguishes it from siblings like `quote_domain` or `get_draft`.

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

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

The description explicitly instructs when to use the tool: before recommending anything with a price. It also tells the agent to read `carry_unknown_count` before quoting headroom, and warns against treating transfer prices as renewal prices. It implicitly differentiates from `quote_domain` by focusing on account-level finances rather than per-domain quotes.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds critical behavioral context beyond that: it emphasizes that this is retrieval, not authority, warns that vector search always returns the nearest neighbor and may appear confident even when incorrect, and describes the return format (passages with source, URL, and citation purpose). This is exactly the kind of context that helps an agent avoid misuse.

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

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

The description is long but densely packed with essential information. It front-loads the primary use case and the critical warning, and repeats the 'do not use for decisions' point for emphasis, which is effective but slightly redundant. Every sentence adds value, and the structure is logical.

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

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

The description covers the tool's purpose, limitations, and return value shape, and effectively routes to sibling tools. It does not describe parameter details (addressed above), but given the tool's simplicity, this is the only notable gap. It is otherwise complete for an agent to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate, but it does not. It mentions 'semantic search' and implies a natural-language query, but does not explain 'top_k' (e.g., range, default, effect on result count) or any query formatting guidance. The purpose is clear, but parameter specifics are left entirely to the schema, which has no descriptions.

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

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

The description states a specific verb (search) and resource (knowledge base) and clearly distinguishes the tool from siblings by declaring it is for understanding, not deciding, and names the dedicated tools for policy and registration. It is unambiguous and actionable.

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

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

Explicitly states when to use the tool (to understand how something works) and when not to use it (to decide anything), and names the alternative tools (GET /tld/:tld/policy and check_live) that take precedence. This provides clear routing with no inference needed.

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

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

The annotations already provide readOnlyHint, idempotentHint, and destructiveHint, and the description adds value by clarifying the read-only behavior ('Cannot spend money') and by disclosing a potential pitfall: scan_age_ms is included so stale verdicts are not mistaken for fresh ones. This is meaningful behavioral context beyond the structured annotations.

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

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

The description is well-structured and front-loaded with the primary use case. Minor redundancy exists: 'Read-only' and 'Cannot spend money' say the same thing and are also covered by annotations, so a small amount of trimming could tighten it further.

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 inventory tool with no output schema, the description is sufficiently complete. It states the exact data scope, the freshness guard (scan_age_ms), the non-spending guarantee, and the appropriate trigger questions. An agent has everything needed to call it correctly.

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

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

The tool has 0 parameters, so the baseline is 4. The description adds no parameter-specific detail because none is needed; it instead clarifies what the returned inventory will contain, which is more relevant for a no-argument list tool.

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

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

The description states a specific verb ('List'), an explicit resource ('the user's domain inventory'), and enumerates the returned data (verification challenge status, cached liveness, classification, title, expiry). This clearly distinguishes it from siblings like check_live or verify_ownership by framing it as the inventory overview 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 description gives explicit usage contexts: start of portfolio, renewal, and 'what do I own' questions, and tells the agent to use it before suggesting a purchase. It does not explicitly name alternative tools or state when not to use it, but the situational guidance is clear enough to route correct invocation.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds value by explicitly stating 'Cannot spend money' and scoping the operation to the user's portfolio. It also discloses the kind of data returned, which is useful since no output schema exists.

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

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

Three short, purposeful sentences: what the tool does, safety behavior, and when to call it. There is no filler or repetition beyond a useful restatement of the read-only guarantee in domain terms ('Cannot spend money').

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

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

For a zero-parameter read-only list tool, the description is complete: it states scope, output fields, safety profile, and recommended invocation timing. No output schema exists, but the description names the important return fields, so an agent can invoke and interpret the result correctly.

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

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

The tool has zero parameters, so the description has no parameter burden to carry. The empty input schema fully covers the parameter surface, and the description adds no misleading or unnecessary parameter 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?

The description names a specific verb ('List'), a specific resource ('drafts in the user's Scopeweb portfolio'), and the included fields (status, preview URLs, timestamps). It clearly distinguishes from siblings like get_draft (single item) and list_domains (different resource).

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 explicit usage context: 'Call this at the start of a session to see existing work.' It does not explicitly mention alternatives or exclusions, such as using get_draft for a single draft, but the guidance is clear enough for selection.

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

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

The description goes far beyond the annotations: it discloses the re-run of the authoritative gate, the non-purchase confirm_url, quote expiry, premium pricing behavior, and the absence of any purchase-completing tool. This is rich behavioral context that annotations alone could not provide, and nothing contradicts the readOnlyHint.

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

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

The description is front-loaded with the purpose but becomes verbose and repetitive. Phrases like 'It is NOT a purchase and you cannot make one', 'THE CONFIRM URL IS NOT A PURCHASE', and 'There is deliberately no tool to complete an order' repeat the same idea. Several sentences could be merged or removed without losing meaning.

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

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

For a single-parameter read-only tool with no output schema, the description is thorough. It lists the return fields (total_cents, renewal_cents, expiry, confirm_url), explains edge cases (premium, expired quotes, registered names), and even clarifies the role of budget context. Nothing critical for correct invocation or expectation-setting 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?

With schema description coverage at 0%, the description must carry parameter meaning. It partially does by explaining the domain must be an unregistered name and quoting is gated. However, it also references a 'project_id' parameter that does not exist in the input schema, which is misleading and reduces reliability for agents constructing calls.

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

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

Description states a specific verb and resource: get the real price for a domain name the user has chosen. It explicitly distinguishes from purchase by saying 'It is NOT a purchase' and from other read tools by focusing on price quoting. The purpose is unambiguous and immediately actionable.

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

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

Explicitly says 'Use this when the user has chosen a name and wants the real price' and clearly states the tool cannot purchase. It also includes when-not conditions, e.g., registered names are never quoted. However, it does not name alternative sibling tools, so it misses the full 'alternatives' component of a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and mutation. The description adds valuable context beyond annotations: it states it cannot spend money (a cost constraint) and lists the specific return fields (registered, resolves, serves, parked, classification, liveness). This enriches the behavioral picture without contradicting any annotation.

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 exactly two sentences: the first front-loads the core action and constraint, the second provides the alternative tool and the return summary. Every word earns its place, with no fluff or repetition.

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

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

Given a single parameter, no output schema, and moderate complexity, the description is fully sufficient. It explains what the tool does, its constraints, its alternative, and the shape of its return data. An agent has everything needed to invoke it correctly without further elaboration.

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 'candidates' parameter, which already explains it expects full domain names with a max of 25. The tool description adds the notion of an 'explicit list', implying exact matches rather than fuzzy or conceptual input. This is a subtle nuance beyond the schema but not substantial—the schema already carries the core meaning, so a baseline score of 3 is appropriate.

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

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

The description explicitly states the verb 'Classify' and the resource 'an explicit list of candidate domains' with a clear maximum of 25. It also distinguishes itself from suggest_names, which is a sibling tool, making the purpose unambiguous and easy to differentiate.

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

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

The description explicitly says to use suggest_names instead when you have a concept rather than a list, giving clear when-to-use and when-not-to-use guidance. It also notes that the tool is read-only and cannot spend money, which further clarifies appropriate usage.

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

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

It goes well beyond annotations by disclosing 'Cannot spend money', the auditable component-level scores, the CAP on severe properties, and that unmeasurable components are never estimated. These are non-obvious behaviors that materially change how an agent should interpret the result.

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

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

The description is dense but every sentence earns its place: the when, the exclusions, the auditability, the cap, and the estimation policy. It is front-loaded with the use condition and structured so critical limitations come before the scoring details are absorbed.

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 how results are composed (score, weight, basis) and how severe properties cap the total. It also explains what happens for unmeasurable components, which covers the main risks an agent would face when invoking 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?

The input schema covers both parameters thoroughly (domain and domains) at 100% coverage. The description adds context about scoring candidate names but does not add new parameter-level constraints or formats; the schema already carries the semantic weight.

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 action and resource: 'Grade candidate names' on a set of measurable properties. It explicitly differentiates itself from check_live (availability), search-ranking prediction, and trademark search, so an agent can tell it apart from siblings without inspecting schemas.

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

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

The description says exactly when to use the tool: when the user is choosing between names or asks whether a name is any good. It also names the alternatives to use instead, including check_live for availability and explicit exclusions for search-ranking and trademark search, leaving no ambiguity.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It meaningfully explains what the tool returns: candidate names across every ending, each tagged with one of five ownership/defensibility states. It does not mention side effects or performance characteristics, but for a search-like read operation the disclosed behavior is clear and usable.

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

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

The description is two tight sentences with no filler. The first sentence front-loads the action and outcome; the second delivers the critical input rule. Every phrase 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 tool with no output schema, the description covers both the input constraint and the return semantics: candidate names plus their defensive state categories. It does not elaborate on each state, but the low complexity and clear schema make the description adequately 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 schema already fully covers the single query parameter, which sets a baseline of 3. The description adds value by framing the input as a concept rather than a domain, effectively giving the agent a negative constraint that is absent from the schema.

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

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

The description uses a specific verb and resource ('Find domain names for an idea') and explains what the result contains (candidates with defensibility states). It also differentiates itself from domain-specific siblings by explicitly instructing the agent to pass a concept, not a domain.

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 clearly states the intended use case: an idea should be turned into candidate domain names. It gives a 'when-not' guidance ('Pass the concept, not a domain'), but it does not explicitly name alternative sibling tools or state when those should be preferred, so it falls just 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?

The description goes well beyond the annotations by explaining response behavior (CURRENT CARRY and HEADROOM are precomputed), edge-case semantics (unknown renewal prices count as unknown, never zero, making headroom an upper bound), and the important fact that budget affects recommendations but never prices. This is rich, non-obvious behavioral detail.

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 usage trigger and contains valuable details, but several sentences repeat the same point: 'It records their ceiling', 'Records a number you chose', and 'Cannot spend money and cannot buy anything' are redundant. The all-caps pricing sentence also adds noise despite being important.

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

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

Despite having no output schema, the description explains what the response contains (CURRENT CARRY and HEADROOM) and the special partial-headroom case. It also addresses pricing misconceptions. Missing only minor details like overwrite behavior, but with idempotentHint=true and the rich narrative, this is adequate for correct invocation.

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

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

Schema description coverage is 0%, so the description must carry the weight. It does this by explaining that period is monthly or yearly, amount is expressed in cents, and the target is a project. It does not give detailed constraints or ranges, but it meaningfully maps to all three parameters.

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

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

The description uses specific verbs and resources: it records a spending limit for a project and never authorizes a purchase. It clearly differentiates itself from purchase-related actions and from pricing tools by stating it cannot spend or buy anything and that prices are unaffected by budget.

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

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

It gives an explicit trigger: 'Use this when the user states a spending limit for a project.' It also provides exclusions ('never authorises a purchase', 'Cannot spend money and cannot buy anything'), but does not name alternative sibling tools or explicitly contrast with them.

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, and the description adds meaningful behavioral detail: it cannot spend money or start/change/cancel subscriptions. It also adds the key domain rule that plans gate depth, never truth, so the agent will not present upgrades as changing registration verdicts.

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 rich but somewhat verbose, with repeated emphatic phrasing such as 'Paying buys more of the picture, never a different answer about reality.' It makes its key points, but multiple sentences restate the same idea, and the all-caps phrase adds weight more than clarity.

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

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

There is no output schema, so the description carries the burden of explaining the return value. It specifies that available plans, inclusions, current tier, allowances used, and invariant truths are listed. Combined with the zero parameters and safety annotations, this is complete enough for an agent to invoke the tool correctly.

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

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

There are zero parameters, and schema coverage is 100%, so there is nothing for the description to add about parameters. The baseline of 4 applies because no parameter guidance is needed.

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

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

The description states a clear verb and resource: 'Show the available plans with what each includes, plus the caller's current tier and any allowance they have used.' It also clarifies the purpose by tying it to real user needs like asking for tier costs or hitting limits. This clearly differentiates it from reading as a generic pricing or subscription 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 description explicitly states when to use the tool: when the user asks about tier costs, bumps into a limit, or when a refusal points to an exhausted allowance. It does not name alternative tools or explicitly say when not to use it, leaving some sibling differentiation 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 readOnlyHint annotation, the description discloses key non-obvious behaviors: it cannot spend money, unregistered does not mean purchasable, reserved/premium names answer the registry the same way, only a registrar quote settles a price, and prices are identical regardless of budget. It also explains scan_id convergence behavior across re-queries.

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

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

The description is long but densely packed and front-loaded with the most important invocation trigger. Each subsequent sentence adds workflow, exclusion, or behavioral guidance; the rename note and pricing caveats earn their place by preventing common agent mistakes.

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

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

Given no output schema, the description still communicates what comes back (ranked candidates classified by availability) and provides the operational constraints needed to call it correctly. It also completes the wider workflow by naming scan_namespace, score_name, and check_live as the surrounding steps, leaving no critical gap for an agent.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds semantic value beyond the schema by explaining that query is a 'CONCEPT', that results are ranked and classified by availability, and that re-querying the same scan_id walks deeper into the namespace. Limit, offset, and tlds still rely mostly on the schema, so this is not a full 5.

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

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

The description opens with a specific behavior: 'returns candidate names across a namespace' for a user choosing or inventing a name, and includes concrete trigger phrases. It clearly distinguishes itself from sibling tools like scan_namespace and score_name rather than merely restating the tool name.

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

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

It gives explicit when-to-use guidance ('START HERE when the user is choosing or inventing a name'), example user utterances, and direct alternatives: 'Use scan_namespace instead when you already have an explicit list.' It also sequences the workflow with score_name and check_live, and explains when NOT to treat results as final pricing.

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 carry readOnly=false, destructive=false, idempotent=false, so the description adds useful patch semantics rather than redisclosing safety. It explains omitted files are carried forward, previous versions are immutable, and the response includes the new version and preview_url. This clarifies behavior beyond a mere mutation label.

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, each with a distinct job: trigger, prerequisite, action, patch behavior, retention, return value. Front-loaded with the when-to-use condition, 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?

For a 2-param update tool with no output schema, the description fully covers invocation flow, versioning, and return value. An agent can call it correctly without needing additional information beyond the schema and annotations.

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

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

Schema coverage is 0%, so the description carries the burden for the two parameters. It explains the lifecycle behavior of `files` (sent files become a version, omitted files carry forward), but it never names `draft_id` explicitly or gives structure for path/content; those are obvious from the schema but not documented in prose. Adequate compensation for a small, self-descriptive 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?

Clear verb+resource: 'Update files in an existing draft.' The phrase 'draft already exists' differentiates it from create_draft, and the mention of copy, sections or layout clarifies scope. No 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?

Explicit when-to-use: 'Use this when a draft already exists and the user asks to change its copy, sections or layout.' It also gives a concrete prerequisite: call get_draft first if current text isn't available, which routes the agent to the correct sibling.

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 provide idempotentHint and non-destructive context, but the description adds valuable behavior: start returns a TXT record, check verifies it, failed DNS lookup returns an error rather than 'not owned', and verification gates list_domains. These are meaningful behavioral details beyond the annotations.

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

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

Every sentence earns its place: the trigger condition, the core mechanism, the action distinction, the list_domains dependency, and the error semantics. It is front-loaded with the most important usage guidance and avoids 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 no output schema, the description covers the necessary workflow, return behaviors, and a key error case. It also connects the tool to the broader system state via list_domains, making it complete enough for an agent to invoke correctly.

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

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

Schema coverage is only 50%, but the description compensates by explaining what each action does: 'start' returns the TXT record and 'check' verifies it. The domain parameter is self-evident from context. The description adds real meaning to the action enum beyond the schema's default note.

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: proving domain ownership via a DNS TXT challenge, with two explicit actions. It also distinguishes itself by explaining that verification is required before a domain appears in list_domains, differentiating it from sibling domain-related tools.

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

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

Explicitly says to use it when the user claims a domain is theirs and the agent is about to act on that claim. It also provides workflow guidance (start then check) and states the prerequisite relationship to list_domains, which serves as clear when-to-use context.

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