The Domain MCP server enables AI assistants to manage Dynadot domains through natural language commands, eliminating the need for API knowledge or manual web interface navigation. It provides 10 tools covering 106 API actions across comprehensive domain management capabilities:
Domain Operations: List, search, register (single/bulk), renew, delete, restore, lock/unlock domains, check availability and TLD pricing, and push domains between Dynadot accounts
Domain Settings: Configure nameservers, WHOIS privacy levels, auto-renewal, URL forwarding (standard/stealth), parking pages, email forwarding, folder organization, and domain notes
DNS Management: Get/set DNS records (A, AAAA, CNAME, MX, TXT) for main domains and subdomains with TTL and priority settings, plus full DNSSEC configuration
Nameserver Management: Register custom nameservers (glue records), update IP addresses, list, and delete nameservers
Domain Transfers: Initiate/cancel transfers, check status, manage authorization codes, authorize outbound transfers, and handle push requests between accounts
Contact Management: Create, edit, delete, and list WHOIS contacts with support for regional settings (.CN audits, EU, Latvia, Lithuania)
Folder Management: Organize domains into folders with bulk settings for WHOIS, DNS, nameservers, forwarding, parking, and renewal options
Account Management: View account balance and details, configure default settings for new domain registrations (WHOIS, nameservers, DNS, forwarding, renewal options)
Aftermarket Operations: Manage backorders, list/bid on auctions, buy expired domains, manage marketplace listings, and confirm Afternic/Sedo transactions
Order Management: View order history, check order/processing status, list available coupons, and manage reseller WHOIS verification
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Domain MCP check if example.com is available and show me similar domains"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Manage Dynadot domains, DNS, renewals, transfers, and WHOIS from Claude, Cursor, or any MCP client.
Skip the registrar dashboard and brittle one-off scripts. domain-mcp groups 108 Dynadot API actions into 10 MCP tools you can call from an AI client.
Quick Start · How It Works · Features · Packages · Contributing
Registrar APIs cover dozens of jobs, but each command has its own parameters, response shape, and edge cases. Working with the API directly takes time and leaves plenty of room for mistakes.
domain-mcp gives your AI client a smaller, typed toolset. Ask it to check availability, update DNS, review renewals, or manage a portfolio without memorizing Dynadot's API.
Without domain-mcp | With domain-mcp |
Search API docs for every task | Describe the outcome in plain language |
Build and maintain registrar scripts | Use the same MCP tools from supported clients |
Handle inconsistent response envelopes | Get results in a consistent format |
Expose every API command as a separate tool | Keep context small with 10 composite tools |
Related MCP server: Name.com MCP Server
You need Node.js 18 or newer and a Dynadot API key.
Add the server to your MCP client:
{
"mcpServers": {
"domain-mcp": {
"command": "npx",
"args": ["-y", "domain-mcp"],
"env": {
"DYNADOT_API_KEY": "your-api-key"
}
}
}
}Restart the client, then try:
List my domains that expire in the next 60 days.
For client-specific setup, shared HTTP transport, environment options, and troubleshooting, read the domain-mcp package guide.
You describe a domain task
│
▼
Claude, Cursor, or another MCP client
│ selects a tool and operation
▼
domain-mcp validates and transforms the request
│ calls the Dynadot API
▼
The result returns to your AI clientThe server groups related operations into composite tools, so clients load a small set of tools instead of more than 100 separate definitions.
Area | What you can do |
Domains | Search, register, renew, delete, lock, push, and inspect domains |
DNS | Read and update DNS records, forwarding, parking, and email settings |
Nameservers | Create, edit, list, and assign nameservers |
Transfers | Start transfers, check status, and manage authorization steps |
Contacts | Create and maintain WHOIS contact records |
Portfolio | Work with folders, account data, bulk settings, and renewals |
Aftermarket | List domains, manage auctions, bids, and marketplace operations |
Agent workflows | Generate domain ideas, run portfolio audits, and diagnose DNS issues |
The server groups Dynadot operations into 10 composite tools, with additional tools for domain checks, name generation, and tool discovery. Zod validates inputs. Responses follow a consistent format, and errors explain what went wrong.
This repository is a pnpm workspace with two related packages:
Package | Best for | Distribution |
Claude, Cursor, Claude Desktop, Zed, and other MCP clients | ||
Agent Plugins v1 hosts, including Hermes and Claude Code | Portable plugin with optional Claude safety adapter |
packages/
├── domain-mcp/ # TypeScript MCP server published to npm
└── domain-agent-kit/ # Portable Agent Plugin built on domain-mcpOnce connected, you can ask your client to:
“Check whether example.com is available and show similar names.”
“Add an A record for example.com and point it to 203.0.113.10.”
“Find domains expiring this quarter and group them by urgency.”
“Enable auto-renew for every unlocked .com domain.”
“Show the current nameservers and WHOIS contacts for example.com.”
Your client should still ask before destructive or paid operations. The portable plugin defines that approval and read-back contract, and its optional Claude Code adapter adds a native confirmation hook for selected irreversible actions.
git clone https://github.com/joachimBrindeau/domain-mcp.git
cd domain-mcp
pnpm install
pnpm test
pnpm buildUseful workspace commands:
Command | Purpose |
| Run the domain-mcp test suite |
| Check TypeScript without emitting files |
| Run Biome across the repository |
| Build the npm package |
See CLAUDE.md for the workspace map and packages/domain-mcp/CLAUDE.md for server architecture and conventions.
Bug reports, API findings, documentation fixes, and focused pull requests are welcome. Read CONTRIBUTING.md before opening a change.
MIT. See LICENSE.
Built by Joachim Brindeau
If domain-mcp saves you time:
Account info, balance, and default settings for new domains. Manage API keys: https://www.dynadot.com/account/domain/setting/api.html?s9F6L9F7U8Q9U8Z8v
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: info: Get account information | balance: Get account balance | set_default_whois: Set default WHOIS contact | set_default_ns: Set default nameservers | set_default_parking: Set default parking | set_default_forwarding: Set default forwarding | set_default_stealth: Set default stealth forwarding | set_default_hosting: Set default hosting | set_default_dns: Set default DNS | set_default_dns2: Set default DNS2 | set_default_email_forward: Set default email forwarding | set_default_renew_option: Set default renewal option | clear_defaults: Clear all default settings | |
| currency | No | Currency code (default: USD) | USD |
| contactId | No | Contact ID | |
| nameservers | No | List of nameservers | |
| forwardUrl | No | URL | |
| stealthUrl | No | URL | |
| options | No | ||
| mainRecords | No | ||
| subdomainRecords | No | ||
| No | Email address | ||
| renewOption | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It hints at actions like 'manage API keys' but fails to specify whether operations are read-only or mutative (e.g., setting defaults implies writes), what permissions are needed, or any side effects. This leaves critical behavioral traits unclear for a tool with potential write operations.
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 brief but includes an irrelevant URL that doesn't aid tool invocation, reducing efficiency. It front-loads key terms like 'Account info, balance, and default settings,' but the sentence structure is cluttered with the URL, making it less concise than ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, nested objects, no output schema, and no annotations), the description is inadequate. It doesn't explain the tool's behavior, return values, or how to handle the various actions, leaving significant gaps for an agent to understand and use the tool effectively in context.
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 description does not detail any parameters, leaving all semantics to the input schema. With a schema description coverage of 64%, the schema partially documents parameters, but the description adds no additional meaning or context. This meets the baseline of 3, as the schema handles most documentation, but the description doesn't compensate for the 36% coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool handles 'Account info, balance, and default settings for new domains' and mentions API key management, which provides a general purpose. However, it's vague about the specific operations (e.g., reading vs. setting defaults) and doesn't clearly distinguish from siblings like 'dynadot_account' vs. 'dynadot_domain_settings' or 'dynadot_contact', leaving ambiguity in scope.
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?
No explicit guidance on when to use this tool versus alternatives is provided. The description mentions managing API keys with a URL, but it doesn't clarify if this tool is for viewing account details, setting defaults, or both, nor does it reference sibling tools for related tasks like domain-specific settings or contact management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aftermarket: auctions, backorders, expired domains, marketplace listings. Browse domains: https://www.dynadot.com/?s9F6L9F7U8Q9U8Z8v
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: backorder_add: Add domain to backorder list | backorder_delete: Remove from backorder list | backorder_list: List backorder requests | auction_list_open: List open auctions | auction_details: Get auction details | auction_bids: Get auction bids | auction_bid: Place auction bid | auction_list_closed: List closed auctions | backorder_auction_list_open: List open backorder auctions | backorder_auction_details: Get backorder auction details | backorder_auction_bid: Place backorder auction bid | backorder_auction_list_closed: List closed backorder auctions | expired_list: List expired closeout domains | expired_buy: Buy expired closeout domain | listings: Get marketplace listings | listing_details: Get listing details | buy_now: Buy domain from marketplace | set_for_sale: List domain for sale | afternic_confirm: Confirm/decline Afternic action | sedo_confirm: Confirm/decline Sedo action | |
| domain | No | Domain name (e.g., example.com) | |
| currency | No | Currency code (default: USD) | USD |
| auctionId | No | Auction ID | |
| bidAmount | No | Amount | |
| price | No | Amount |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose critical behavioral traits: whether actions are read-only or mutative (e.g., 'bid' or 'buy' imply writes), authentication requirements, rate limits, or error handling. The URL reference is irrelevant to tool behavior and adds no operational context.
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 poorly structured: it starts with a vague list, then includes an irrelevant URL that doesn't belong in a tool description. It's not front-loaded with useful information, and the URL sentence wastes space without adding value for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, 20 action types, no output schema, and no annotations), the description is inadequate. It doesn't explain the tool's scope, return values, or how actions differ (e.g., mutative vs. read-only). Without annotations or output schema, more context is needed for effective use.
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%, providing detailed parameter documentation, especially for the 'action' enum. The description adds no meaningful parameter semantics beyond what's in the schema—it doesn't clarify relationships between parameters (e.g., which actions require 'domain' or 'bidAmount') or usage nuances. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Aftermarket: auctions, backorders, expired domains, marketplace listings' which lists categories but lacks a specific verb or clear action. It doesn't distinguish this tool from siblings like dynadot_domain or dynadot_order, which might also handle domain-related operations. The URL reference adds confusion rather than clarifying 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?
No guidance on when to use this tool versus alternatives is provided. The description mentions categories but doesn't explain when to choose this over sibling tools (e.g., dynadot_domain for regular domain operations vs. this for aftermarket activities). The URL suggests manual browsing, which contradicts automated tool usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHOIS contact management: create, edit, delete, list, regional settings
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: list: List all contacts | get: Get contact details | create: Create new contact | edit: Update contact | delete: Delete contact | create_cn_audit: Create .CN domain audit | get_cn_audit_status: Get .CN audit status | set_eu_setting: Set EU contact settings | set_lv_setting: Set Latvia contact settings | set_lt_setting: Set Lithuania contact settings | |
| contactId | No | Contact ID | |
| name | No | Contact name | |
| No | |||
| phoneCc | No | Phone country code (e.g., "1" for US, "33" for France) | |
| phoneNum | No | Phone number without country code (e.g., "5551234567") | |
| address1 | No | Address line 1 | |
| city | No | City | |
| state | No | State/Province | |
| zipCode | No | Postal code | |
| country | No | Country code (2-letter) | |
| organization | No | Organization | |
| address2 | No | Address line 2 | |
| auditDetails | No | Audit details | |
| settings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions operations like 'create, edit, delete' which imply mutations, but doesn't disclose behavioral traits such as permissions required, whether deletions are permanent, rate limits, or what happens with regional settings. The description is too brief to provide meaningful context beyond the basic actions.
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 very concise—a single phrase listing key actions. It's front-loaded with the core purpose. However, it could be more structured (e.g., separating operations from regional aspects) and some terms like 'regional settings' are vague, slightly reducing efficiency.
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 high complexity (15 parameters, nested objects, no output schema, no annotations), the description is incomplete. It doesn't explain return values, error conditions, or how actions differ. For a multi-action tool with significant parameter variety, more context is needed to guide effective use.
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 93% (high), so the baseline is 3. The description adds minimal value beyond the schema—it hints at 'regional settings' which loosely relates to actions like 'set_eu_setting', but doesn't explain parameter usage or dependencies. With 15 parameters, the description doesn't compensate for the 7% coverage gap or clarify how parameters map to different actions.
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 'WHOIS contact management: create, edit, delete, list, regional settings' which specifies the domain (WHOIS contacts), the operations (create, edit, delete, list), and mentions regional settings. It distinguishes from siblings by focusing on contact management rather than domains, DNS, accounts, etc. However, it doesn't explicitly differentiate from all siblings (e.g., 'dynadot_account' might also involve contact info).
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when to choose specific actions (e.g., 'create' vs 'edit'), or how it relates to sibling tools like 'dynadot_domain' or 'dynadot_account'. Usage is implied through the action list but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DNS management: get/set DNS records, DNSSEC configuration
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: get: Get current DNS records | set: Set DNS records | set_dnssec: Enable DNSSEC | get_dnssec: Get DNSSEC settings | clear_dnssec: Remove DNSSEC | |
| domain | No | Domain name (e.g., example.com) | |
| mainRecords | No | Main domain records | |
| subdomainRecords | No | Subdomain records | |
| keyTag | No | Key tag | |
| algorithm | No | Algorithm | |
| digestType | No | Digest type | |
| digest | No | DS record digest |
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 mentions 'get/set DNS records, DNSSEC configuration' which implies both read and write operations, but doesn't specify permissions required, whether changes are immediate or propagate, rate limits, or error conditions. For a tool with multiple mutation actions (set, set_dnssec, clear_dnssec), this is inadequate behavioral context.
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 extremely concise at just 7 words: 'DNS management: get/set DNS records, DNSSEC configuration.' Every word earns its place by establishing scope (DNS), operations (get/set/configuration), and resources (records/DNSSEC). It's front-loaded with the most important information and wastes no space.
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 tool with 8 parameters, multiple actions including mutations, no annotations, and no output schema, the description is insufficient. It doesn't explain return formats, error handling, authentication requirements, or operational constraints. The agent must rely entirely on the input schema without guidance on how to interpret results or handle failures.
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 8 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does all the work, though the description could have explained which parameters are required for which actions or provided examples.
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 'DNS management: get/set DNS records, DNSSEC configuration' which specifies the verb (manage) and resource (DNS records/DNSSEC). It distinguishes from siblings like dynadot_account or dynadot_domain by focusing specifically on DNS operations. However, it doesn't explicitly mention it's for Dynadot domains specifically, which could help differentiate from generic DNS tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when to choose DNS management over domain settings, or any context about which sibling tools might be more appropriate for related tasks. The agent must infer usage from the action parameter descriptions alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Core domain operations: list, search, register, renew, delete, info, lock, pricing. Search domains: https://www.dynadot.com/domain/search.html?s9F6L9F7U8Q9U8Z8v
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: list: List all domains in your account | info: Get detailed info about a domain | search: Check domain availability (with optional pricing). Search manually: https://www.dynadot.com/domain/search.html?s9F6L9F7U8Q9U8Z8v | register: Register a new domain. View pricing: https://www.dynadot.com/domain/pricing?s9F6L9F7U8Q9U8Z8v | bulk_register: Register multiple domains at once. View pricing: https://www.dynadot.com/domain/pricing?s9F6L9F7U8Q9U8Z8v | renew: Renew a domain or check renewal price | delete: Delete a domain | restore: Restore a deleted/expired domain | lock: Lock or unlock a domain | tld_price: Get TLD pricing | push: Push domain to another Dynadot account | |
| domain | No | Domain name (e.g., example.com) | |
| domains | No | List of domain names | |
| showPrice | No | Include pricing | |
| currency | No | Currency code (default: USD) | USD |
| duration | No | Duration in years (1-10) | |
| priceCheck | No | Only check price | |
| lock | No | Lock action | |
| tld | No | TLD (e.g., com, net) | |
| username | No | Target username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It lists operations but doesn't disclose critical traits like authentication needs, rate limits, destructive effects (e.g., delete, restore), or response formats. The URL reference adds some context but is insufficient for a tool with 10 parameters and no output schema.
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 brief but front-loaded with a list of operations, which is efficient. However, the second sentence with the URL feels tacked on and doesn't integrate well, slightly reducing clarity. It's not overly verbose but could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, multiple actions including destructive ones like delete, no annotations, no output schema), the description is incomplete. It fails to address key aspects like authentication requirements, error handling, or what results to expect, leaving significant gaps for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond the schema's detailed parameter descriptions and enum values, meeting the baseline of 3 for high coverage without extra value.
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 lists operations (list, search, register, etc.) which gives a general sense of purpose, but it's vague about what 'core domain operations' means and doesn't specify the resource clearly beyond 'domains'. It doesn't differentiate from sibling tools like dynadot_domain_settings or dynadot_transfer, which likely handle related domain functions.
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?
No explicit guidance on when to use this tool versus alternatives is provided. The description mentions a search URL but doesn't explain when to use 'search' action here versus other tools or manual methods. There's no mention of prerequisites, context, or exclusions for different actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure domain settings: nameservers, privacy, renewal, forwarding, parking, WHOIS
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: set_ns: Set nameservers | get_ns: Get current nameservers | set_renew_option: Set auto-renewal option | set_privacy: Set WHOIS privacy | set_whois: Set WHOIS contact | set_forwarding: Set URL forwarding | set_stealth: Set stealth/masked forwarding | set_parking: Enable parking page | set_hosting: Set hosting settings | set_email_forward: Set email forwarding | set_folder: Move domain to folder | set_note: Set domain note | clear_settings: Clear all custom settings | |
| domain | No | Domain name (e.g., example.com) | |
| nameservers | No | List of nameservers | |
| renewOption | No | Renewal option | |
| domains | No | List of domain names | |
| option | No | Privacy level | |
| registrantContact | No | Contact ID | |
| adminContact | No | Contact ID | |
| techContact | No | Contact ID | |
| billingContact | No | Contact ID | |
| forwardUrl | No | URL | |
| forwardType | No | ||
| stealthUrl | No | URL | |
| stealthTitle | No | Page title | |
| options | No | Hosting options | |
| forwardTo | No | Email address | |
| username | No | Email username (default: *) | |
| folderId | No | Folder ID | |
| note | No | Note text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Configure' implies mutation operations, the description doesn't specify whether this requires authentication, what permissions are needed, whether changes are reversible, or any rate limits. For a complex configuration tool with 19 parameters, this represents a significant transparency gap.
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 extremely concise - a single sentence that efficiently lists all major configuration areas. Every word earns its place, and the structure is front-loaded with the core purpose followed by specific examples.
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 configuration tool with 19 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after configuration, what values are returned, error conditions, or how different actions interact. The agent would struggle to use this tool effectively without significant trial and error.
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 95% schema description coverage, the input schema already documents most parameters thoroughly. The description adds minimal value by listing configuration areas that map to some parameters, but doesn't provide additional context beyond what's in the schema. The baseline score of 3 reflects adequate but unremarkable parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Configure domain settings' and lists specific configuration areas (nameservers, privacy, renewal, etc.), which provides a comprehensive overview. However, it doesn't explicitly differentiate this tool from sibling tools like 'dynadot_dns' or 'dynadot_nameserver' that might handle related functionality.
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 no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, dependencies, or how this tool relates to the nine sibling tools listed, leaving the agent with no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Folder management: create, delete, list, configure folder-level settings
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: list: List all folders | create: Create new folder | delete: Delete folder | rename: Rename folder | set_whois: Set WHOIS for all domains in folder | set_ns: Set nameservers for folder | set_parking: Enable parking for folder | set_forwarding: Set forwarding for folder | set_stealth: Set stealth forwarding for folder | set_hosting: Set hosting for folder | set_dns: Set DNS for folder | set_dns2: Set DNS2 for folder | set_email_forward: Set email forwarding for folder | set_renew_option: Set renewal option for folder | clear_settings: Clear all folder settings | |
| folderName | No | Name | |
| folderId | No | Folder ID | |
| contactId | No | Contact ID | |
| nameservers | No | List of nameservers | |
| forwardUrl | No | URL | |
| stealthUrl | No | URL | |
| options | No | ||
| mainRecords | No | ||
| subdomainRecords | No | ||
| No | Email address | ||
| renewOption | No | Renewal option |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It lists actions like 'create' and 'delete' but fails to explain critical details such as permissions required, whether deletions are irreversible, rate limits, or what happens to domains within folders during operations. This is inadequate for a multi-action tool with potential mutations.
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 a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words, though it could be slightly more structured by separating actions for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, multiple actions including mutations), lack of annotations, and no output schema, the description is insufficient. It doesn't address behavioral risks, return values, or error handling, leaving significant gaps for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 75%, so the schema already documents most parameters well. The description adds minimal value by mentioning 'folder-level settings,' which hints at parameters like set_whois or set_dns, but doesn't clarify semantics beyond the schema. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Folder management: create, delete, list, configure folder-level settings,' which is a specific verb+resource combination. It distinguishes itself from siblings like dynadot_domain or dynadot_dns by focusing on folders, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as dynadot_domain_settings for domain-level configurations or dynadot_dns for DNS management. It lacks context about prerequisites or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage registered nameservers (glue records): register, update IP, delete, list
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: list: List all registered nameservers | register: Register a custom nameserver | add: Add a nameserver | set_ip: Update nameserver IP | delete: Delete a nameserver | delete_by_domain: Delete all nameservers for a domain | |
| host | No | Nameserver hostname | |
| ip | No | IP address | |
| domain | No | Domain name (e.g., example.com) |
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 mentions actions but doesn't describe what 'manage' entails operationally: whether changes are immediate or require propagation, authentication requirements, rate limits, error conditions, or what happens when deleting nameservers. For a tool with multiple mutation actions, this is insufficient behavioral context.
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 extremely concise and front-loaded in a single sentence that efficiently communicates the core functionality. Every word earns its place with no wasted text, making it easy to parse while covering the essential scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, multiple mutation actions, no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error handling, or the operational impact of actions like 'delete_by_domain'. The combination of mutation capabilities and lack of structured metadata requires more comprehensive description.
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%, providing detailed descriptions for all parameters including the enum values for 'action'. The description adds minimal value beyond the schema by listing the same actions. It doesn't explain parameter dependencies (e.g., which parameters are needed for which actions) or provide additional context about nameserver management semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as managing registered nameservers (glue records) with specific actions (register, update IP, delete, list). It distinguishes from siblings by focusing on nameserver management rather than account, DNS, domain, or other functions. However, it doesn't explicitly differentiate from potential overlapping tools like DNS management.
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 no guidance on when to use this tool versus alternatives. It lists actions but doesn't indicate prerequisites, when certain actions are appropriate, or how this tool relates to sibling tools like dynadot_dns or dynadot_domain_settings for nameserver-related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Orders, coupons, processing status, reseller operations
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: list: List recent orders | status: Get order status | is_processing: Check if operations pending | coupons: List available coupons | reseller_verification: Set reseller WHOIS verification status | |
| orderId | No | Order ID | |
| contactId | No | Contact ID | |
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, the description only lists nouns without explaining any behavioral traits such as whether operations are read-only or mutative, what permissions are needed, or how results are returned. This is inadequate for a tool with multiple action types.
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 a comma-separated list of four nouns without sentence structure or front-loading of key information. It is under-specified rather than concise, failing to communicate purpose or usage efficiently. Each 'sentence' (though not properly formed) does not earn its place by adding 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?
Given the tool's complexity with 4 parameters, multiple action types, no annotations, and no output schema, the description is completely inadequate. It does not explain return values, error conditions, or operational context, leaving significant gaps for the agent to understand how to use the tool effectively.
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 75%, providing a baseline. The description adds no meaningful parameter semantics beyond what the schema already states in the action enum descriptions. It does not clarify how parameters interact or provide context for their use, so it meets the minimum viable level without compensating for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Orders, coupons, processing status, reseller operations' is a vague list of nouns rather than a clear statement of what the tool does. It restates concepts from the action enum without specifying the verb or how it operates, making it tautological and lacking a specific purpose. It fails to distinguish this tool from its siblings like dynadot_account or dynadot_domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, and offers no comparison to sibling tools. This leaves the agent with no information to make an informed choice among the available tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Domain transfers: initiate, check status, manage auth codes, push requests
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform: initiate: Initiate domain transfer | status: Check transfer status | cancel: Cancel pending transfer | get_auth_code: Get transfer auth code | set_auth_code: Set custom auth code | authorize_away: Authorize transfer to another registrar | get_push_request: Get pending push request | set_push_request: Accept or decline push request | |
| domain | No | Domain name (e.g., example.com) | |
| authCode | No | Authorization code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions actions like 'initiate' and 'cancel' which imply mutations, but doesn't specify permissions needed, whether changes are reversible, rate limits, or what the response looks like. The description is too brief to adequately cover behavioral traits for a tool with multiple potential write operations.
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 extremely concise - a single phrase listing key actions. It's front-loaded with the core purpose and wastes no words. Every element in the description serves a purpose in conveying the tool's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema that handles potentially destructive operations like transfers and cancellations, the description is insufficient. It doesn't explain return values, error conditions, or the implications of different actions. The brevity comes at the cost of completeness for a complex domain transfer tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it just lists action types without explaining parameter interactions or dependencies. Baseline 3 is appropriate 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 tool's purpose as handling 'domain transfers' with specific actions listed (initiate, check status, manage auth codes, push requests), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like dynadot_domain or dynadot_domain_settings, which might also involve domain operations.
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 no guidance on when to use this tool versus alternatives. It lists actions but doesn't specify prerequisites, when to choose this over other domain-related tools, or any exclusions. Usage is implied through the action list but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every tool has a clearly distinct purpose with no ambiguity; each targets a specific aspect of domain management (e.g., account, DNS, orders, transfers) with no overlap in functionality. The descriptions clearly delineate boundaries, making it easy for an agent to select the correct tool for any given task.
All tool names follow a consistent 'dynadot_' prefix with a descriptive noun suffix (e.g., dynadot_account, dynadot_dns), creating a predictable and readable pattern throughout. There are no deviations in naming conventions, ensuring clarity and ease of use.
With 10 tools, the server is well-scoped for domain management, covering essential areas like domains, DNS, orders, and transfers without being overwhelming. Each tool earns its place by addressing a distinct operational need, making the count appropriate for the server's purpose.
The tool set provides complete CRUD/lifecycle coverage for domain management, including operations for account, aftermarket, contacts, DNS, domains, settings, folders, nameservers, orders, and transfers. There are no obvious gaps, ensuring agents can handle all core workflows without dead ends.
Domain search, registration, DNS, marketplace, and checkout with your AI agent.
Buy & manage domains from any AI chat: availability, register, DNS, email forwarding, AI bot stats.
Custom domains for SaaS and AI agents: search, register, connect DNS, and issue HTTPS over MCP.
Search, Register , Renew , Transfer and Manage domains
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/joachimBrindeau/domain-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
