The Muumuu Domain MCP Server enables natural language management of domains and DNS via AI assistants like Claude and Cursor.
Domain Search & Purchase: Search availability and pricing, get a purchase quote with a short-lived token, purchase domains (irreversible, charges credit card), and check purchase status.
Domain Management: List and view details of owned domains (including contract period, auto-renewal status, nameservers), with filtering and pagination; toggle credit-card auto-renewal.
DNS Management: List, create, update, and delete DNS records (A, AAAA, CNAME, MX, TXT, NS, ALIAS, SRV, CAA) for owned domains.
Personal Access Tokens: List and revoke personal access tokens.
日本語版 README はこちら / Japanese README
The official remote Model Context Protocol (MCP) server for Muumuu Domain — a domain registration service operated by GMO Pepabo, Inc.
Search and register domains, manage owned domains and contracts, and configure DNS records — all through natural language conversations with AI assistants.
First remote MCP server in the Japanese domain registrar industry.
https://mcp.muumuu-domain.com/mcpTransport: Streamable HTTP. Authentication: OAuth 2.1 (handled automatically by supported clients).
Related MCP server: Whodis MCP Server
Domain search & registration — check availability, view pricing, register domains
Domain management — list and inspect owned domains
DNS management — list, create, update, and delete DNS records
Contract management — review contract list (renewal dates, auto-renewal status) and details
Pricing: MCP server access is free. Standard Muumuu Domain registration fees apply when purchasing domains.
Choose your client below.
claude mcp add --transport http muumuu https://mcp.muumuu-domain.com/mcpThen run /mcp inside Claude Code and select Authenticate to complete the OAuth flow.
Settings → Connectors → Add custom connector → enter:
https://mcp.muumuu-domain.com/mcpOAuth is handled automatically by Claude.
Add to .cursor/mcp.json:
{
"mcpServers": {
"muumuu": {
"url": "https://mcp.muumuu-domain.com/mcp"
}
}
}codex mcp add muumuu --url https://mcp.muumuu-domain.com/mcpSee the Gemini CLI MCP server documentation for adding remote MCP servers.
For clients that only support stdio transport, use mcp-remote:
{
"mcpServers": {
"muumuu": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://mcp.muumuu-domain.com/mcp"]
}
}
}For MCP registries (e.g. Glama) that index the tool surface in a headless build environment where an interactive OAuth flow cannot complete, the CLI also supports a stdio-only introspection mode:
node bin/muumuu-mcp.js --introspect-onlyIn this mode the CLI serves the static tool manifest over stdio. It does not make any network calls, does not read the Authorization header, and tools/call always returns isError: true. Do not use this mode for real traffic.
The server exposes 14 tools. Tools marked write change account state; those marked destructive cannot be undone — clients should confirm with the user before calling them.
Tool | Description |
| Check availability and pricing of domain candidates across TLDs. Does not reserve anything. |
| Get a signed quote — final price, availability, and a short-lived purchase token — before buying. |
| Execute a purchase with a quote token. write / destructive — charges the registered credit card. |
| Poll the progress of a purchase started by |
Tool | Description |
| List domains owned by the authenticated account, filtered by state or FQDN, paginated. |
| Fetch one owned domain in full: contract period, auto-renewal status, nameservers. |
| Turn credit-card auto-renewal on or off for an owned domain. write |
Tool | Description |
| List the DNS records of an owned domain, addressed by domain ID. |
| The same listing, addressed by FQDN when the domain ID is unknown. |
| Add a record — A, AAAA, CNAME, MX, TXT, NS, ALIAS, SRV, or CAA. write |
| Change the value or priority of an existing record. write |
| Remove a record from the zone. write / destructive |
Tool | Description |
| List the personal access tokens issued for the account. |
| Revoke a personal access token. write / destructive |
A Muumuu Domain account
An MCP-compatible client (Claude Desktop, Claude Code, Cursor, OpenAI Codex CLI, Gemini CLI, etc.)
For service-related inquiries: Muumuu Domain Help Center
For issues with this repository: please open a GitHub Issue
Create a new DNS record on an owned domain. Changes take effect on Muumuu's authoritative nameservers. Mutating operation: confirm intent with the user before calling.
| Name | Required | Description | Default |
|---|---|---|---|
| domain-id | Yes | Domain ID issued by Muumuu Domain. Format: 'MU' followed by 8 digits (e.g. MU00000001). | |
| payload | Yes | DNS record to create. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint=false and idempotentHint=false, the description adds important context: changes take effect on authoritative nameservers, and it's a mutating operation requiring user confirmation. No contradiction with annotations. Slightly less than 5 because it doesn't detail what happens if the record already exists or other edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second adds behavioral context. No fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested object payload) and the fact that schema covers 100% of parameters, the description is nearly complete. It lacks details about return value or error states, but no output schema exists, so that burden falls on description. Slightly less than 5 because of missing outcome 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% (all parameters and nested properties have descriptions). The description adds minimal parameter semantics beyond the schema, but the schema already documents format and requirements thoroughly. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a new DNS record on an owned domain', specifying the verb (create), resource (DNS record), and scope (on an owned domain). It distinguishes from sibling tools like 'delete-me-dns-record' and 'update-me-dns-record' by explicitly naming the operation type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Changes take effect on Muumuu's authoritative nameservers' and 'Mutating operation: confirm intent with the user before calling'. This tells the agent when to use (when user requests creating a DNS record) and when not to (requires user confirmation due to mutation). Alternatives are implied by sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a DNS record from an owned domain. Destructive and NOT reversible — confirm with the user before calling.
| Name | Required | Description | Default |
|---|---|---|---|
| domain-id | Yes | Domain ID issued by Muumuu Domain. Format: 'MU' followed by 8 digits (e.g. MU00000001). | |
| record-id | Yes | DNS record ID to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Permanently delete a DNS record' and 'Destructive and NOT reversible', which aligns with and adds context beyond annotations (destructiveHint=true). The annotation idempotentHint=true might appear contradictory, but the description's emphasis on irreversibility clarifies that the operation, while idempotent in HTTP sense, has permanent effects. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a crucial warning. Both are essential and concise; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a tool with only two well-described parameters and no output schema (common for delete operations). Combined with annotations, it provides complete contextual information for safe usage.
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 baseline is 3. The description does not add any extra information about the parameters beyond what the schema provides, but that's acceptable since the schema is thorough with descriptions and pattern constraints.
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 'Permanently delete a DNS record from an owned domain', which uses a specific verb (delete) and resource (DNS record). It distinguishes itself from siblings like 'create-me-dns-record' and 'update-me-dns-record'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns 'Destructive and NOT reversible — confirm with the user before calling', providing clear guidance on when to use (with user confirmation) and why caution is needed. This differentiates it from read-only tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll the progress of a domain purchase started by purchase-domain. Use the purchase_id returned by that call to track state transitions (pending → processing → completed / failed).
| Name | Required | Description | Default |
|---|---|---|---|
| purchase_id | Yes | Purchase session ID returned by `purchase-domain`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only (`readOnlyHint: true`) and open-world (`openWorldHint: true`) behavior. The description adds context about polling and state transitions. No contradictions; it complements annotations well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loading purpose and usage, with no wasted words.
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 simplicity (single param, no output schema), the description is sufficient. It explains the polling behavior and state transitions. Minor gap: no expected response format mentioned, but acceptable for a simple poll 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% and the description adds context by explaining the parameter's origin (`purchase_id` from `purchase-domain`) and its role in tracking progress, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it polls the progress of a domain purchase initiated by `purchase-domain`, specifying the sequence and resource. It distinguishes itself from sibling tools by focusing on purchase status tracking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly ties usage to the purchase flow, mentioning the `purchase_id` from `purchase-domain` and expected state transitions, guiding when and how to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full details of a single owned domain by its Muumuu domain ID, including contract period, auto-renewal status, and nameserver configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| domain-id | Yes | Domain ID issued by Muumuu Domain. Format: 'MU' followed by 8 digits (e.g. MU00000001). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description covers safe read-only operation (annotations confirm readOnlyHint=true) and specifies what data is retrieved. OpenWorldHint is noted but not contradicted. Description adds context about data fields beyond 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?
Single, front-loaded sentence that efficiently communicates purpose and included fields with no wasted words.
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 single parameter with full schema coverage, no output schema, and simple read operation, description is sufficiently complete. Sibling tools cover related listing and DNS operations, so context is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed description and pattern for domain-id (100% coverage). Description reiterates the format and mentions it's from Muumuu Domain, adding slight clarity but schema already suffices.
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?
Description clearly states the verb 'Fetch full details' and specific resource 'a single owned domain by its Muumuu domain ID', listing included fields (contract period, auto-renewal, nameserver config) distinguishes it from siblings like list-me-domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for getting details of a single domain, contrasting with list-me-domains for listing all. However, no explicit guidance on when to use alternatives or when not to use this tool is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List DNS records for a specific owned domain (identified by domain ID). Supports filtering by record type or FQDN, with pagination. Read-only view of the authoritative zone.
| Name | Required | Description | Default |
|---|---|---|---|
| domain-id | Yes | Domain ID issued by Muumuu Domain. Format: 'MU' followed by 8 digits (e.g. MU00000001). | |
| fqdn | No | Exact FQDN match filter (trailing dot required, e.g. 'www.example.com.'). | |
| type | No | Filter by DNS record type (A, AAAA, CNAME, MX, TXT, NS, ALIAS, SRV, CAA). | |
| page | No | Page number (1-indexed). | |
| page-size | No | Items per page (maximum 100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint, and description adds 'Read-only view of the authoritative zone' reinforcing safety. No contradictions; description adds context about zone and authoritative nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no fluff. Front-loaded with main action and key qualifiers (domain ID, filtering, pagination). Every phrase earns its place.
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 no output schema and simple list operation, description covers purpose, parameters, and read-only behavior. Could add that it returns a list of DNS record objects, but not essential for agent invocation since schema is detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by stating filtering by 'record type or FQDN' and pagination, which synthesizes the purpose. Not adding much beyond what schema already says, but sufficiently clear.
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?
Description explicitly states 'List DNS records for a specific owned domain', includes filtering and pagination capabilities, and distinguishes from sibling tools like list-me-dns-records-by-fqdn by mentioning domain ID and read-only nature. Verb 'List' and resource 'DNS records' are clear.
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?
Describes when to use (list records, filter, paginate) and hints at read-only use (vs. create/delete). However, does not explicitly mention alternatives like list-me-dns-records-by-fqdn or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List DNS records by specifying the owning domain as an FQDN instead of an internal domain ID. Use this when the caller only knows the domain name (e.g. 'example.com') and not its Muumuu domain ID.
| Name | Required | Description | Default |
|---|---|---|---|
| domain-fqdn | Yes | FQDN of the target domain (exact match), e.g. 'example.com' or 'example.co.jp'. | |
| fqdn | No | Optional: exact-match filter on the DNS record FQDN. | |
| type | No | Filter by DNS record type. | |
| page | No | Page number (1-indexed). | |
| page-size | No | Items per page (maximum 100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and description adds no contradiction; it confirms the safe read operation. Minor behavioral details like pagination are in schema, not description, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, no wasted words.
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 simple list operation with 100% schema coverage and readOnlyHint, the description adequately covers usage. No output schema, but return values are predictable for a list operation.
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. The description adds no additional semantics beyond what is in the schema, maintaining baseline 3.
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 lists DNS records by FQDN instead of internal domain ID, providing a specific verb+resource and distinguishing from sibling 'list-me-dns-records' which uses internal ID.
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?
Explicitly says to use this when caller only knows domain name, not internal ID, directly differentiating from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List domains owned by the authenticated account. Supports pagination and filtering by state or exact FQDN match. Use this to discover domain IDs needed by other tools (e.g. DNS management).
| Name | Required | Description | Default |
|---|---|---|---|
| fqdn | No | Exact FQDN match filter (e.g. 'example.com'). When set, only that domain is returned. | |
| state | No | Filter by domain lifecycle state: active | inactive | pending-setup (onboarding) | pending-transfer (transfer in progress) | pending-bulk (bulk-purchase queued). | |
| page | No | Page number (1-indexed). | |
| page-size | No | Items per page (maximum 100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true (mutation safety) and openWorldHint=true (dynamic results). The description adds that it supports pagination and filtering, which is useful behavioral context beyond annotations. It discloses the purpose for discovering domain IDs. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, supported features, usage hint. No filler or redundancy. Front-loaded with the primary action. Every sentence earns its place.
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 low complexity (list with filters), no required params, and no output schema, the description adequately covers purpose, filtering, pagination, and usage hint. Minor gap: doesn't mention the range of states explicitly (but schema does), and doesn't describe return format (acceptable without output schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions, so baseline is 3. The description adds value by clarifying that fqdn is an 'Exact FQDN match filter' and that 'When set, only that domain is returned', which reinforces behavior. The state filter is explained with examples. This raises the score to 4.
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 verb 'list' and the resource 'domains owned by the authenticated account'. It distinguishes from sibling tools like 'get-me-domain' (single domain) and 'search-domains' (broader search) by specifying the scope and filtering options.
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 includes a usage hint: 'Use this to discover domain IDs needed by other tools (e.g. DNS management).' This provides context for when to use this tool. However, it does not explicitly exclude cases or mention alternatives beyond the hint, so it scores a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a domain purchase using a purchase-token obtained from quote-domain-purchase. This is a paid, irreversible operation. Charges the registered credit card. Require explicit user confirmation of the quoted amount before calling. Returns a purchase_id to poll with get-domain-purchase-status.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only. Description adds critical details: irreversible, charges card, user confirmation needed, returns a purchase_id for polling. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each packed with essential info: action, warning, prerequisite, side effect, next step. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and high annotations, the description covers all needed context: input origin, irreversible effect, billing action, confirmation requirement, and follow-up polling URL.
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 has 0% coverage, so description must compensate. It describes the purchase-token parameter's origin, purpose, and validation (expired tokens rejected). Exact schema details like property names are missing, but the key semantic is clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Execute a domain purchase'), the required input ('purchase-token obtained from quote-domain-purchase'), and the irreversible nature. It distinguishes itself from sibling tools like quote-domain-purchase and get-domain-purchase-status.
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?
Explicitly says when to use ('after obtaining purchase-token'), prerequisites ('explicit user confirmation of quoted amount'), and alternatives (poll with get-domain-purchase-status). No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a signed purchase quote for a domain before buying. Returns the final price, availability, credit-card registration state, and a short-lived purchase-token (valid ~10 minutes). Always call this before purchase-domain and present the price to the user.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as readOnlyHint: true and openWorldHint: true, indicating it's a read-only operation with dynamic output. The description adds behavioral context: the 'purchase-token' is short-lived (~10 minutes). This is useful but not extensive. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two sentences. The first sentence states purpose and key outputs, the second gives explicit usage instruction. No extraneous words. Front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has moderate complexity (one nested param object) with no output schema. The description covers purpose, key outputs, token validity, and usage order. However, it does not describe the return format or list all output fields (e.g., price structure). With annotations providing readOnly and openWorld hints, the description is nearly complete for agent invocation decision-making.
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 add meaning. The description does not detail parameters 'fqdn' and 'term' beyond what the schema provides (e.g., schema describes fqdn as 'Target domain name'). However, the description's context (quote, price, purchase-token) implicitly explains the role of the 'fqdn' parameter. The 'term' parameter is not mentioned, which is a minor gap. Overall, the purpose-driven description compensates well.
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: 'Get a signed purchase quote for a domain before buying.' It identifies the specific verb ('get a signed purchase quote'), resource ('domain purchase'), and output (final price, availability, credit-card registration state, purchase-token). It is easily distinguished from the sibling 'purchase-domain' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'Always call this before purchase-domain and present the price to the user.' This provides clear guidance on the workflow order and direct instruction to present the price, distinguishing it from the purchase step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check availability and pricing of one or more domain names across TLDs. Use this before suggesting a domain to purchase. Returns each candidate with its availability state and price in JPY. Does NOT reserve or purchase the domain.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search keyword. Either a full domain name with TLD (e.g. 'example.com') or a bare label without TLD (e.g. 'example'). When no TLD is present, specify the `tlds` parameter. | |
| tlds | No | Candidate TLDs to search when `q` omits the TLD (e.g. ['com', 'net', 'jp']). Ignored when `q` already contains a TLD. Defaults to a curated set of popular TLDs when omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description is not required to restate safety. It adds non-obvious details: returns price in JPY, does not reserve/purchase. This is sufficient beyond annotations, missing only potential rate limits or data freshness.
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 only three sentences, each with a distinct purpose: function, usage guidance, and important limitations. No fluff or repetition.
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 is simple (2 params, no output schema, no nested objects), the description covers purpose, usage, and limitations. The annotations cover safety. For this complexity, it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already provides full parameter descriptions. The description briefly mentions the two parameter types but adds no crucial extra semantics beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks domain availability and pricing, specifies it returns availability state and price in JPY, and explicitly says it does NOT reserve or purchase, distinguishing its action from purchase 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 says to use this before suggesting a domain to purchase, providing clear usage context. It also states what it does not do (reserve/purchase), and siblings like purchase-domain are separate, so the agent can differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the value or priority of an existing DNS record. fqdn, type, and ttl are immutable — delete and recreate if those need to change. Mutating operation.
| Name | Required | Description | Default |
|---|---|---|---|
| domain-id | Yes | Domain ID issued by Muumuu Domain. Format: 'MU' followed by 8 digits (e.g. MU00000001). | |
| record-id | Yes | DNS record ID (integer). | |
| payload | Yes | Fields to update. Supply at least one of `value` or `priority`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true (the operation is safe to retry) and readOnlyHint=false (it's a mutation). The description adds the crucial behavioral detail that the operation is 'Mutating operation', which aligns with non-readOnly. It also specifies which fields are immutable, adding context beyond 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 two sentences: the first states the tool's purpose, the second provides immutable-field guidance. No wasted words; front-loaded with critical info.
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 has no output schema, the description fully explains the operation, its constraints, and alternatives. For a mutation operation with clear parameters and annotations, the description is complete enough to guide correct 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 coverage is 100% and descriptions in the schema are thorough, including formats, patterns, and constraints. The description adds no further parameter details but reinforces that only `value` and `priority` are mutable. Since schema already does heavy lifting, a 4 is appropriate for not repeating what's already covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update the value or priority of an existing DNS record' which is a specific verb+resource combination. It clearly distinguishes from siblings like create-me-dns-record (creation) and delete-me-dns-record (deletion), and lists the two mutable fields explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when NOT to use this tool: if `fqdn`, `type`, or `ttl` need to change, the user should 'delete and recreate' instead. This provides clear guidance on when to use alternatives (create/delete) and outlines the immutable fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools target distinct resources (domains, DNS records, purchases), but `list-me-dns-records` and `list-me-dns-records-by-fqdn` are very similar, differing only in how the domain is identified. This could cause confusion but is mitigated by descriptions explaining the distinction.
Tool names use a consistent verb-hyphen-noun pattern (e.g., create-me-dns-record, list-me-domains) with a 'me' context prefix. The only minor inconsistency is `get-domain-purchase-status` lacking the 'me' prefix, and `search-domains` does not include 'me' either.
With 11 tools covering domain management, DNS records, and purchase workflow, the count is well-scoped for a domain registrar MCP server. Each tool feels necessary, and there are no redundant or extraneous tools.
The tool surface covers core domain lifecycle (search, quote, purchase, status poll, list owned) and DNS CRUD except for missing an explicit update for domain metadata (e.g., auto-renewal toggle). However, the DNS record tools are complete (create, list, update, delete).
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Custom domains for SaaS and AI agents: search, register, connect DNS, and issue HTTPS over MCP.
Domain search, registration, DNS, marketplace, and checkout with your AI agent.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pepabo/muumuu-domain-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
