Enables domain registration and DNS management with automatic Cloudflare integration
MCP server for AgentDomain — register, buy, and manage internet domains as an AI agent.
🔍 Search and check domain availability
🛒 Buy domains with automatic Cloudflare registration
🌐 Manage DNS records (A, CNAME, MX, TXT, etc.)
💰 Wallet balance and top-up
🔑 API key auto-saved locally
Related MCP server: Bloomfilter
uvx agentdomain-mcpOr with pip:
pip install agentdomain-mcpAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"agentdomain": {
"command": "uvx",
"args": ["agentdomain-mcp"]
}
}
}Add to your MCP settings:
{
"mcpServers": {
"agentdomain": {
"command": "uvx",
"args": ["agentdomain-mcp"]
}
}
}Add to ~/.hermes/config.yaml:
mcp_servers:
agentdomain:
command: "uvx"
args: ["agentdomain-mcp"]Register — Call the register tool with your name, email, and password
Verify email — Check your inbox and click the verification link
Top up — Add funds to your wallet via wallet_topup
Search — Find available domains with domain_search
Buy — Register a domain with domain_buy
Manage — Update DNS records with domain_dns_update
Tool | Description |
| Create account + save API key |
| Login to existing account |
| Get account details |
| Search available domains |
| Check availability + price |
| Register a domain |
| List your domains |
| Get DNS records |
| Update DNS records |
| Get EPP auth code |
| Check balance |
| Create top-up session |
| List transactions |
Variable | Default | Description |
|
| API base URL |
MIT
Get current account details (name, email, verification status).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 indicates a read operation but does not discuss authentication requirements or side effects. However, the simple read nature limits the need for additional disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 11 words, front-loaded with the purpose. Every word 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 simplicity (0 parameters, output schema present), the description is adequate. It identifies the resource and key fields, and the output schema handles return values.
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 tool has zero parameters, and the input schema is fully covered (100%). The description adds no parameter information, but none is needed. Baseline for 0 parameters is 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 specifies the verb 'Get' and the resource 'current account details', listing key fields (name, email, verification status). It distinguishes itself from siblings like login, register, domain tools, and wallet 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 implies usage when account details are needed, and no sibling tool provides the same function. However, it does not explicitly state when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register/buy a domain.
Requires sufficient wallet balance. The domain will be registered through Cloudflare and DNS records can be managed immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| years | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses registration through Cloudflare and that DNS can be managed immediately, but does not cover error handling for insufficient balance, domain availability, or any restrictions (e.g., TLD limits).
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 with clear purpose upfront. While concise, it could benefit from structuring prerequisites and post-purchase details more explicitly.
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?
Output schema exists (not shown) so return values may be documented there. However, description omits critical context: need to check domain availability, what happens if domain is taken, or any cost implications.
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 0%, and the description adds no detail beyond parameter names. 'domain' and 'years' are mentioned implicitly but not explained (e.g., format, constraints like max years).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Register/buy a domain' which clearly identifies the action and resource. It distinguishes from sibling tools like domain_check, domain_search, and domain_transfer.
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?
Mentions 'Requires sufficient wallet balance' as a prerequisite, but does not advise checking domain availability first or list alternatives. Implicitly, it is for purchasing domains, but lacks explicit when-to-use vs. when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a specific domain is available and get its price.
Returns availability status and registration cost.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description says it returns availability and price, implying a read-only operation, but does not disclose potential network calls or rate limits.
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 clearly communicate the purpose and output, 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 a simple single-parameter tool with no annotations but an output schema, the description adequately mentions return values, but lacks parameter format details.
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 only parameter 'domain' has no description in the input schema (0% coverage), and the tool description adds no details about valid formats (e.g., should include TLD?).
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 'check' and the resource 'domain availability and price', distinguishing it from sibling tools like domain_buy or domain_search.
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 is provided on when to use this tool versus alternatives; for example, it could be used before domain_buy but this is not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get DNS records for a domain.
Returns all DNS records (A, CNAME, MX, TXT, etc.) for the domain.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Returns all DNS records' but does not disclose behavior for missing domains, authentication requirements, rate limits, or any side effects. The read-only nature is implied but not explicit.
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 short sentences with no fluff. The second sentence partially repeats the first by enumerating record types, but it's not excessive. Could be merged into one concise sentence without loss.
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 only one parameter and presence of an output schema, the description is minimally sufficient. However, it lacks information about error cases, permissions, or behavior when domain is invalid. With no annotations, more context is needed for a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the only parameter 'domain'. The description adds no additional semantics beyond 'for a domain'—no format, example, or constraints. It fails to compensate for the schema 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 clearly states the action (Get DNS records) and the resource (domain). It lists specific record types (A, CNAME, MX, TXT), distinguishing it from sibling tools like domain_dns_update which modifies records.
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. It does not mention that this is for reading records, nor does it specify when to use domain_dns_update or other siblings. No prerequisites or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update DNS records for a domain.
Each record should have: type, name, content, ttl, and optionally proxied. Example: {"type": "A", "name": "@", "content": "1.2.3.4", "ttl": 300, "proxied": false}
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| records | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states 'Update' without explaining whether it replaces all records, merges, or patches omissions. There's no mention of idempotency, error handling, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences and an example: no fluff, front-loaded purpose. Every sentence contributes to understanding the input structure.
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?
Despite having an output schema, the description omits return behavior, error cases, and update semantics (replace vs merge). For a mutation tool with multiple siblings, more context is needed to avoid misuse.
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 has 0% description coverage, leaving both parameters undefined. The description adds meaning for 'records' by specifying required fields (type, name, content, ttl) and optional (proxied). However, 'domain' remains without explanation beyond its name.
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: 'Update DNS records for a domain.' It uses a specific verb (update) and resource (DNS records), and the sibling domain_dns_get indicates a clear separation of concerns (read vs write).
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 a structural example of expected input but does not specify when to use this tool over alternatives (e.g., when to update vs get or check). No explicit context on prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all domains registered on your account.
Returns domain names, status, expiration dates, and nameservers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the tool returns data (read-only) but does not mention rate limits, pagination, or any potential side effects. For a simple list operation, this is acceptable but not exemplary.
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, clear, and front-loaded with the main action. No unnecessary 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 has zero parameters and an output schema, the description adequately covers what the tool does and what it returns. It is complete for a listing 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?
The input schema has 0 parameters with 100% coverage. The description adds value by specifying the output fields (domain names, status, expiration dates, nameservers), which is 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 lists all domains on the account and specifies the returned fields (names, status, expiration, nameservers). This distinguishes it from sibling tools like domain_buy, domain_check, domain_search, and domain_transfer.
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 use for listing all domains but does not explicitly state when to use this versus domain_search or other listing tools. No guidance on when not to use or alternatives is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for available domains matching a keyword.
Returns a list of available domain names with prices.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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. It only states the basic function and output, omitting details like required authentication, rate limits, or side effects. The description does not add value beyond the purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loading the purpose and output. Every sentence adds value, but it could be slightly more detailed without losing conciseness.
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 nature of a search tool and the presence of an output schema (not detailed in description), the description covers the basic return values. However, it lacks context about error handling, pagination, or how it differs from sibling tools, making it minimally 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?
Schema description coverage is 0%, and the description does not mention any parameters. It provides no meaning beyond the raw schema, which already documents query (required) and limit (optional with default). The description must compensate for low coverage but fails to do so.
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 searches for available domains matching a keyword and returns names with prices. It provides a specific verb-resource combination and mentions output, but does not distinguish from siblings like domain_check or domain_list.
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 is given on when to use this tool versus alternatives. There are many domain-related siblings (domain_check, domain_buy, etc.) but no differentiation or contextual advice on when to choose domain_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the EPP authorization code to transfer a domain to another registrar.
Returns the auth code needed for domain transfer.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions the tool returns an auth code but does not disclose potential side effects (e.g., domain status changes, code expiration) or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences), with the purpose stated upfront. No unnecessary information, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and an output schema, the description is minimally adequate but lacks details on return format and prerequisites. Given the sibling tools, it could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'domain' has no additional meaning added beyond its schema title. Schema description coverage is 0%, and the description fails to specify expected format (e.g., full domain name with TLD).
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 retrieves the EPP authorization code for domain transfer. The verb 'Get' and resource 'EPP authorization code' are specific, and the tool is easily distinguished from sibling tools like domain_buy, domain_check, and domain_dns_update.
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 the tool is used to obtain an auth code for transferring a domain, but provides no explicit guidance on when to use it vs alternatives, or prerequisites like domain unlock or transfer restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Login to an existing AgentDomain account and save the API key.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| password | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must inform about side effects. It mentions 'save the API key' but does not clarify where it is saved, whether credentials are stored, or if it creates a session. No information about error handling or security implications.
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, concise sentence that immediately conveys the core purpose with no extraneous 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?
Despite the existence of an output schema, the description omits critical details such as the required nature of inputs, authentication implications, and expected outcomes. For a credential-based login, more context is needed.
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%, and the description provides no additional meaning for the 'email' and 'password' parameters. No format, constraints, or purpose beyond the schema field names are given.
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 ('Login'), the target resource ('existing AgentDomain account'), and the outcome ('save the API key'). It effectively distinguishes from the sibling tool 'register' by specifying 'existing' account.
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 use for existing accounts but provides no explicit guidance on when to use this tool versus alternatives (e.g., 'register' for new accounts). No when-not-to-use or prerequisite conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new AgentDomain account and save the API key.
Call this first if you don't have an account. The API key is saved automatically for future calls.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| Yes | |||
| password | Yes | ||
| billing_name | No | ||
| billing_address | No | ||
| billing_city | No | ||
| billing_country | No | US | |
| billing_postal | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions side effect of saving API key automatically, which is helpful. But with no annotations, it lacks disclosure of permissions, rate limits, error handling, or detailed behavior beyond creation.
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, front-loaded with action and context, no redundant information. Every sentence serves a clear purpose.
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?
Provides essential usage context and side effect, but does not explain return value (though output schema exists) or detail billing parameters. Missing information for a complete understanding.
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 0%, and the description adds no meaning to individual parameters. It only implies name, email, password are required but doesn't explain what each parameter represents or the purpose of billing fields.
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 AgentDomain account and save the API key,' specifying verb and resource. It also distinguishes from siblings like login by saying 'Call this first if you don't have an account.'
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 call this first if no account exists, giving clear context for when to use. However, it does not explicitly mention alternatives or when not to use, though the implication is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check your AgentDomain wallet balance.
Returns balance in cents and spending limits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that it returns balance in cents and spending limits, which is useful. However, without annotations, it lacks explicit mention of read-only nature or authentication requirements.
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, no waste. Front-loaded with purpose, followed by return details. Highly concise and 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 zero parameters and presence of an output schema, the description is fully complete. It explains the return format (cents and spending limits), covering all needed 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?
No parameters exist (0 params), so baseline 4 applies. The description does not need to add parameter info, and it correctly states what the tool returns.
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 wallet balance, with a specific verb 'Check' and resource 'AgentDomain wallet balance'. It distinguishes from siblings like wallet_topup and wallet_transactions by focusing on balance retrieval.
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 like wallet_transactions or account_info. The description only states what it does, not when it is appropriate or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a card top-up session for your wallet.
Returns a Stripe Checkout URL to complete payment.
| Name | Required | Description | Default |
|---|---|---|---|
| amount_cents | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavior. It mentions creating a session and returning a URL, but does not clarify session lifecycle, payment failure consequences, or idempotency. This is insufficient for an agent to fully anticipate side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information. Efficiently conveys the core purpose and return value. Could be slightly more structured but remains highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers the basic idea. However, it omits details like whether amount_cents is in cents, if there is a minimum, or what the Stripe URL response contains. Adequate but not thorough.
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 only parameter amount_cents has 0% schema description coverage. The description does not add meaning like minimum value, allowed range, or currency. It merely restates the parameter name, providing no additional semantic 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?
Description clearly states the action (create a card top-up session) and the output (Stripe Checkout URL). It distinguishes from siblings like wallet_balance (read-only) and wallet_transactions (listing).
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 use when adding funds via card, but does not explicitly state when to avoid this tool or mention alternatives. As a single-purpose tool, the lack of explicit guidance is acceptable but not exceptional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent wallet transactions.
Shows domain purchases, top-ups, and refunds.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It mentions listing recent transactions but lacks details on authentication requirements, time range, or default limit. The schema shows a limit parameter but the description ignores it.
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 with front-loaded purpose. No redundant information, but could benefit from adding parameter details or usage hints without becoming verbose.
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?
An output schema exists but is not explained. Missing critical context such as authentication, default behavior, and pagination. The description is insufficient for a tool with no annotations and a single undocumented parameter.
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 0% and the description does not mention the only parameter (limit). It adds no meaning beyond the schema, leaving the agent uninformed about how to control the number of transactions.
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 recent wallet transactions and specifies types (purchases, top-ups, refunds). It is specific and distinct from sibling tools like wallet_balance or wallet_topup, though could mention 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 vs alternatives. While the purpose implies it for viewing history, no exclusions or comparisons to siblings like wallet_balance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.1.2account_infodomain_buydomain_checkdomain_dns_getdomain_dns_updatedomain_listdomain_searchdomain_transferloginregisterwallet_balancewallet_topupwallet_transactionsEach tool targets a distinct operation: account, domain actions (buy, check, list, search, transfer), DNS management, wallet, and auth. No overlap between tools; even domain_check and domain_search serve different purposes (specific vs keyword search).
Most tools follow a domain_verb or wallet_verb pattern (e.g., domain_buy, domain_check, wallet_balance). However, login and register deviate from this pattern, and account_info is noun_noun. Still, the majority are consistent.
13 tools cover domain lifecycle (search, check, buy, list, transfer, DNS management) plus account and wallet operations. This is well-scoped for a domain registrar MCP server, neither too few nor too many.
The set covers core domain operations: search, check, buy, list, transfer, DNS management. Missing domain renewal and deletion, but these are less critical. Wallet and account tools are complete. Minor gaps but overall functional.
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.
AI agent registry — search, discover, register, and connect agents via MCP.
Domain registration for AI agents via Stripe or x402 crypto with Cloudflare DNS.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MarsHeer/agentdomain-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
