Which integrations are available for this server?

Enables n8n workflows to automate domain management tasks such as checking domain availability, listing contacts, and registering domains via the Openprovider MCP server.

How do I use Openprovider MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Openprovider MCP Server check if example.com is available" 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.

Openprovider MCP Server

Official

by openprovider

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Openprovider MCP Server

Official Model Context Protocol server for the Openprovider API.

Maintained by Openprovider.

Connect Claude, or any Model Context Protocol client, to your Openprovider account to manage domains, DNS, SSL certificates, contacts, email and licences in natural language.

What you get

95 tools across the Openprovider API:

Area	Examples
Domains	`check_domain`, `register_domain`, `renew_domain`, `transfer_domain`, `update_domain`, `delete_domain`, `restore_domain`, `suggest_domain`
Transfers & auth codes	`get_domain_authcode`, `reset_domain_authcode`, `approve_domain_transfer`, `send_foa1_domain_transfer`
DNS	`list_dns_zones`, `create_dns_zone`, `update_dns_zone`, `list_dns_zone_records`, DNS templates, nameservers, NS groups
SSL	`list_ssl_products`, `create_ssl_order`, `renew_ssl_order`, `reissue_ssl_order`, `create_csr`, `decode_csr`, approver emails
Contacts & customers	`list_contacts`, `create_contact`, `update_contact`, `list_customers`, `create_customer`
Email	Email templates, email verification, SpamExperts domains
DMARC	`list_dmarc_subscriptions`, `create_dmarc`, `get_dmarc`, `retry_dmarc`
Licences	Plesk licences, licence prices and items
Pricing & TLDs	`get_domain_price`, `list_tlds`, `get_tld`

A full reference with input schemas is in docs/tools.md.

Related MCP server: realtime-register-mcp

Quick start

Requires Node.js 20+ and an Openprovider account with API access enabled.

npx openprovider-mcp

Claude Desktop / Claude Code

Add to your MCP client configuration:

{
  "mcpServers": {
    "openprovider": {
      "command": "npx",
      "args": ["-y", "openprovider-mcp"],
      "env": {
        "OPENPROVIDER_USERNAME": "your-openprovider-username",
        "OPENPROVIDER_PASSWORD": "your-openprovider-password"
      }
    }
  }
}

For Claude Code:

claude mcp add openprovider npx -y openprovider-mcp \
  -e OPENPROVIDER_USERNAME=your-username \
  -e OPENPROVIDER_PASSWORD=your-password

From source

git clone https://github.com/openprovider/openprovider-mcp.git
cd openprovider-mcp
npm install
npm run build
OPENPROVIDER_USERNAME=... OPENPROVIDER_PASSWORD=... npm start

Configuration

Variable	Required	Description
`OPENPROVIDER_USERNAME`	yes	Openprovider account username
`OPENPROVIDER_PASSWORD`	yes	That account's password
`OPENPROVIDER_BASE_URL`	no	Override the API base URL (defaults to the production API)

Credentials are read from the environment, used only to obtain an API token from Openprovider, and are never written to disk or logged.

Do not enable two-factor authentication on a user used for API access. Openprovider rejects 2FA logins over the API — the server reports this as Openprovider 10006: Two factor authenticator required. Use a dedicated API user without 2FA.

Hosted option

Openprovider also runs a hosted, multi-tenant deployment at https://mcp.openprovider.com with a dashboard, API keys, team management, approval policies and an audit log. See docs/MCP-SERVER.md for client setup against the hosted endpoint. This repository is the standalone, self-hosted server.

Safety

Many tools perform real, billable and often irreversible operations — registering, renewing, transferring and deleting domains, and ordering certificates and licences. This standalone build executes them directly with no approval step. Point it at an account you intend to change, and prefer a test account while you are exploring.

Documentation

Tool reference — every tool and its input schema
Hosted endpoint setup guide — for mcp.openprovider.com, not this standalone server
Troubleshooting
Examples
Openprovider API documentation

Security

Please report vulnerabilities privately — see SECURITY.md. Do not open a public issue for a security problem.

Contributing

See CONTRIBUTING.md.

License

MIT — see LICENSE.

Available Tools

10 tools

check_domainB

Check domain availability

ParametersJSON Schema

Name	Required	Description	Default
`domains`	Yes	List of domains to check
`with_price`	No	Include price information

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description bears full responsibility for behavioral disclosure. It states 'Check domain availability' but does not elaborate on what availability means, how it is determined, or any side effects (e.g., read-only). Critical details like authentication or rate limits are omitted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, making it concise and front-loaded. However, it is under-specified; while brevity is valued, it sacrifices necessary context that could be added without excessive length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

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 should provide more context about the return value and behavior. It lacks information on response format, error handling, or any prerequisites. The schema is rich but the description alone is insufficient for an AI agent to fully understand the tool's output and side effects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of parameters with clear descriptions, so baseline is 3. The description adds no extra meaning beyond the schema, which is adequate but not improved. for.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Check domain availability' clearly states the verb (check) and resource (domain availability), and effectively distinguishes this tool from siblings like get_domain and register_domain. It is specific and actionable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidance is provided. The description does not specify when to use this tool versus alternatives such as get_domain or register_domain. It lacks explicit context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_contactC

Create a new contact

ParametersJSON Schema

Name	Required	Description
`additional_data`	No	Additional contact data
`address`	Yes	Contact address
`api_access_enabled`	No	Enable API access for this contact
`comments`	No	Comments about the contact
`company_name`	No	Company name
`email`	No	Contact email address
`inn`	No	INN (Individual Taxpayer Number)
`is_active`	No	Whether the contact is active
`kpp`	No	KPP (Tax Registration Reason Code)
`locale`	No	Contact locale
`name`	Yes	Contact name information
`password`	No	Contact password
`phone`	Yes	Contact phone information
`role`	No	Contact role (admin, tech, billing, owner)
`type`	No	Contact type
`gender`	No	Gender (M/F)
`username`	No	Username for the contact
`vat`	No	VAT number

TDQS

C2.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavioral traits such as side effects, authentication requirements, or data validation. The description 'Create a new contact' offers no behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that merely restates the tool name. While concise, it is under-specified and does not add unique value beyond the name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of 18 parameters, nested objects, and required fields, the description is completely inadequate. It provides no context about contact creation, data constraints, or return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 tool description adds no additional meaning beyond the schema, but the schema itself is descriptive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create a new contact' is clear but does not differentiate from sibling tools like update_contact or delete_contact. It is a slight improvement over a tautology by adding 'new' but lacks distinguishing details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 siblings, such as whether to use it for a new contact or update_contact for an existing one.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_contactC

Delete a contact by ID

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Contact ID to delete

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It only states the operation without mentioning permanence, error handling, or side effects. A deletion tool should clarify consequences and idempotency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, concise and front-loaded. It is not verbose, but slightly more context (e.g., 'permanently') could be added without harming conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity (1 param, no output schema, no annotations), the description is incomplete. It does not cover return values, error scenarios, or whether deletion is reversible. A more complete description would mention success/failure behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of parameters with a description ('Contact ID to delete'). The description adds no new meaning beyond 'by ID', but the schema already provides sufficient info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Delete') and the resource ('a contact') and how to identify it ('by ID'). It is distinct from sibling tools like create_contact, get_contact, or update_contact.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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, prerequisites (e.g., contact must exist), or when not to use it. The description only states what it does, not the context of use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_contactA

Get contact details by ID

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Contact ID

TDQS

A3.8/5.0

Behavior3/5

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 describes the action as 'get', suggesting a read-only operation with no side effects. However, it does not disclose what happens on missing ID, permissions needed, or any rate limits. The description is adequate but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no extraneous words. Every word earns its place, making it highly concise and structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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 nested objects, no output schema), the description provides sufficient context for an agent to understand the purpose. It is complete enough for a basic lookup tool, though it could hint at return structure since there is no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with one parameter 'id' described as 'Contact ID'. The description adds no new information beyond reinforcing that the ID is used to fetch details. With full schema coverage, a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and resource ('contact details'), and specifies the method ('by ID'). It clearly distinguishes from siblings like 'list_contacts' which lists multiple, and 'create_contact' which creates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when you have a specific ID and need details, but does not explicitly state when to use this tool versus alternatives like 'list_contacts' or 'update_contact'. No exclusions or when-not-to-use guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_domainC

Get domain details

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Domain ID

TDQS

C2.6/5.0

Behavior2/5

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 only says 'Get domain details' without mentioning read-only, permissions, rate limits, or side effects. The tool could be a read operation, but not explicitly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (three words) but lacks sufficient detail to earn its place. It does not explain what 'details' means or what the tool returns. This is under-specification, not effective conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should clarify the return value or structure. It omits this entirely. Given the tool's simplicity (one required param) and lack of annotations, the description is incomplete and inadequate for an agent to understand its full behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with param 'id' described as 'Domain ID'. The description adds no further meaning beyond what the schema already provides. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and resource ('domain details'), clearly indicating the action. However, it does not differentiate from sibling tools like check_domain, which might have similar purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use get_domain versus alternatives (e.g., list_domains, check_domain). There is no context for when it is appropriate to invoke this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_contactsC

List contacts in your Openprovider account

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of contacts to return
`offset`	No	Offset for pagination

TDQS

C2.9/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden for behavioral disclosure. It only states 'list contacts' with no mention of read-only nature, pagination behavior, rate limits, or any effects. This is severely lacking.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded, no wasted words. However, it is under-specified for a list tool with pagination.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity (2 params, no nesting, no output schema), the description should clarify what data is returned or how to use pagination. It lacks completeness, especially with many sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both limit and offset well-described. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (list) and the resource (contacts in Openprovider account). It distinguishes from sibling tools like create_contact, delete_contact, and get_contact.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 mention of filtering, searching, or when to use get_contact for a specific contact.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_domainsB

List domains in your Openprovider account

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of domains to return
`offset`	No	Offset for pagination
`status`	No	Filter by domain status

TDQS

B3/5.0

Behavior2/5

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 only states the basic function with no details on authentication, rate limits, return format, or pagination behavior. For a data retrieval tool, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, making it concise. However, it lacks structure (e.g., separate sections for purpose, usage) and does not front-load the most critical information. It is acceptable but not exemplary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 parameters, no output schema, and no annotations, the description should provide more context about pagination, result format, or typical use. It is incomplete for a list operation that likely returns a list of domains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for all three parameters (limit, offset, status). The description adds no additional information beyond the schema, so it meets the baseline expectation but does not enhance understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List') and the resource ('domains'), and the context of 'in your Openprovider account' specifies scope. It is distinct from sibling tools like 'get_domain' (single domain) and 'register_domain' (create).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as 'check_domain' for availability or 'get_domain' for details. No mention of 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.

loginB

Authenticate with Openprovider and get a token

ParametersJSON Schema

Name	Required	Description	Default
`username`	No	Openprovider username
`password`	No	Openprovider password

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only states 'authenticate' and 'get a token' without disclosing session behavior, token expiration, or side effects like credential validation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence that directly states the tool's purpose. No unnecessary words or repetition. Earns its place efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and annotations, the description should explain how the token is returned and its usage context. It omits critical details for a login tool, making it incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both parameters described in the schema. The description adds no extra meaning beyond what the schema already provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Authenticate' and the resource 'Openprovider', plus the outcome 'get a token'. It effectively distinguishes from sibling tools like check_domain or list_contacts, which handle domain/contact operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool, such as requiring it before other API calls or that it returns a token that must be reused. No contrast with siblings provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

register_domainC

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes
`period`	Yes	Registration period in years
`owner_handle`	Yes	Owner contact handle
`admin_handle`	No	Administrative contact handle
`tech_handle`	No	Technical contact handle
`billing_handle`	No	Billing contact handle
`name_servers`	No	List of nameservers
`ns_group`	No	Nameserver group
`use_domicile`	No	Use domicile service
`is_private_whois_enabled`	No	Enable private WHOIS
`is_dnssec_enabled`	No	Enable DNSSEC
`autorenew`	No	Auto-renewal setting (on, off, default)	default

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility for behavioral transparency. It only states 'Register a new domain' without disclosing whether the operation creates a resource, requires authentication, has side effects, or any rate limits. The bare minimum is conveyed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (one sentence) but lacks substance. It under-specifies the tool's behavior and fails to provide necessary context, making it more under-specification than effective conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (12 parameters, nested objects, no output schema, no annotations), the description is inadequate. It does not explain return values, prerequisites, or any post-conditions. A more detailed description is needed for an AI agent to use this tool confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is high (92%), and the input schema already describes most parameters adequately. The description adds no additional meaning or constraints beyond the schema. Baseline 3 is appropriate as the description does not compensate for any low coverage areas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Register') and the resource ('a new domain'), making the purpose apparent. However, it does not explicitly distinguish from siblings like 'check_domain' or 'update_contact', though the verb 'register' is distinct enough.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context (when you want to register a domain) but provides no explicit guidance on when to use this tool versus alternatives like 'check_domain' for availability checks. 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.

update_contactC

Update an existing contact

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Contact ID to update
`additional_data`	No	Additional contact data
`address`	No	Contact address
`api_access_enabled`	No	Enable API access for this contact
`comments`	No	Comments about the contact
`company_name`	No	Company name
`email`	No	Contact email address
`inn`	No	INN (Individual Taxpayer Number)
`is_active`	No	Whether the contact is active
`kpp`	No	KPP (Tax Registration Reason Code)
`locale`	No	Contact locale
`name`	No	Contact name information
`password`	No	Contact password
`phone`	No	Contact phone information
`role`	No	Contact role (admin, tech, billing, owner)
`type`	No	Contact type
`gender`	No	Gender (M/F)
`username`	No	Username for the contact
`vat`	No	VAT number

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description only says 'Update', implying mutation, but fails to disclose behavioral traits like partial update behavior, idempotency, or required permissions. No annotations are provided to compensate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise (6 words), but it lacks structure and does not front-load key information. It could benefit from more detail without sacrificing brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (19 parameters, nested objects, no output schema), the description is insufficient. It does not explain return values, error handling, or field relationships.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are already well-documented. The tool description adds no additional meaning beyond the schema, resulting in a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Update an existing contact' clearly states the action (update) and resource (contact). It is specific but does not differentiate from sibling tools like create_contact or delete_contact.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 create_contact or delete_contact. No prerequisites or exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: domain availability checking, authentication, and full CRUD for contacts and domains. There is no overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with lowercase underscores (e.g., check_domain, create_contact), making them predictable and easy to understand.

Tool Count5/5

With 10 tools, the server is well-scoped for a domain registrar, covering authentication, domain operations, and contact management without unnecessary bloat.

Completeness4/5

The tool set covers basic domain lifecycle (check, register, get, list) and full contact CRUD. However, it lacks domain renewal, transfer, or DNS management, leaving some common tasks unsupported.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

dnsimple A
io.usefulapi
MCP server for DNSimple — domains, DNS zone records, availability, pricing and contacts.
Networking & Infrastructure Cloud Platforms
122
Domains A
io.github.pipeworx-io
Domains MCP — domain registration lookup + availability search over live
Search Web Scraping Open Data
362
omnidim-mcp-server
io.github.Omnidim
Official MCP server for OmniDimension. Drive voice agents, dispatch calls, and run bulk campaigns.
Communication Speech Processing
27
Speechtotext Mcp
io.github.varvararatta
MCP server for Speech-to-Text
Speech Processing AI & Machine Learning
2

Related MCP Servers

dynadot-mcp
App Automation E-commerce & Retail
mikusnuz
A
license
B
quality
A
maintenance
MCP server for Dynadot domain registrar API3 — manage domains, DNS, contacts, transfers & more
Updated a month ago (2026-08-06 08:33 UTC)
67
86
1
MIT
realtime-register-mcp
Networking & Infrastructure API Testing
zenjoy
A
license
Not graded
quality
D
maintenance
An MCP server for domain management, enabling domain availability checks, bulk domain checks, and API connectivity testing through the RealtimeRegister API.
Updated 8 months ago (2025-12-28 10:27 UTC)
19
1
MIT
mcp-namecheap
E-commerce & Retail Networking & Infrastructure
fantomdancer
A
license
A
quality
D
maintenance
Comprehensive MCP server for the Namecheap API, enabling domain management, DNS record control, nameserver settings, and domain registration from any MCP client.
Updated 7 months ago (2026-02-07 18:15 UTC)
10
45
MIT
@hasna/domains
Cloud Platforms Networking & Infrastructure
hasna
A
license
Not graded
quality
B
maintenance
MCP server for domain portfolio management, registrar operations, marketplace, and DNS management via CLI or AI agents.
Updated 23 days ago (2026-08-11 15:39 UTC)
1,085
1
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/openprovider/openprovider-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server