MCPDomain

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

With no annotations provided, the description carries the full burden of disclosing behavior. It states the tool returns availability status, price, and alternatives if taken, and implies a read-only check by being a precursor to registration. It does not explicitly state non-mutation or limitations, but the description is clear enough for a simple lookup tool.

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

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

The description is concise and well-structured: a purpose statement, a returns line, and an explicit WHEN TO USE section. Every sentence adds value, with no redundancy or filler.

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

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

For a simple single-parameter tool with no output schema or annotations, the description covers the core function, return content, and usage context. It also implicitly differentiates from sibling tools like suggest_available_domains and register_new_domain, making it sufficiently complete for an agent to decide when to invoke it.

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 defines the only parameter 'domain' with an example. The description adds minimal extra semantic value, only repeating the notion of checking a specific domain name and providing examples in usage guidance. Baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: checking if a specific internet domain name is available for registration. It also differentiates from siblings like register_new_domain and suggest_available_domains by specifying that it returns availability status, price, and alternatives if taken.

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

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

Provides explicit WHEN TO USE guidance with concrete examples ('user asks 'is X.com available?''), and directly prescribes that this tool should ALWAYS be called before register_new_domain. This clearly communicates the intended use case and relationship to sibling 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?

With no annotations, the description carries the full burden for disclosing behavior. It states 'Add/update' but does not warn that existing DNS records may be overwritten, that propagation can be delayed, or that modifying DNS can have service-affecting consequences. The replacement behavior is only mentioned in the schema, not 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?

The description is short, front-loaded with the action and resource, and uses a distinct 'WHEN TO USE' label. Every sentence adds value without unnecessary fluff.

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

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

The tool is moderately complex with nested records, and the schema is rich, but the description does not mention what the tool returns on success, whether changes are immediate, or how propagation is handled. The description is adequate but lacks some contextual depth for a mutation tool with 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?

The input schema has 100% description coverage, providing detailed explanations for domain and records including record types, TTL, and priority. The description adds minimal parameter-specific semantics beyond the schema, mostly repeating the record types already covered.

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 'Add/update DNS records' and names specific record types (A, CNAME, MX, TXT), making it clear this tool manipulates DNS records. The use case 'point domain to Vercel, Netlify, GitHub Pages' distinguishes it from sibling tools like configure_domain_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 clearly states 'WHEN TO USE: user wants to connect domain to hosting,' providing a concrete trigger condition. It does not explicitly mention when not to use it or alternatives, but the context is clear enough from the sibling tool names.

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

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

With no annotations, the description carries the full burden for behavioral transparency. It usefully discloses that no MX records are needed and that forwarding targets Gmail/Outlook. However, it does not describe what happens to existing email settings, whether forwarding is additive or replaces existing config, or any 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?

The description is two sentences plus a labeled WHEN TO USE section. It is front-loaded with the action, wastes no words, and 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?

With 100% schema coverage and no output schema, the description provides adequate usage context: it mentions registration prerequisite and the key technical fact about MX records. It does not go into edge cases, but for a setup tool this is sufficient.

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 thoroughly. The description adds little beyond the mention of 'any@domain' which loosely aligns with the catch_all_to parameter. Per the rubric, baseline 3 applies when 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?

The description clearly states the action ('Set up email forwarding') and the resource ('a registered domain'), and specifies the forwarding behavior ('Forward any@domain to Gmail/Outlook'). 'No MX records needed' distinguishes this from the DNS configuration 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?

The 'WHEN TO USE' section explicitly indicates triggers: after domain registration or when the user asks about professional email. It does not explicitly state when not to use the tool or name alternatives, but the context is clear.

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

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

Since no annotations are provided, the description carries the full burden of disclosing behavior. It lists exactly what the tool returns (registered_at, expires_at, nameservers, email-forwarding status) and enumerates possible statuses ('active / pending verification / pending NS propagation / etc'), giving the agent a clear picture of the output. While it doesn't mention error handling or rate limits, the disclosure is detailed for a lookup tool.

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

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

The description is concise and well-structured: it opens with the primary purpose, lists key return fields, and ends with a 'WHEN TO USE' section containing concrete examples. Every sentence carries informational value, and the 'WHEN TO USE' label improves 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?

With no output schema, the description appropriately explains return values (registered_at, expires_at, nameservers, email-forwarding status). It also includes common user intents, covering likely use cases. It could mention behavior when the domain is not found or not owned, but for a single-parameter lookup tool, the description is largely 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 input schema already provides a comprehensive description for the single parameter: 'A domain previously registered via register_new_domain.' With 100% schema coverage, the description adds no additional parameter semantics. Per the rubric, baseline is 3 when schema coverage is high, and no extra value 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 clearly states the tool's function: 'Look up the registration status of a domain you previously registered through MCPDomain.' It specifies the exact resource (domains registered via MCPDomain) and the verb 'look up,' which distinguishes it from sibling tools like check_domain_availability (which checks availability before registration) and configure_domain_dns/email (which modify settings).

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

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

The description provides explicit usage scenarios under 'WHEN TO USE' with example user questions like 'is my domain ready?' and 'did email forwarding finish setting up?'. This gives clear context for when to invoke the tool. It does not explicitly name alternatives or state 'when not to use,' but the phrase 'previously registered' implies exclusions (e.g., not for availability checks), providing some differentiation.

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?

Without annotations, the description discloses that this tool returns a payment URL and only registers after payment, plus includes features like email forwarding and AI monitoring. It does not mention failure modes or refunds, but the payment caveat is a critical behavioral trait that is clearly stated.

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 focused sentences with the key action, payment outcome, and preconditions. The use of capitalization for critical instructions is effective and the description is free of fluff.

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

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

For a complex transactional tool, the description covers the payment flow, post-payment features, and required preconditions. It could mention error handling or the one-time nature of the checkout URL, but the core decision-making information is present.

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

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

Schema coverage is 100%, so the schema documents all parameters thoroughly. The description adds the prerequisite to check availability and to collect specific user fields, but these are also in the schema; it does not provide new semantic details beyond the schema.

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

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

The description clearly states 'Register a new domain' and specifies the payment flow via Stripe checkout URL. It distinguishes from sibling tools like check_domain_availability and transfer_existing_domain by focusing on new registrations.

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 'ALWAYS call check_domain_availability first' and requires collecting first_name, last_name, and email before calling, providing clear preconditions. It implies this tool is for new registrations, not transfers or DNS configuration, setting expectations.

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 must carry the behavioral disclosure burden. It adds one key behavioral trait: 'real-time availability checks.' However, it does not specify whether results are filtered to only available domains, the output format, or any limitations. This is a meaningful but incomplete disclosure.

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

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

Two concise sentences: the first states the core function, the second gives practical usage examples. No filler or redundant information; the structure is front-loaded and efficient.

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

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

The tool has a simple schema and no output schema or annotations. The description explains what the tool does but does not explicitly describe the return format (e.g., list of suggestions with availability status). While the behavior is implied, the missing output details prevent a higher score.

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 covers all three parameters with descriptions and defaults (e.g., tlds default, max_results default). The description adds no extra semantic detail beyond what's in 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?

The description uses a specific verb ('Generate') with a clear resource ('domain name suggestions') and source ('keywords or business description'). It distinguishes itself from sibling tools like check_domain_availability, which checks a specific domain, by focusing on generation of suggestions.

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

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

The description provides explicit 'WHEN TO USE' guidance with concrete user utterances ('help me find a domain for my bakery'). It lacks explicit alternatives or exclusions, but the context clearly indicates this tool is for brainstorming domains rather than checking or registering specific ones.

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 provided, the description carries full burden for behavioral disclosure. It reveals non-obvious consequences: the transfer takes 5-7 days and adds 1 year to expiry. It also mentions the prerequisite of an EPP/auth code. While it does not cover reversibility or post-transfer management, the core behavior and timeline are transparent.

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

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

The description is three concise sentences: the main action, the requirement, and the duration/impact. It is front-loaded with the verb and resource, contains no filler words, and every sentence contributes essential 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?

The description is sufficiently complete for a mutation tool of moderate complexity. It explains what happens, the timeline, and the effect on expiry, while the schema covers additional prerequisites (e.g., domain age, unlock status). No output schema exists, but the description gives enough context to understand the outcome. It could mention potential failure reasons, but overall it is adequate.

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 provides 100% coverage with detailed descriptions for both parameters, including conditions for 'domain' and synonyms for 'auth_code'. The description adds no new parameter-specific information beyond restating the need for an EPP/auth code, which the schema already explains. Thus, the 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 clearly states the action with a specific verb ('Transfer'), the resource ('a domain'), and the context ('from another registrar ... to MCPDomain'). This distinguishes it from sibling tools like register_new_domain and configure_domain_dns, leaving no ambiguity about its 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?

The description implies when to use the tool: when the user has an existing domain with another registrar and possesses the EPP/auth code. It also provides practical guidance by noting the 5-7 day transfer time and the addition of one year to expiry. It does not explicitly list exclusions but the context is clear enough for an agent to select it appropriately.

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