namecheap-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation4/5
Most tools target clearly distinct actions, but check_domain_availability and get_domain_pricing both deal with pricing/availability and could be confused without reading descriptions carefully. All other tools have clear boundaries, including the DNS trio (get, modify, replace_all) where descriptions emphasize the safe vs dangerous distinction.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_domain_info, set_nameservers, renew_domain). No mixing of styles or vague verbs, making the set predictable and scannable.
Tool Count4/5
At 20 tools, the count is on the heavy side but each tool serves a distinct domain-management function (lifecycle, DNS, nameservers, email forwarding, privacy, billing, transfers). The breadth justifies the count, though it slightly exceeds the typical well-scoped range.
Completeness4/5
The toolset covers the full domain lifecycle: availability, pricing, registration, renewal, reactivation, transfer, DNS management, nameservers, email forwarding, privacy, and billing. Minor gaps exist (e.g., no direct tool to update domain contact info or toggle auto-renew), but these are edge cases agents can work around.
Average 4.5/5 across 20 of 20 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, so the read-only nature is known. The description adds a non-obvious behavioral constraint: forwarding only works with Namecheap DNS. This is beyond the annotations and provides useful context. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that cover purpose, scope, a usage condition, and the read-only nature. Every sentence contributes meaning with no fluff or repetition. It is ideally sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter), has an output schema, and read-only annotations. The description includes the essential purpose and an important prerequisite (Namecheap DNS). It omits edge-case behavior (e.g., what happens if the domain is not on Namecheap DNS), but given the tool's minimal complexity, the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain the 'domain' parameter beyond restating 'for a domain' in the first sentence. With a single parameter named 'domain', the description adds no format, example, or constraint beyond what the parameter name and minLength imply. This fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('email-forwarding rules for a domain') with the mapping format (mailbox -> destination). It distinguishes itself from sibling tools like set_email_forwarding and get_dns_records by naming a distinct resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage condition: email forwarding only works while the domain uses Namecheap DNS. It does not explicitly name an alternative tool, but the read-only hint and 'List' verb imply that this is for reading, while set_email_forwarding is the write counterpart. The single constraint gives context, but no direct alternative or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and readOnlyHint=false, so the description's 'Idempotent' adds no new information. It does add value by explaining automatic WhoisGuard subscription resolution and the role of forwardedToEmail for WHOIS contact mail relay. Yet it does not disclose potential costs or external side effects despite openWorldHint=true, so transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at four short sentences, with the core purpose front-loaded in the first sentence. The final sentence 'Idempotent' is redundant with the idempotentHint annotation, but it is harmless. Overall, every sentence earns its place except that minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return value details are covered. The description covers the toggle behavior, automatic subscription resolution, and conditional email requirement, which is sufficient for correct invocation. Minor gaps: it does not mention how to check current privacy state or what happens if no WhoisGuard subscription exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, and the description adds important meaning to forwardedToEmail by clarifying it is 'Required when enabling,' which is not evident from the schema's optional flag. It also reinforces enabled's true/false semantics. It does not add domain format guidance, but the conditional requirement is a meaningful enhancement over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Turn WhoisGuard/domain privacy on or off for a domain.' The verb 'Turn...on or off' plus resource 'domain privacy' is specific and unambiguous, and the setter action clearly distinguishes it from the sibling get_domain_privacy tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a key usage condition: 'Enabling requires a forwardedToEmail,' which tells the agent when a parameter is mandatory. It also notes automatic subscription ID resolution, giving context. However, it does not explicitly mention alternatives like get_domain_privacy for checking current status, so it stops short of full when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation by revealing that the tool internally combines two distinct API calls ('domains.getInfo with the registrar-lock lookup') and explicitly states 'Read-only'. It also clarifies the scope of the data returned. No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence states the purpose and lists the data fields, the second clarifies the internal composition and read-only nature. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, read-only, output schema present), the description is largely complete. It covers what is included, how the tool works (combining two lookups), and its safety. The presence of an output schema obviates the need to detail return values. A slight gap: it doesn't mention potential edge cases (e.g., domain not found), but this is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single parameter 'domain' with a clear example. The description does not add additional parameter semantics beyond echoing 'one domain', which is redundant. Since schema coverage is 100%, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a coherent single view of one domain' and lists the specific data points included (registration, expiry, registrar-lock, privacy, DNS). It distinguishes itself from sibling tools by emphasizing that it combines multiple lookups into one call, making it the go-to for a comprehensive domain overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool—when you need a consolidated view of a domain without making multiple calls. It does not explicitly name alternative tools or state when not to use it, but the context is clear from the 'one call' phrasing and the enumeration of combined data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral detail: Route 53's apex NS set is what you give the registrar, and GoDaddy's v3 API cannot read nameservers back. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with purpose and then add a useful qualifier. No wordiness or redundancy; every clause contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and strong annotations, the description covers purpose, provider-specific behavior, and read-only confirmation. It implicitly differentiates from set_nameservers. A minor gap is the lack of explicit guidance on when not to use it, but that is largely covered by the tool's read-only nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description for 'provider' is thorough ('Force a provider instead of routing by domain...'). The 'domain' parameter is self-explanatory. With 50% schema coverage, the description does not compensate further, but it doesn't need to because the existing schema coverage is sufficient for the simple parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Show' plus resource 'nameservers for a domain', clearly distinguishing from sibling set_nameservers. It also adds provider-specific nuance (Route 53 apex NS set, GoDaddy limitation) that further clarifies the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool (reading nameservers for registrar) and notes a key limitation (GoDaddy cannot read back). It does not explicitly name alternatives or exclusions, but the read-only nature is evident from both description and annotations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces it with 'Read-only.' It adds value beyond annotations by specifying what fields are returned (domain, status, expiry) and the account scope. It does not mention pagination behavior, but the schema covers page/pageSize, so this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loaded with the action and resource. Every clause adds useful information: what is listed, included fields, and where to go for toggling. This is exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward list with output schema and annotations. The description covers the primary purpose, scope, and returned fields, making it sufficient for an agent to invoke correctly. The only gap is parameter semantics, which are already penalized in that dimension; overall the description is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only listType has a short description), and the tool description does not explain any parameters. The meaning of 'listType' with enum values (ALL, ALLOTTED, FREE, DISCARD) is only vaguely 'Filter subscriptions,' and page/pageSize are left to inference. Since the coverage is low, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('WhoisGuard/domain-privacy subscriptions'), scopes it to the account, and details included fields (domain, status, expiry). It also explicitly distinguishes from the sibling tool set_domain_privacy by pointing to it for toggling, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use set_domain_privacy to toggle a domain's privacy,' which explicitly names the alternative for a different action. This prevents misuse and clarifies when to use this tool versus its sibling. No other alternatives are needed given the input schema and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the readOnlyHint annotation by explaining that it maps numeric StatusID to a plain-English meaning and a coarse phase, and it explicitly says 'Read-only.' This provides useful behavioral information about the output transformation without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action and key resource, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool and the presence of an output schema, the description adequately covers usage. It doesn't need to detail return values or error handling, and it's complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes transferId as 'The TransferID from transfer_domain,' and the description repeats this context without adding new details. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'look up,' names the resource ('status of an in-progress or completed inbound transfer'), and specifies the input (TransferID). It clearly distinguishes itself from sibling tools like transfer_domain and get_domain_info by focusing solely on transfer status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the TransferID is returned from transfer_domain, implying the tool is used after initiating a transfer. It doesn't explicitly list alternatives, but the context makes the use case clear. This merits a 4 rather than a 5 because no when-not-to-use or alternative is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description repeats 'Read-only' but adds non-obvious behavior: provider selection logic, domain registrable-form handling, and the Route 53 record-set grouping with shared IDs and TTLs. This goes beyond the annotation safety profile and reveals important invocation nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight paragraphs: a front-loaded purpose sentence, then provider/domain semantics, then a brief provider-specific edge case. Every sentence earns its place; no fluff or repetition of schema data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only 2 parameters and an output schema, the description covers all invocation-relevant details: domain format, provider routing/force, and a meaningful Route 53 grouping behavior. It's sufficiently complete for an agent to select and call it correctly without additional research.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented, but the description enriches both: domain is further explained as the registrable domain with sub-domains placed in each record's `name`, and provider auto-routing vs. forcing is clarified. This adds practical meaning beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'List every DNS record for a domain' — a specific verb and resource that distinguishes this tool from siblings like modify_dns_records or get_nameservers. It also clarifies that it covers all providers and both the domain and provider selection logic, making the tool's scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains provider auto-routing and when to pass `provider` ('unless you pass `provider`'), and the schema adds that provider is needed when the domain doesn't exist yet. It doesn't explicitly compare to alternatives (e.g., 'use modify_dns_records for edits'), but the intended use case—listing existing DNS records—is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds the important behavioral caveat that these are standard non-premium prices. It also mentions the distilling behavior and per-year price tiers, going beyond the safety annotations to describe data behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded purpose, a behavior note, and a helpful alternative pointer. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full schema coverage and an output schema present, the description provides the necessary usage context, caveats, and sibling differentiation. It is complete for a simple read-only pricing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with described parameters, so baseline is 3. The description adds minimal parameter meaning beyond restating action options; it does clarify that the result is per-year tiers, but this is more output than input semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Get Namecheap's list price for one or more TLDs and an action' with explicit resource and scope. It distinguishes itself from the sibling tool by explicitly directing premium-domain pricing to check_domain_availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance with 'for premium domains use check_domain_availability, which returns premium pricing' as an alternative. Also indicates the tool distils users.getPricing, suggesting it is a focused subset for standard prices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the 'Read-only' mention is redundant. However, the description adds useful behavioral context by summarizing what each entry includes (expiry, lock, auto-renew, WhoisGuard, DNS usage), which goes beyond the schema and annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences), front-loaded with the main action, and every sentence adds value: the first states the purpose, the second details list content, and the third provides an alternative and safety note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values. It covers the tool's purpose, output summary, alternative tool, and read-only nature, making it fully context-rich for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 5 parameters, including defaults and enums. The description mentions paging and filtering generically but does not add semantic meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists domains in the Namecheap account with paging and filtering, and explicitly differentiates from get_domain_info by noting it provides a full single-domain view. The verb 'List' and resource 'domains' are specific, and the mention of paging/filtering further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs users to use get_domain_info for a full single-domain view, providing a clear alternative. It also implies appropriate use cases: listing domains with summaries and applying paging/filtering, which distinguishes it from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotation idempotentHint, the description explains the behavior of idempotency in plain terms ('setting the state it is already in is a no-op') and adds the rationale for locking (transfer protection). It does not cover edge cases like permissions, but the annotation set already provides the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the core action and immediately followed by the most important operational caveat. Every sentence contributes value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with an output schema and detailed annotations, the description covers purpose, the transfer-use case, and idempotency. Nothing necessary for correct selection or invocation is missing; the context is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'locked' parameter (true = LOCK, false = UNLOCK), so the tool description reinforces this with the transfer context. For the 'domain' parameter, schema coverage is absent, but the description implies it's the domain being locked without adding format details. Overall, the description adds meaning by connecting parameter values to real-world transfer behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Set the registrar lock on a domain', a specific verb and resource. It clearly distinguishes this tool from domain siblings (e.g., get_domain_info, transfer_domain) by focusing on the registrar lock and adding the dual unlock/transfer guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states that locking protects against unauthorised transfers and gives a concrete rule: 'you must UNLOCK before transferring a domain away.' This tells the agent when the tool is necessary. It does not explicitly name alternatives, but no sibling offers the same lock functionality, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses non-obvious routing behavior ('does NOT route by who holds the domain'), provider-specific limitations, and quota implications. This adds significant behavioral context that annotations alone do not convey, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but every sentence contributes unique information: main purpose, routing semantics, provider capabilities, and quota impact. It is front-loaded with the core purpose and avoids redundancy, though slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the multi-provider complexity, the description covers purpose, routing logic, provider limitations, batch behavior, and account-threshold nuances. Since an output schema exists, return-value details are appropriately omitted, making the description complete for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters well. The description adds contextual color about provider behavior (e.g., batch vs. single-request) but does not materially enhance the meaning of the domains or provider parameters beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Check whether one or more domains are available to register,' clearly distinguishing this from sibling tools like get_domain_pricing or list_domains. It also scopes the operation to availability, which is a distinct registry-level query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use guidance: it explains that availability is registry-level rather than account-level, states that Route 53 cannot answer, and contrasts Namecheap's batch capability with GoDaddy's per-request quota cost. This effectively routes the agent toward the correct provider choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint and non-readOnly, but the description goes far beyond: it explains the read-merge-write workflow, untouched-record preservation, the allowEmptyZone safety switch, and the GoDaddy non-atomic delete-then-create caveat (if create fails the record is ABSENT, not stale). This is critical, actionable behavior not derivable from annotations alone, and it contradicts nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but dense. It front-loads the most important rule ('WITHOUT wiping the zone'), then systematically covers operation grammar, safety, return value, and provider-specific behavior. Every sentence carries operational weight; there is no filler. Slight length is justified by complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested operations array, multiple providers, and mutation risk, the description covers all essential context: how operations are matched, the allowEmptyZone guard, the diff return, and the non-atomic provider caveat. The output schema exists, so not detailing return fields is fine. This is a fully self-sufficient description for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning beyond field descriptions: update matches name+type optionally matchAddress and only touches provided fields; delete similarly; address is required for add, optional for update; allowEmptyZone is a safety switch. This is exactly the semantic depth needed for correct operation construction.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Change DNS records WITHOUT wiping the zone', a specific verb-resource pair that instantly distinguishes it from replace_all_dns_records. The scope (granular add/update/delete vs. wholesale replacement) is explicit, making the tool's purpose unambiguous among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly positions itself as 'the tool you almost always want' and contrasts with the destructive alternative by saying 'WITHOUT wiping the zone'. It also gives concrete guidance for using the provider parameter (domain not existing yet, or domain at two providers). However, it doesn't name the alternative tool directly, only implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint and openWorldHint, and the description reinforces 'Read-only' while adding context about the 90-day auto-renewal window and the distinction between available and account balance. It does not disclose auth requirements, but the tool is simple and the annotations cover the safety profile, so this is more than adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences: the first front-loads the primary purpose with concrete data fields, the second gives a practical usage tip. There is no wasted wording or unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool with an output schema, the description fully covers what it does, when to use it, and its read-only nature. The output schema handles return-value details, so no further explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is trivially 100%. The description explains what the result contains (available balance, account balance, auto-renewal funds), which is relevant even though parameter semantics are not needed. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Namecheap account funds, listing specific components (available balance, account balance, 90-day auto-renewal fund requirement). It distinguishes itself from sibling tools that operate on domains or DNS records, making its unique purpose obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to check this tool before register/renew/transfer, linking to a common failure mode ('order creation failed'). This provides clear when-to-use guidance; no alternatives are needed since no sibling tool offers account balance data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds crucial behavioral context beyond the annotations: it warns that the operation spends money and can cost more than a normal renewal, and explicitly states confirm=true is required. This aligns with readOnlyHint=false and destructiveHint=true, with 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, then the critical cost warning and alternative. Every sentence adds essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid, potentially expensive operation, the description covers the eligibility window, cost implication, required confirmation, and provides a clear alternative. The output schema exists, so return values need not be described. This is comprehensive for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%). The description explains the confirm parameter's role (must be true) and implicitly that domain is the target, but provides no additional detail for domain format or promotionCode. It partially compensates for the low coverage but leaves promotionCode's purpose unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: reactivating expired domains within Namecheap's redemption/grace window. It uses a specific verb and resource, and explicitly distinguishes from renew_domain for non-expired domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool (expired domains within the redemption/grace window) and when to use an alternative ('For domains that have not yet expired, use renew_domain.'). This provides clear usage guidance with an exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, readOnly=false), the description adds critical behavioral context: it spends money and requires confirm=true. It also reinforces the non-expired prerequisite, which is essential for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences deliver purpose, prerequisites, a financial warning, and an alternative tool. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid mutation tool, the description covers the essential context: when to use, when not to use, the money-spending nature, and the confirmation requirement. Combined with the output schema and sibling context, this is fully sufficient for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (25%), so the description should compensate. It meaningfully explains the confirm parameter (must be true to place the paid renewal), and implies domain is the target. However, years and promotionCode are not explained beyond schema constraints, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renews an existing, non-expired domain to extend its expiry. It uses a specific verb and resource, and explicitly distinguishes from reactivate_domain, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides a conditional usage guideline: use this tool for non-expired domains, and directs users to reactivate_domain for expired domains. This directly addresses the key alternative and clarifies when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral context beyond the annotations: moving nameservers transfers DNS authority, so records at the old provider stop taking effect. This aligns with destructiveHint=true and openWorldHint=true, and the warning about consequences is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary purpose, followed by critical provider-specific and consequence information. Every sentence carries meaningful content without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers the essential caveats: provider-specific behavior, the consequence of changing DNS authority, and a Route 53 limitation. This is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (75%), and the description adds semantics for the 'mode' parameter by explaining that 'default' resets to Namecheap BasicDNS. This goes beyond the schema's generic description. The 'domain' parameter is self-evident and needs no extra explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Point a domain at nameservers,' clearly identifying the resource and action. It distinguishes from sibling tools like get_nameservers and modify_dns_records by focusing on the nameserver assignment operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context, including a critical exclusion (Route 53 cannot do this) and provider-specific behavior (mode=default resets to Namecheap BasicDNS). It does not explicitly compare to all alternatives, but the guidance is sufficient for making an informed choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true), the description discloses the financial impact ('THIS SPENDS MONEY'), the need for confirm=true, and the inclusion of a year of renewal. It also reveals the 60-day age and transfer restrictions, which are important behavioral constraints not captured in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action, then the financial warning, then prerequisites and tracking. Every sentence contributes essential information without redundancy. It leverages uppercase for the financial warning, making it hard to miss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, financial side effects, external prerequisites), the description covers the action, cost, confirm flag, EPP code requirement, domain age restrictions, and where to track progress. An output schema exists but is not shown; the description adequately prepares the 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the critical eppCode parameter (passed from the losing registrar) and its requirement for most gTLDs, adding value beyond the schema's one-line description. It also clarifies confirm required for the paid order, which the schema already lists but the description reinforces. With 67% schema coverage, the description compensates partially, though promotionCode and enablePrivacy remain implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Initiate an inbound domain transfer to Namecheap') and distinguishes it from sibling tools like register_domain, renew_domain, and get_transfer_status. The verb 'transfer' and resource 'domain' are specific, and the qualifier 'inbound' adds scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisites (unlock domain, obtain EPP code) and points to get_transfer_status for tracking progress. It doesn't explicitly name alternative tools, but the context makes clear when to use this tool. The warning about spending money and needing confirm=true is practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by explaining the safety mechanism: default is a safe merge that reads existing rules, upserts matching ones, removes listed mailboxes, and preserves untouched rules. It also discloses that replace_all is destructive and requires confirm=true. This adds critical behavioral detail beyond the destructiveness/idempotence hints and is fully consistent 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, then packing the behavioral details efficiently. Each sentence earns its place: the first establishes purpose and the safe merge default; the second explains the destructive alternative. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the presence of an output schema, and annotations, the description is complete. It covers the default safe behavior, the destructive mode, the confirm requirement, and how existing rules are preserved. The only missing nuance is error handling, but that is not expected at this level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description meaningfully explains how the parameters interact: `forwards` are upserted by mailbox, `remove` deletes specific mailboxes, `mode` toggles merge vs. replace_all, and `confirm` is a safety gate. This orchestration is not evident from the individual schema descriptions, significantly enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource: 'Configure email forwarding.' It then explains the merge vs. replace_all behavior, which distinguishes this mutation tool from the read-only sibling `get_email_forwarding`. The reference to 'DNS setHosts' adds context about replace-all semantics without obscuring the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this tool is for modifying email forwarding rules and provides context on when to use merge vs. replace_all. However, it does not explicitly mention alternatives like `get_email_forwarding` for reading or state when not to use the destructive replace_all mode. The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant context beyond the annotations (destructiveHint=true, readOnlyHint=false) by disclosing that the action 'SPENDS MONEY from the Namecheap account balance and is not reversible,' describes the dry-run behavior, and explains that the registrant contact applies to all roles unless overridden. It also warns about ccTLD extended attributes, all of which are critical operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized for a complex, high-risk operation. Each sentence earns its place: the money warning is front-loaded, the confirm flag behavior is critical, contact roles and ccTLD extras are necessary, and the pointer to related tools prevents misuse. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, nested objects, paid irreversible action), the description covers all essential aspects: prerequisites, the confirm gate, contact requirements, special ccTLD handling, and links to sibling tools for availability/balance checks. The output schema exists, so return values need no description. It is fully adequate for an agent to safely invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 89%, so the baseline is 3, but the description adds crucial meaning for key parameters: confirm (controls dry-run vs actual charge), contact (applied to all roles unless overridden), and extendedAttributes (raw Namecheap field names). It does not explain nameservers or enablePrivacy, but those are adequately covered by the schema and simpler in nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Register (buy) a new domain,' a specific verb and resource that immediately distinguishes it from siblings like renew_domain and transfer_domain. It clearly states the action is purchasing, which is unique among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance by instructing to 'Check availability/pricing first with check_domain_availability and confirm funds with get_account_balance,' naming the appropriate alternatives for pre-checks. It also specifies that confirm=true is required to actually place the order, otherwise it returns a dry-run, setting expectations for operational use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses permanent deletion of omitted records including MX, requires confirm=true and allowEmptyZone=true for empty zones, and explains Route 53's SOA/apex NS behavior. This adds rich behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight paragraphs with a front-loaded 'DANGER' warning. Every sentence contributes critical safety, usage, or provider-specific information with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, destructive semantics, prerequisites, rollback advice, alternatives, and provider-specific exception. With an output schema present, return values need not be explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (80%), so baseline is 3. The description adds value by clarifying the records array is the complete desired set ('Anything omitted is deleted') and explicitly tying confirm/allowEmptyZone to the destructive behavior, plus the provider parameter for force-routing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'replace' with resource 'entire DNS zone', explicitly stating every record not in the list is permanently deleted. It clearly distinguishes from sibling modify_dns_records by naming it as the alternative for everyday edits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs users to prefer modify_dns_records for everyday edits, and recommends calling get_dns_records first for rollback. This provides clear when-to-use vs. alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![namecheap-mcp MCP server](https://glama.ai/mcp/servers/fledgeling-co/namecheap-mcp/badges/card.svg)](https://glama.ai/mcp/servers/fledgeling-co/namecheap-mcp)

Score Badge

Copy to your README.md:

[![namecheap-mcp MCP server](https://glama.ai/mcp/servers/fledgeling-co/namecheap-mcp/badges/score.svg)](https://glama.ai/mcp/servers/fledgeling-co/namecheap-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/fledgeling-co/namecheap-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server