Domain availability search, WHOIS lookup, TLD pricing and registry rules from name.ai. Read-only.
Scored across 4 tools
Each tool targets a distinct concern: availability/alternates, TLD pricing, TLD policy requirements, and WHOIS details. There is no overlap or ambiguous boundary between them.
All names are snake_case and descriptive, but conventions are mixed: search_domain is verb_noun, whois_lookup is noun_verb, and the two tld_* tools are noun phrases. The tld_ prefix provides cohesion, making the set predictable despite the lack of a single uniform pattern.
Four tools is well-scoped for a domain-information server. Each tool contributes a necessary capability without redundancy or bloat.
The surface covers the core domain-research lifecycle: availability, pricing, registry requirements, and existing registration details. A minor gap is the lack of any purchase/registration action, but the server appears intentionally informational rather than transactional.
Check whether a domain is available and, for the same label, whether its common alternate TLDs are too (e.g. querying "acme.com" also returns "acme.ai", "acme.io", ...).
Backed by POST /api/domain/search — public, no auth required.
Buy-now (aftermarket/marketplace) prices are hidden unless you're
authenticated (see AUTH.md at name.ai for how to get a token) — an
unauthenticated call only sees new-registration pricing for a domain
that's simply unregistered. Pass a valid OAuth access token as this
call's Authorization header and it's forwarded automatically.
Args:
domain: A domain name to check, e.g. "example.ai".
include_alternates: When true (default), also return sibling TLDs for
the same label. When false, only the exact domain is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| include_alternates | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read/idempotent annotations, the description discloses the underlying endpoint, the public/authenticated behavior, price visibility differences, and automatic OAuth header forwarding. This gives the agent actionable behavioral knowledge annotations alone cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then endpoint/auth context, then a clearly labeled Args section. Each sentence adds distinct information and no filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two simple parameters and no output schema, the description covers invocation endpoint, auth requirements, parameter semantics, and an edge-case about aftermarket prices. An agent has enough context to call and interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining domain format with an example and include_alternates' default true behavior and its effect. Every parameter gets additional meaning beyond the raw 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 opens with a specific verb+resource: 'Check whether a domain is available' and adds alternate-TLD behavior with a concrete example. This clearly differentiates it from sibling tools like whois_lookup or tld_registration_price, even though those are not named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear contextual signals: the call is public, requires no auth, and is intended for availability checks. It does not explicitly state when to prefer it over sibling tools or when not to use it, so it misses the explicit-alternatives bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current USD price for a domain-lifecycle operation on a TLD (new registration, transfer-in, renewal, or restore from redemption).
Backed by GET /api/pricing/tld — public, no auth required. This is
name.ai's own registration pricing, not an aftermarket/marketplace price,
so it is never gated by sign-in status.
Args:
tld: The TLD without a leading dot, e.g. "ai" or "com".
operation: One of "register", "transfer", "renew", "restore".
| Name | Required | Description | Default |
|---|---|---|---|
| tld | Yes | ||
| operation | No | register |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive. The description adds genuinely new behavioral context beyond those annotations: the underlying endpoint (GET /api/pricing/tld), that it is public with no auth required, and that access is never gated by sign-in status. This is exactly the kind of auth/access context the rubric credits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose in the first sentence, then endpoint/auth, then the marketplace disambiguation, then an Args section. Every sentence earns its place; no filler or redundancy. The two-sentence auth and sign-in distinction could seem overlapping but the second half carries the marketplace-clearing context.
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 low-complexity read tool (2 params, 1 required, 1 enum) with rich annotations covering safety, the description covers purpose, auth, endpoint, and parameter formats thoroughly. The only notable gap is the return format (e.g., a numeric USD amount), but that is readily inferable from the tool's name and purpose.
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 carries the burden — and it compensates well. For tld it adds format guidance ('without a leading dot') plus concrete examples ('ai', 'com'). For operation it expands the bare enum values with semantic meaning ('transfer-in', 'restore from redemption'), going beyond the schema's labels.
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?
Opens with a specific verb+resource+scope: 'Get the current USD price for a domain-lifecycle operation on a TLD', then enumerates the four operations (registration, transfer-in, renewal, restore). It further disambiguates from marketplace/aftermarket pricing, making its purpose unmistakable and distinct from siblings like search_domain and whois_lookup.
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 useful context by stating the endpoint is public, no auth required, and that pricing is name.ai's own registration pricing rather than aftermarket, so it is never gated by sign-in status. However, it does not explicitly name sibling alternatives or state when not to use this tool, leaving exclusions implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get registration requirements for a TLD: allowed registration period range, whether an organization is required, allowed registrant countries, nameserver rules, and similar registry policy.
Backed by GET /api/tlds/{tld}/metadata — public, no auth required.
Args:
tld: The TLD without a leading dot, e.g. "ai" or "io".
| Name | Required | Description | Default |
|---|---|---|---|
| tld | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, and the description does not contradict them. It adds valuable behavioral context beyond annotations by revealing the backing GET endpoint and explicitly stating the call is public and requires no authentication, which helps an agent anticipate authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tight and well-structured: a front-loaded summary of the tool's purpose, a one-line endpoint/auth note, and a clearly formatted Args section. Every sentence earns its place, and there is no redundant restatement of the tool name or schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with rich annotations and no output schema, the description is complete: it defines the parameter format, identifies the backing endpoint, clarifies authentication, and summarizes the kind of registry policy data returned. Nothing essential for a correct call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the weight, and it does: it explains the tld parameter should be given without a leading dot and provides concrete examples 'ai' or 'io'. This is meaningful format guidance that the raw input schema does not offer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get registration requirements for a TLD,' and then enumerates concrete policy dimensions such as registration period range, organization requirement, allowed countries, nameserver rules, and similar policy. This makes it clearly distinct from siblings like whois_lookup, tld_registration_price, and search_domain without needing to open their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description: query this tool when you need TLD registration policy details. It also provides useful context by noting the endpoint and that no auth is required, but it never explicitly states when to prefer this over sibling tools or when it would be inappropriate to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up WHOIS/RDAP registration details for a domain: registrar, registrant, creation/expiration dates, nameservers.
Backed by POST /api/tools/whois — public, no auth required, but rate
limited by name.ai to 10 lookups per day per caller IP. Since every MCP
call shares this server's egress IP, that quota is pooled across all of
this MCP server's callers, not per end user.
Args:
domain: A domain name to look up, e.g. "example.com".
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, openWorld), the description reveals critical behavior: the rate limit and the fact that the shared egress IP pools the quota across all MCP callers. It also notes the backend HTTP method and public access, which are not captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized: purpose first, then backend/rate-limit context, then the parameter definition. Every sentence carries useful information with no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup with one parameter, the description covers the main need: what data is returned and the important rate-limit behavior. It doesn't describe error cases or exact return formatting, but the absence of an output schema is partially mitigated by listing the returned fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description's Args section fully compensates by defining 'domain' as 'a domain name to look up' and providing the example 'example.com'. This tells the agent exactly what input format is expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and object: 'Look up WHOIS/RDAP registration details for a domain' and enumerates the specific data returned (registrar, registrant, dates, nameservers). This distinguishes it from siblings like tld_registration_price and tld_requirements, which have different purposes.
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 states that the endpoint is public, requires no auth, and is rate-limited to 10 lookups per caller IP per day, with the pooled-quota caveat. This gives clear operational context, though it never explicitly names alternatives or says when not to use this tool versus a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
search_domaintld_registration_pricetld_requirementswhois_lookupCheck domain name availability via RDAP. Single, bulk, and smart suggestions. No API key needed.
Domain search, registration, DNS, marketplace, and checkout with your AI agent.
Domain intelligence for DNS, WHOIS/RDAP, TLS, reputation, valuation, and brand protection.
Watch domains and forecast when they drop; check a name's domain, handles, and trademark.
Add one secure layer between your agents and this server.
