dotmoose

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds a genuinely useful negative disclosure ("never returns WHOIS contact data") and implies a live network lookup, but says nothing about whether the result is a boolean, a price, or suggested alternatives, nor about rate/latency behavior.

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

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

Two short sentences, front-loaded with the action and free of filler. The second sentence earns its place as a scope-boundary disclosure, though the phrasing could be folded more tightly into the first.

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-param read-only tool with annotations covering safety, the core is present, but the description omits what the response conveys and how the caller should normalize the domain string. Without an output schema, those gaps matter 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?

With one parameter and 0% schema description coverage, the description must carry the burden, and it offers only the adjective "normalized" without explaining the normalization rules (strip scheme, lowercase, punycode/IDN handling). It hints at the required input format but leaves the operative detail unspecified.

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

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

States a specific verb ("Check") and resource ("a normalized domain") against the live DotMoose lookup path, which distinguishes it from the pricing-oriented sibling quote_domain. The word "availability" appears only in the name/title, so the description alone doesn't quite declare the outcome the tool 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?

There is no explicit when-to-use or when-not guidance, and the obvious alternative (quote_domain) is never named despite being in the sibling set. An agent must infer that this is the pre-pricing availability check rather than the quoting step.

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, so safety is covered; the description adds real value by disclosing the curation filter (only publicly visible, still-active codes) and the important caveat that returned promotions may not apply at checkout due to revalidation of eligibility and stacking. Return shape and pagination remain undocumented.

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, front-loaded with the scope constraint followed by filter optionality and the checkout caveat. No filler, though the final caveat sentence could have been folded in more economically.

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 read-only nature is annotated and the scope/caveats are explained, but with no output schema the description says nothing about what a promotion record contains or how results are ordered or bounded. For a simple two-optional-param list tool it is adequate, but an agent still cannot anticipate the response.

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

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

Schema description coverage is 0%, so the description has to carry weight; it names both parameters conceptually ('product and billing-cycle filters are optional') and confirms they are non-required. It adds no meaning about what a productRef refers to or how billingCycle constrains results beyond the enum already in the schema, so compensation is only partial.

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 clear verb and resource ('List ... promotion codes') and narrows scope precisely to codes 'explicitly curated for public MCP visibility and still active in current DotMoose commerce data.' That scope language distinguishes it from any general promotion lookup, though none of the listed siblings are close enough for explicit 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?

Implies when the tool is appropriate ('optional' filters, curated public codes) and warns that 'First-party checkout revalidates final eligibility and stacking,' which hints the result is not authoritative for pricing. However, it never says to use quote_public_product or quote_domain for binding prices, so the routing 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?

With readOnlyHint already covering the safety profile, the description adds useful behavioral context: results come from fresh DotMoose commerce data, only currently public/active/orderable fixed products are included, and the no-family-filter case returns a curated directory of guided handoffs. It does not cover pagination or response size, but it meaningfully explains what the caller will receive.

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

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

The description is two sentences and front-loads the core listing behavior before explaining the conditional directory expansion. The second sentence is dense with a long enumeration but every part earns its place by defining response scope.

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

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

For a read-only, one-parameter listing tool with no output schema, the description covers the key behavioral distinction between filtered fixed-product results and the expanded directory results. The main gap is the lack of detail about the `family` parameter's valid format and values, which leaves part of the call semantics undocumented.

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 full burden for the single `family` parameter. It partially does: it identifies the parameter as a fixed-family filter and explains that omitting it expands the response to include the curated directory. It does not explain the slug format, valid values, or examples beyond what the schema's regex implies.

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

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

The description gives a specific verb and resource: listing fixed products that are currently public, active, available for sale, and orderable. It also distinguishes fixed products from the curated directory of guided handoffs, which clarifies scope. However, it does not name any sibling tool, so an agent still has to infer the boundary with tools like quote_public_product or recommend_product.

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 the listing scope and by the conditional behavior when no family filter is supplied, but there is no explicit when-to-use or when-not-to-use guidance. The description never names alternatives or says which sibling tool to choose for quoting, recommending, or checking availability.

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 the description repeats 'This tool is read-only' rather than extending it. It does add one genuinely useful behavioral constraint: only non-sensitive project characteristics should be supplied. It says nothing about the shape of the recommendation, whether it is advisory only, or how the result should be interpreted — and with no output schema, that burden remains entirely on the 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?

Two tight sentences: the capability first, the safety constraint second. Nothing is padded. The only wasted clause is the read-only restatement, which duplicates the annotation.

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 pure advisory tool with 11 inputs and no output schema, the description establishes what it does and that it is safe, but not what comes back or how the inputs are weighed. An agent cannot tell whether omitting requiresRoot or needsDatabase degrades the recommendation, nor what a returned 'product and workflow' looks like.

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% across 11 parameters, so the description is the only place meanings could be explained, and it explains none of them. It names no parameter, gives no guidance on the enum values (appType, runtime, expectedTraffic) or on the booleans such as requiresRoot, customTcpPorts, or hasDockerfile, which materially change the recommendation. The phrase 'non-sensitive' is the only substantive hint, and it does not map to a specific 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?

A specific verb pair (analyze/recommend) applied to a concrete resource: the smallest DotMoose product plus publication workflow for a named app type. The enumerated app categories mirror the appType enum, so an agent can match input to tool. It stops short of distinguishing itself from the sibling recommend_product, which read-only listing suggests is the nearest 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?

Usage is implied by the scope ('plan how to publish' vs. quoting or signing up), but there is no explicit when-to-use or when-not-to-use statement and no pointer to sibling tools like recommend_product, quote_public_product, or list_public_products. The agent must infer the routing from 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 already establish readOnlyHint=true, so the safety profile is clear. The description adds meaningful behavior beyond annotations: pricing is in CAD, limited to standard TLDs, and premium-domain pricing is explicitly non-authoritative until checkout recalculates 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?

Two sentences, front-loaded with the core behavior, with zero redundant wording. The premium-pricing caveat is placed second, where it reads as a qualification rather than a distraction.

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 no schema descriptions, the definition should do more to explain what a quote response contains and how years affects pricing. The CAD/standard-TLD/premium caveats are helpful but leave the return shape and term-length behavior underspecified.

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 parameter meaning. It covers the operation values (register, transfer, renew) and implies domain, but never explains the years parameter or its 1–10 range, leaving a meaningful parameter undocumented.

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 ('Return') and resource ('current standard CAD TLD pricing') and enumerates the three operations. It differentiates somewhat from sibling quote_public_product by scoping to TLD pricing, though it does not explicitly contrast the two.

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 'Return pricing for registration, transfer, or renewal,' but the description gives no explicit guidance on when to use this versus check_domain_availability or quote_public_product. The premium-pricing caveat is useful context but not a routing 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?

With readOnlyHint=true already signaling a safe read, the description adds useful behavioral context: the quote is short-lived, non-binding, CAD-denominated, sourced from current sales data, and not the final checkout step. It does not describe return fields or rate limits.

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

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

Two tight sentences: the first front-loads the action and key qualities of the quote, and the second clarifies the checkout boundary. 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?

The description adequately covers the quote's nature and checkout boundary, and annotations cover safety. However, for a tool with 0% schema description coverage, it leaves productRef and billingCycle behavior undocumented, which is a meaningful gap 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%, yet the description does not explain productRef format, accepted product references, or billingCycle semantics. The parameter names are somewhat self-descriptive and the enum is visible in the schema, but the description adds no meaning beyond the schema.

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

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

The description states a specific verb and resource: return a quote for a current DotMoose product, with CAD currency and non-binding status. It implicitly distinguishes itself from product-listing and domain-quoting siblings, but does not explicitly differentiate 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 note that final tax and payment occur in first-party checkout implies this tool is for pre-checkout quoting rather than purchase completion. However, it does not explicitly say when to use this versus list_public_products, recommend_product, or start_signup.

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?

readOnlyHint=true is consistent with a recommendation operation, and the description adds real context beyond the annotation: it discloses that recommendations and optional add-ons are derived from live public availability rather than a hard-coded price table, and that the dedicated path returns a quote handoff instead of a product. Return shape is only partially characterized (no output schema), which keeps it below 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?

Two dense sentences with zero filler, and the primary behavior is front-loaded before the dedicated-case exception. Slightly jargon-heavy ('workload-specific Dedicated quote handoff'), but every clause conveys information.

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

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

With six undocumented parameters and no output schema, the description should explain what a recommendation actually contains and how the traffic/root/domain flags alter the result. It covers the availability-sourcing and the dedicated branch well, but leaves the agent guessing about the returned structure and about three of the six inputs.

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 burden. It adds meaning for roughly half the parameters — the 'goal' maps to workload, 'bare metal explicitly requested' maps to workload=dedicated, and 'optional backup/object-storage components' maps to needsBackup/needsObjectStorage — but expectedTraffic, needsRoot, and needsDomain get no explanation of how they change the recommendation.

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: recommend the smallest currently orderable public product set, with a named secondary behavior for the dedicated/bare-metal case. It is clearly distinct from the sibling listing/quoting tools (list_public_products, quote_public_product) because it produces a recommendation rather than a list or a firm quote.

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?

Implies usage ('for a goal') and gives one routing condition — bare metal explicitly requested routes to the Dedicated quote handoff. It does not say when to prefer this over quote_public_product or list_public_products, nor what the agent should do with the recommendation afterwards, so the guidance is implied 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 declare non-read-only, non-destructive, closed-world, but the description adds genuinely new behavior: the intent is short-lived and signed, and no account is created until the user completes the first-party page. That clarifies side effects and the handoff, which the annotations alone do not convey. It doesn't state token TTL or what happens on expiry.

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 tightly written sentences: the action and return value are front-loaded, followed by the handoff context. 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?

The flow context is well explained and no output schema exists so return values are covered by the URL mention. However, with a nested domainIntent object and zero parameter documentation, an agent lacks enough to build correct arguments beyond guessing from names.

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% and four parameters (productRef, billingCycle, domainIntent with mode/domain, promotionCode) are documented only by their types and patterns. The description mentions 'product-selection' vaguely but never explains what productRef accepts, what domainIntent modes mean, or how promotionCode is applied, so it fails to compensate for the coverage gap.

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: creates a short-lived signed product-selection intent and returns a continuation URL. It conveys the tool's role as the entry point to checkout, though it never names the siblings it differs from (quote_public_product, recommend_product).

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 'signup/checkout' and the note that account creation and payment happen on the continuation page, which signals this is a pre-checkout step. There is no explicit when-not or routing to quote/recommend siblings, so the agent must infer that this is the terminal 'start purchase' action rather than a pricing call.

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