This server connects AI assistants to your Domain Pilot account, enabling domain portfolio management, DNS control, uptime monitoring, SSL tracking, and health analysis through natural language.
Domain Management
List all domains with their status, health grade, and monitoring state
Get detailed domain info including uptime, SSL, health scores, and expiry dates
Add new domains to monitor
Get a dashboard overview — total domains, online count, expiring domains, and alerts
Health & AI Analysis
Get domain health check results including scores and grades
Trigger on-demand health checks for any domain
Get AI-powered analysis with findings and recommendations
DNS Management
List all DNS records for a domain
Add DNS records (A, AAAA, CNAME, MX, TXT, NS)
Update existing DNS records (value, TTL, priority)
Acknowledge detected DNS changes
(Note: DNS record deletion is intentionally not supported — use the web UI for that)
Uptime & Incidents
Get uptime statistics for 24h, 7d, or 30d periods
List downtime incidents for a domain
Toggle uptime monitoring on or off
SSL
Get SSL certificate status and details for a domain
Click on "Deploy 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., "@DomainPilot MCP Server Check the health of domain example.com"
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.
A Model Context Protocol (MCP) server that connects AI assistants to your Domain Pilot account. Manage domains, DNS records, uptime monitoring, SSL status, and more through natural language in Claude Desktop, Claude Code, or any MCP-compatible client.
The server is published on npm, so there's nothing to install or build -- npx fetches and runs it on demand.
Generate an MCP API token from your Domain Pilot settings page at domainpilot.io/settings/mcp.
One command -- no config file to edit:
claude mcp add domainpilot --env DOMAINPILOT_API_TOKEN=your-token-here -- npx -y domainpilot-mcpThe -- separates Claude's flags from the command it runs; everything after it is the launch command. Pin a version with domainpilot-mcp@1.0.2 if you prefer.
Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"domainpilot": {
"command": "npx",
"args": ["-y", "domainpilot-mcp"],
"env": {
"DOMAINPILOT_API_TOKEN": "your-token-here"
}
}
}
}Use the same pattern -- run npx -y domainpilot-mcp and set the DOMAINPILOT_API_TOKEN environment variable.
To run a local checkout instead of the published package:
git clone https://github.com/warunacds/domainpilot-mcp.git
cd domainpilot-mcp
npm install
npm run buildThen point your client's command/args at the built entry point -- "command": "node", "args": ["/absolute/path/to/domainpilot-mcp/dist/index.js"].
The remote entrypoint serves stateless Streamable HTTP at /mcp:
# Development
npm run dev:http
# Built server
npm run build
npm run start:httpList tools without authentication:
curl http://localhost:3000/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'Tool calls require a bearer token on the request:
curl http://localhost:3000/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-H 'Authorization: Bearer your-token-here' \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"list_domains","arguments":{}}}'The HTTP entrypoint never uses DOMAINPILOT_API_TOKEN; each tool call uses only
the bearer token supplied with that request.
Related MCP server: Coolify MCP Server
Tool | Description |
| List all your domains with status, health grade, and monitoring state |
| Get detailed info about a specific domain (uptime, SSL, health, expiry) |
| Add a new domain to monitor |
| Get latest health check results including scores and grade |
| Trigger an on-demand health check for a domain |
| Get AI-powered analysis with findings and recommendations |
| Get uptime statistics for a domain (24h, 7d, or 30d) |
| List all DNS records for a domain |
| Add a DNS record (A, AAAA, CNAME, MX, TXT, NS) |
| Update an existing DNS record |
| Acknowledge detected DNS changes for a domain |
| Get SSL certificate status and details |
| List downtime incidents for a domain |
| Get portfolio overview (total domains, online count, alerts) |
| Enable or disable uptime monitoring for a domain |
Note: DNS records can be added and updated, but deletion is intentionally not exposed through this server. Removing a record is the highest-risk DNS operation and the hardest to undo, so it is left out by design. Delete records via the Domain Pilot web UI instead.
Variable | Required | Default | Description |
| Stdio only | -- | Your Domain Pilot MCP API token |
| No |
| API base URL (override for development) |
| HTTP only |
| Port for the Streamable HTTP server |
| HTTP only |
| Bind address for the Streamable HTTP server |
# Run in development mode (no build needed)
DOMAINPILOT_API_TOKEN=your-token npm run dev
# Build for production
npm run build
# Run the built server
DOMAINPILOT_API_TOKEN=your-token npm startMake sure the DOMAINPILOT_API_TOKEN environment variable is set in your MCP client configuration. Generate a token at your Domain Pilot settings page.
Your token may have been revoked or expired. Generate a new one from your Domain Pilot settings page.
Double-check the domain name. It must match exactly as shown in your Domain Pilot account (e.g., example.com, not www.example.com or https://example.com).
Make sure the path to dist/index.js is absolute (not relative)
Restart Claude Desktop after editing the config
Check that node is available in your PATH
If using a custom DOMAINPILOT_API_URL, verify the URL is correct and the server is reachable. The default URL points to the production Domain Pilot API.
MIT
Acknowledge detected DNS changes for a domain
| Name | Required | Description | Default |
|---|---|---|---|
| domain_name | Yes | The domain name (e.g., "example.com") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states what it does (acknowledge), but does not explain side effects (e.g., whether it is destructive, requires permissions, or dismisses alerts). Critical for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no fluff. It is front-loaded and efficient, though could be slightly more informative 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 tool's simplicity (one parameter, no output schema), the description is too sparse. It omits details on return values, when acknowledgment is needed, and any confirmation behavior. Incomplete 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 coverage is 100% (the sole parameter 'domain_name' is well-described in the schema). The description adds no extra meaning beyond the schema, so baseline of 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 action ('Acknowledge') and resource ('detected DNS changes for a domain'). It is specific and not a tautology, but does not differentiate from sibling tools like 'add_dns_record' or 'update_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 provides no guidance on when to use this tool versus alternatives, no prerequisites, and no contextual usage hints. This is a significant gap for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a DNS record to a domain
| Name | Required | Description | Default |
|---|---|---|---|
| ttl | No | Time to live in seconds (optional) | |
| name | Yes | The record name (e.g., "@" for root, "www", "mail") | |
| value | Yes | The record value (e.g., IP address, hostname, text) | |
| priority | No | Priority for MX records (optional) | |
| domain_name | Yes | The domain name (e.g., "example.com") | |
| record_type | Yes | The DNS record type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It fails to mention any side effects, such as propagation time, overwrite behavior, validation rules, or access requirements for a mutation tool.
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 with no unnecessary words or fluff. It is appropriately front-loaded.
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 no annotations, the description is incomplete for a tool with 6 parameters. It lacks information about return values, error conditions, or typical usage patterns.
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 meaning beyond the schema, earning the 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 verb 'Add' and resource 'DNS record' with target 'domain'. It effectively distinguishes from sibling tools like 'update_dns_record' and 'get_dns_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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical contexts, or exclusions like when to use update_dns_record instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new domain to monitor
| Name | Required | Description | Default |
|---|---|---|---|
| auto_renew | No | Whether the domain auto-renews (optional) | |
| domain_name | Yes | The domain name to add (e.g., "example.com") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral transparency. It only states the action but fails to disclose important traits such as what happens after adding (e.g., immediate monitoring, need for DNS verification), potential side effects, or required permissions.
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 with no unnecessary words. It is front-loaded with the core action.
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 the tool (add operation, 2 params, no output schema), the description is adequate but lacks details on behavior like duplicate handling or validation, which would improve completeness.
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% with descriptions for both parameters. The description adds no additional meaning beyond the schema, so it meets the baseline but does not provide 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 clearly states the action and resource: 'Add a new domain to monitor'. It uses a specific verb and resource, and the purpose is distinct from sibling tools like list_domains or get_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?
No guidelines are provided about when to use this tool versus alternatives, no prerequisites (e.g., domain must not already be monitored), and no mention of when not to use it. The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest AI-powered analysis for a domain with findings and recommendations. Can optionally regenerate if a free generation is available.
| Name | Required | Description | Default |
|---|---|---|---|
| regenerate | No | Set to true to regenerate the analysis (may require payment) | |
| domain_name | Yes | The 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. It discloses that regeneration may require payment, but fails to explain behavior when no free generation is available, whether regeneration creates or replaces analysis, or if the operation is idempotent.
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 consists of two concise sentences, front-loading the main purpose and then adding the optional regeneration feature. 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?
While the description covers the basic purpose and regeneration option, it lacks details on output format, behavior when no free generation is available, and potential side effects. Given the lack of annotations and output schema, the description is adequate but has clear gaps.
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 describes both parameters (100% coverage). The description adds meaningful context: 'Can optionally regenerate if a free generation is available' clarifies the regenerate parameter's behavior beyond the schema's 'may require payment' note.
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 retrieves the latest AI-powered analysis for a domain, including findings and recommendations. It distinguishes itself from sibling tools, none of which offer AI analysis, and specifies an optional regeneration feature.
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 does not provide explicit guidance on when to use this tool versus alternatives, nor does it explain when to set regenerate to true versus false. The mention of 'if a free generation is available' hints at conditions but offers no structured usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an overview of your domain portfolio — total domains, online count, expiring, alerts
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, and the description is straightforward, indicating a read-only operation that retrieves summary statistics. It does not disclose potential caveats like data freshness or permissions, but the simplicity of the tool (no parameters, no side effects) makes the behavioral disclosure adequate.
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 front-loads the purpose and includes the key metrics. Every word contributes to the meaning, with no redundancy or unnecessary detail.
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 (no parameters, no output schema, no nested objects), the description fully specifies what the tool returns. It is complete and sufficient for an agent to understand the tool's functionality.
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 schema coverage is 100%. The description adds no additional parameter information, but none is needed. Baseline score for no 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 states the tool provides an overview of the domain portfolio, listing specific metrics like total domains, online count, expiring, and alerts. It is a specific verb ('get') and resource ('dashboard stats'), and the listed metrics distinguish it from sibling tools that focus on individual domains or specific aspects.
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 for a high-level overview, but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. Given the simplicity of the tool and no siblings that directly compete, this is acceptable but leaves room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all DNS records for a domain
| Name | Required | Description | Default |
|---|---|---|---|
| domain_name | Yes | The domain name (e.g., "example.com") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as pagination, rate limits, authentication requirements, or whether the operation is read-only. The simple statement does not add depth beyond the obvious.
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, front-loaded sentence with no redundant information. Every word is necessary and contributes to purpose 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?
For a simple list tool with one parameter and no output schema, the description is minimally adequate. However, it fails to mention the return format or any limitations, which reduces completeness for an agent deciding whether the tool meets its needs.
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 100% coverage with a description for the only parameter. The description adds little beyond the schema's parameter description, 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 'List all DNS records for a domain' clearly specifies the action (list), the resource (DNS records), and the context (for a domain). It distinguishes from sibling tools like add_dns_record and update_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?
No guidance on when to use this tool versus alternatives such as get_domain or get_dns_records (which might be similar but no distinction is made). No prerequisites or when-not-to-use information provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific domain including uptime, SSL, health, and expiry
| Name | Required | Description | Default |
|---|---|---|---|
| domain_name | Yes | The domain name (e.g., "example.com") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description implies a read operation but does not disclose permissions, rate limits, or side effects. Could add 'read-only' 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?
Single sentence, no fluff, efficiently communicates purpose and 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?
Adequate for a simple one-parameter tool with no output schema; covers key details. Could add preconditions like monitoring status.
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 100% coverage for the single parameter; description adds value by listing the returned fields (uptime, SSL, health, expiry), going beyond 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?
Clearly states it retrieves detailed information for a specific domain, listing uptime, SSL, health, expiry. Distinguishes from siblings like get_domain_health, get_ssl_status, get_uptime which focus on single aspects.
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?
Implicitly guides to use for a specific domain. No explicit when-not or alternatives, but the context is clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest health check results for a domain including scores and grade
| Name | Required | Description | Default |
|---|---|---|---|
| domain_name | Yes | The domain name (e.g., "example.com") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It notes the result includes 'latest' results and 'scores and grade', but omits details on data freshness, side effects (none expected), permissions, or rate limits. Adequate but not rich.
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 sentence front-loaded with the essential information. No unnecessary words, but it is slightly terse; could include a brief note about output format.
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 one-parameter tool without output schema, the description covers the input and basic output. However, it lacks differentiation from siblings like get_domain or get_uptime, and does not specify the output structure given no 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?
Schema coverage is 100% with a clear description for the only parameter 'domain_name'. The tool description does not add any additional meaning beyond what the schema already provides, meeting the baseline for high 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 action 'Get', the resource 'health check results', and specifies the scope 'for a domain' along with the content ('scores and grade'). It directly distinguishes from related tools like run_health_check which triggers a check.
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 like run_health_check or get_domain. The agent is left to infer the difference without any context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List incidents (downtime events) for a domain
| Name | Required | Description | Default |
|---|---|---|---|
| domain_name | Yes | The domain name (e.g., "example.com") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose whether the operation is read-only, if pagination exists, or any side effects. The term 'List' suggests a read operation, but no further behavioral details are given.
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 sentence, perfectly concise, and front-loaded with the key action and resource.
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 is simple with one parameter; description covers the basics. However, missing details like whether results are paginated, ordered, or limited, which would be helpful for a complete 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?
Only one parameter, 'domain_name', fully described in the schema. Description does not add any meaning beyond what the schema provides, so baseline of 3 applies.
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 verb 'List', resource 'incidents (downtime events)', and scope 'for a domain'. It differentiates from sibling tools like get_domain_health or get_uptime by focusing specifically on incidents.
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 get_domain_health. Usage is implied but not contrasted with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get SSL certificate status and details for a domain
| Name | Required | Description | Default |
|---|---|---|---|
| domain_name | Yes | The domain name (e.g., "example.com") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It only states it gets SSL status, but does not indicate read-only nature, required permissions, or any 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?
The description is a single concise sentence. It is efficient but could benefit from additional context without sacrificing brevity.
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 omits details about what certificate information is returned (e.g., issuer, expiry, validity). Given the absence of an output schema and annotations, the description is insufficient for an agent to understand the full scope of the tool's output.
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% for the single parameter, and the description does not add extra meaning beyond what the schema already states. Baseline 3 applies.
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 'Get SSL certificate status and details for a domain' uses a specific verb ('Get') and resource ('SSL certificate status and details'), clearly stating the tool's function. It is distinguishable from sibling tools like get_dns_records or get_domain_health.
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 such as get_domain or get_domain_health. The description does not mention prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get uptime statistics for a domain
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Time period for uptime stats: "24h", "7d", or "30d" (default: "30d") | 30d |
| domain_name | Yes | The domain name (e.g., "example.com") |
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 only states 'Get uptime statistics', without disclosing whether the operation is read-only, latency, or any side effects. The behavior is assumed to be safe but unconfirmed.
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, coherent sentence with no unnecessary words. It is front-loaded with key information, achieving maximum 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?
The description lacks details about return values. Since there is no output schema, the description should clarify what statistics are returned (e.g., uptime percentage, history). This omission reduces completeness for a tool with simple parameters.
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%, with both parameters (domain_name and period) having clear descriptions in the schema. The tool description does not add new semantics beyond what the schema already provides, so the baseline score of 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 specifies the verb 'Get' and the resource 'uptime statistics for a domain', making the purpose clear. It distinguishes itself from sibling tools like get_domain_health and get_dashboard_stats by focusing on uptime metrics, though it does not explicitly call out the differentiation.
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 offers no guidance on when to use this tool versus alternatives such as get_domain_health or get_dashboard_stats. There is no mention of prerequisites or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all your domains with their current status, health grade, and monitoring state
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read-only operation by stating 'list', but does not disclose potential behaviors like pagination, sorting, or authentication requirements. The simplicity of the operation partly compensates.
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?
A single, front-loaded sentence that conveys the tool's purpose and output. Every word contributes meaning with no redundancy.
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 lack of annotations, output schema, and parameters, the description is fairly complete for a simple list tool. It specifies what is returned. However, it could mention if the list is exhaustive or if there are any limits, but overall 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?
There are no parameters, so baseline is 4. The description adds meaning beyond the schema by listing the fields included in the output (status, health grade, monitoring state), which helps the agent understand what to expect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'domains', and specifies the fields returned ('status, health grade, and monitoring state'). This clearly distinguishes it from siblings like get_domain (single domain) and get_domain_health (just health).
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 for getting an overview of all domains, but does not explicitly state when to use this tool vs alternatives like get_domain or get_dashboard_stats. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger an on-demand health check for a domain
| Name | Required | Description | Default |
|---|---|---|---|
| domain_name | Yes | The domain name (e.g., "example.com") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only says 'trigger an on-demand health check' without disclosing whether it is synchronous, its side effects, or permissions needed. This is insufficient for a mutation-like tool.
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 sentence, 8 words, no wasted words. Perfectly concise and front-loaded with the action.
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 one parameter, the description is minimal but adequate for a simple trigger. However, it lacks details on return value or asynchronous behavior.
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 already describes 'domain_name' with an example; description does not add further meaning. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'trigger' and the resource 'health check for a domain', distinguishing it from 'get_domain_health' which likely retrieves existing 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?
No guidance on when to use this tool versus alternatives like 'get_domain_health'. The phrase 'on-demand' implies manual use but no explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable or disable uptime monitoring for a domain
| Name | Required | Description | Default |
|---|---|---|---|
| enabled | Yes | Set to true to enable monitoring, false to disable | |
| domain_name | Yes | The domain name (e.g., "example.com") |
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 states the action (enable/disable) but does not disclose any behavioral traits such as whether disabling monitoring stops all checks, deletes data, or requires permissions. For a mutation tool, this is a significant 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 a single, concise sentence with no filler. It is front-loaded with the core purpose and uses efficient wording. 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?
The tool is simple with two parameters and no output schema. The description is mostly adequate, but it lacks context such as prerequisites (e.g., domain must be added), potential side effects, or how it relates to sibling tools like 'get_uptime'. A more complete description would mention these.
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 covers 100% of parameters with clear descriptions (e.g., 'Set to true to enable monitoring, false to disable'). The description adds no additional meaning beyond the schema, so the baseline score of 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 'Enable or disable uptime monitoring for a domain' clearly states the specific verb (toggle) and resource (uptime monitoring for a domain). It distinguishes from siblings like 'get_uptime' (read-only) and 'run_health_check' (ad-hoc check). However, it could be more specific about what 'uptime monitoring' entails, e.g., periodic checks vs. continuous monitoring.
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. For example, it does not explain when to toggle monitoring vs. using 'get_uptime' for status or 'run_health_check' for an immediate check. There is no mention of prerequisites (e.g., domain must exist) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing DNS record
| Name | Required | Description | Default |
|---|---|---|---|
| ttl | No | The new TTL in seconds (optional) | |
| value | No | The new record value (optional) | |
| priority | No | The new priority for MX records (optional) | |
| record_id | Yes | The ID of the DNS record to update | |
| domain_name | Yes | The 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 the full burden of behavioral disclosure. It only says 'update', with no details on permissions, side effects, failure modes, or rate limits. This is insufficient for a mutation operation.
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. It is front-loaded and efficient, though it could benefit from more detail. 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?
For a mutation tool with 5 parameters (2 required) and no output schema, the description is too minimal. It does not explain the effect on existing records, required permissions, or typical use cases, leaving the agent under-informed.
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 100% description coverage across its 5 parameters. The description adds no additional meaning beyond the schema, but since schema coverage is high, the baseline score of 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 verb 'update' and the resource 'DNS record', indicating modification of existing records. However, it does not distinguish from sibling tools like 'add_dns_record', which creates records, so it lacks differentiation.
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 such as 'add_dns_record' or 'acknowledge_dns_changes'. The description offers no context about prerequisites or typical scenarios.
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.
v1.0.2acknowledge_dns_changesadd_dns_recordadd_domainget_ai_analysisget_dashboard_statsget_dns_recordsget_domainget_domain_healthget_incidentsget_ssl_statusget_uptimelist_domainsrun_health_checktoggle_monitoringupdate_dns_recordScored across 15 tools
Each tool targets a clearly distinct aspect of domain management (monitoring, DNS, health, incidents, etc.). No two tools have overlapping purposes, making selection unambiguous.
All tools follow a consistent verb_noun pattern with lowercase underscores (e.g., add_dns_record, get_uptime). No mixing of conventions or vague verbs.
15 tools is well-scoped for a domain monitoring and management server, covering essential operations without bloat. Each tool serves a clear need.
Core domain and DNS management is covered, but missing delete operations for both domains (delete_domain) and DNS records (delete_dns_record) are notable gaps. Incidents lack resolution tools.
Uptime, SSL, DNS and domain monitoring you can talk to from Claude or any MCP client.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Custom domains for SaaS and AI agents: search, register, connect DNS, and issue HTTPS over MCP.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
