Which integrations are available for this server?

Allows managing GoDaddy DNS records, including listing, adding, replacing, and deleting records, as well as checking domain availability for domains in a GoDaddy account.

How do I use @appouse/godaddy-dns-mcp?

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., "@@appouse/godaddy-dns-mcp List all A records for 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.

@appouse/godaddy-dns-mcp

by appouse

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

@appouse/godaddy-dns-mcp

License: MIT Node MCP

A Model Context Protocol (MCP) server for managing GoDaddy DNS records. It lets Claude and other AI assistants list, add, replace and delete DNS records on any domain in your GoDaddy account — and check whether a domain is still available to register.

Written in TypeScript and published to npm, so it runs with a single npx command — nothing to clone, install or build.

Related MCP server: MCP Namecheap Server

Quick start

Requires Node.js 18.17 or newer.

npx -y @appouse/godaddy-dns-mcp --help

There is nothing to clone or build — npx fetches the package on demand. To install it permanently:

npm install -g @appouse/godaddy-dns-mcp
godaddy-dns-mcp --version

Configuration

1. Get GoDaddy API credentials

Generate a Production API key at developer.godaddy.com/keys — select Production, not OTE. OTE keys point at GoDaddy's test environment and will not see your real domains.

The API returns ACCESS_DENIED for keys on accounts with fewer than 10 domains or without an eligible plan; that is a GoDaddy account restriction, not a problem with this server.

2. Register the server with your MCP client

Claude Code — claude mcp add, or add this to the mcpServers section of ~/.claude.json:

"godaddy-dns": {
  "command": "npx",
  "args": ["-y", "@appouse/godaddy-dns-mcp"],
  "env": {
    "GODADDY_API_KEY": "your_api_key",
    "GODADDY_API_SECRET": "your_api_secret"
  }
}

Claude Desktop — same block, in claude_desktop_config.json:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "godaddy-dns": {
      "command": "npx",
      "args": ["-y", "@appouse/godaddy-dns-mcp"],
      "env": {
        "GODADDY_API_KEY": "your_api_key",
        "GODADDY_API_SECRET": "your_api_secret"
      }
    }
  }
}

Restart the client to pick up the change.

3. Any other MCP client

The server speaks MCP over stdio. Run it directly:

GODADDY_API_KEY=your_key GODADDY_API_SECRET=your_secret npx -y @appouse/godaddy-dns-mcp

Environment variables

Variable	Required	Description
`GODADDY_API_KEY`	yes	Production API key
`GODADDY_API_SECRET`	yes	Matching API secret

Credentials are read at request time, so the server starts even when they are missing — it logs a warning to stderr and every tool call reports the problem instead of failing silently.

Tools

Tool	Description
`list_dns_records`	List all records for a domain, optionally filtered by type and/or name
`add_dns_record`	Add a record without overwriting existing ones of the same type (`PATCH`)
`replace_dns_records`	Overwrite all records of a given type + name — use when exactly one record should exist (`PUT`). Supports `dry_run`
`delete_dns_record`	Delete all records matching a given type and name. Supports `dry_run`
`check_domain_availability`	Check whether a domain is available to register, with price and currency

Supported record types: A, AAAA, CNAME, MX, TXT, NS, SRV, CAA, and anything else the GoDaddy API accepts.

Parameters

Parameter	Tools	Default	Notes
`domain`	all	—	Root domain, e.g. `example.com`
`record_type`	all except availability	—	Case-insensitive; sent upper-cased
`name`	all except availability	—	Subdomain; `@` for the apex, `*` for a wildcard
`data`	add, replace	—	Record value (IP, hostname, text …)
`ttl`	add, replace	`3600`	Seconds
`priority`	add, replace	`0`	Only sent for `MX` and `SRV`
`dry_run`	replace, delete	`false`	Preview only — makes no API call
`check_type`	availability	`FAST`	`FAST` (cached) or `FULL` (authoritative)

Safety: the two destructive tools accept dry_run. With dry_run=true they describe exactly what would change and make no call to the GoDaddy API — useful for confirming a change before committing to it.

list_dns_records and check_domain_availability also return structured content, so clients that support it get typed results instead of a JSON blob in text.

Usage

Once registered, ask your assistant in plain language:

"Add a CNAME record for app.example.com pointing to cname.vercel-dns.com"

"List all A records for example.com"

"Show me what deleting the TXT record _vercel from example.com would do, but don't do it yet"

"Is myneatidea.dev still available?"

Programmatic use

The package also ships as a library if you want to embed the tools in your own MCP server or script:

import { createServer, GoDaddyClient, listDnsRecords } from "@appouse/godaddy-dns-mcp";

// A ready-to-connect MCP server
const server = createServer();

// Or just the API layer
const client = new GoDaddyClient({ apiKey: "…", apiSecret: "…" });
const records = await listDnsRecords(client, { domain: "example.com", record_type: "A" });

Security

Credentials never leave your machine. They are read from the environment and sent only to api.godaddy.com over HTTPS, and are never included in tool output or error messages.
Inputs are validated before a URL is built. domain, record_type and name all end up in the request path, so each is checked against a DNS-shaped pattern; slashes, query strings, percent escapes and .. traversal are rejected before any request is made.
Requests time out after 30 seconds instead of hanging a client session.
replace_dns_records and delete_dns_record are destructive — they affect every record matching the type and name. Prefer dry_run=true first, and remember that most MCP clients let you require approval per tool.
Never commit API credentials. Put them in your MCP client config or a local .env that is git-ignored.

Development

git clone https://github.com/appouse/godaddy-dns-mcp
cd godaddy-dns-mcp
npm install

npm run typecheck   # tsc --noEmit
npm test            # vitest — all HTTP traffic is stubbed
npm run build       # emit dist/
npm run dev         # run from source with tsx

Tests cover the API layer, the input validation, the MCP protocol surface (via an in-memory transport) and the built CLI as a real subprocess over stdio. No test ever contacts GoDaddy.

Inspect the server interactively:

npm run build
npx @modelcontextprotocol/inspector node dist/cli.js

License

MIT — see LICENSE.

Available Tools

5 tools

add_dns_recordAdd DNS recordA

Add a DNS record without overwriting existing records of the same type (PATCH). Use replace_dns_records instead when exactly one record should exist.

ParametersJSON Schema

Name	Required	Description
`ttl`	No	Time-to-live in seconds (default 3600)
`data`	Yes	Record value — IP address, hostname, text, ...
`name`	Yes	Record name/subdomain — use "@" for the apex/root record
`domain`	Yes	The root domain, e.g. "example.com"
`priority`	No	Priority for MX/SRV records (ignored for other types)
`record_type`	Yes	DNS record type: A, AAAA, CNAME, MX, TXT, NS, SRV, CAA, ...

TDQS

A4.4/5.0

Behavior4/5

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

The description adds behavioral nuance by explaining the PATCH method and the non-overwriting property, which goes beyond what the annotations convey (readOnlyHint=false, idempotentHint=false). It does not describe failure modes or response shape, but the annotations already cover the low-risk safety profile, and there is no contradiction.

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

Conciseness5/5

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

Two sentences with zero fluff. The first sentence states the primary action and its key behavioral constraint; the second identifies the alternative. Information density is high with no redundant phrasing.

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 has 6 parameters, all documented, and a clear description with sibling differentiation, it is almost complete. No output schema is present, but the description explains the semantic intent, and annotations cover mutation flags. A slight gap is the lack of expected return value or error conditions, but these are not essential for a straightforward create-like operation.

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 schema provides full coverage of all 6 parameters with individual descriptions, so the description need not repeat them. The description adds no parameter-specific detail, but the schema already fully documents fields like domain, record_type, data, ttl, and priority.

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 ('Add a DNS record') and differentiates it from the sibling tool by specifying 'without overwriting existing records of the same type (PATCH)'. It also names the alternative tool to imply the intended usage scope.

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

Usage Guidelines5/5

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

Explicit guidance is provided: use this tool to add a record while preserving existing ones, and use 'replace_dns_records instead when exactly one record should exist'. This gives the agent a direct decision rule between the two tools.

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

check_domain_availabilityCheck domain availabilityA

Read-only

Check whether a domain is available to register. Returns availability, price (in micro-units of the returned currency) and whether the answer is definitive.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	The domain to check, e.g. "example.com"
`check_type`	No	"FAST" (cached, quicker) or "FULL" (authoritative)	FAST

Output Schema

ParametersJSON Schema

Name	Required	Description
`availability`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

The description adds valuable behavioral context beyond the annotations: it mentions the return of price in micro-units of the returned currency and explicitly notes that the answer may not be definitive, which relates to the FAST vs FULL distinction. The readOnlyHint and openWorldHint annotations are consistent and complemented by this added nuance.

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, focused sentence that front-loads the core purpose and appends essential return-value details. It is concise with no filler, earning a high score for efficiency.

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

Completeness5/5

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

Given the simple tool scope, presence of an output schema, and annotations covering safety and open-world behavior, the description provides sufficient information: what it does, what it returns, and key unit caveats. No critical gaps for an agent to invoke it correctly.

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 already provides full parameter descriptions for both 'domain' and 'check_type' (including the FAST/FULL enum values). The description does not add new parameter-level semantics beyond what the schema offers, so it meets the baseline but does not exceed it.

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 ('Check whether') and identifies the resource ('a domain is available to register'), clearly distinguishing it from sibling DNS management tools. It states the primary function in a single, unambiguous sentence.

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 purpose makes the primary use case obvious, but the description provides no explicit guidance on when to choose this tool over alternatives or when to prefer FAST vs FULL. The schema describes the check_type options, but the description itself does not elaborate on usage context.

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

delete_dns_recordDelete DNS recordsA

DestructiveIdempotent

Delete ALL DNS records of a given type and name for a domain. Pass dry_run=true to preview the deletion without applying it.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Record name/subdomain to delete — use "@" for apex/root
`domain`	Yes	The root domain, e.g. "example.com"
`dry_run`	No	When true, make NO call to the GoDaddy API — just describe the change that would be made
`record_type`	Yes	DNS record type: A, AAAA, CNAME, MX, TXT, NS, SRV, CAA, ...

TDQS

A4.2/5.0

Behavior4/5

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

The description goes beyond annotations by emphasizing the 'ALL' scope of deletion and introducing the dry_run preview mechanism. This complements the destructiveHint annotation by explaining exactly what will be destroyed and how to preview it.

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?

Two concise, front-loaded sentences clearly communicate the action, scope, and the dry_run option. No wasted words.

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?

The description is sufficient for a destructive, bulk-delete tool, covering the core behavior and safety preview. Complete schema and annotations (destructiveHint) round out the context, though it could mention reversibility or prerequisites.

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?

All parameters are fully described in the input schema (100% coverage), so the description does not need to repeat them. The baseline of 3 applies since the schema handles the heavy lifting.

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 that this tool deletes ALL DNS records of a given type and name for a domain, using specific verbs and scope. This distinguishes it from sibling tools like add_dns_record, replace_dns_records, and list_dns_records.

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

Usage Guidelines4/5

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

The description provides a clear usage context: when you need to remove all records of a type and name, with a dry_run preview option. It does not explicitly mention alternatives or when not to use it, but the context is clear enough to guide selection.

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

list_dns_recordsList DNS recordsA

Read-only

List DNS records for a domain. Optionally filter by record type, and by name as well (filtering by name requires a record type).

ParametersJSON Schema

Name	Required	Description
`name`	No	Optional filter — record name/subdomain (requires record_type)
`domain`	Yes	The root domain, e.g. "example.com"
`record_type`	No	Optional filter — A, AAAA, CNAME, MX, TXT, NS, SRV, CAA, ...

Output Schema

ParametersJSON Schema

Name	Required	Description
`records`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the description's added value lies in explaining the filtering behavior, especially the requirement that name filtering requires a record_type. This is useful behavioral context beyond the annotations.

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?

Two concise sentences deliver purpose and key constraint without wasted words. Front-loaded verb 'List' immediately conveys the action.

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

Completeness5/5

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

Given the tool's simplicity, the presence of an output schema, and annotations, the description is fully adequate. It covers the core operation, filters, and the coupling between parameters, leaving no significant gaps.

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

Parameters4/5

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

Schema covers all parameters with descriptions, so baseline is 3. The description adds the semantic constraint that 'name' filtering requires 'record_type', which is not fully explicit in the schema alone. This enriches understanding of how parameters interact.

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 tool's action ('List DNS records') and its scope ('for a domain'), with optional filters. It distinguishes from sibling tools that add, replace, delete, or check availability, because none of those perform listing.

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

Usage Guidelines4/5

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

The description makes evident this is a read-only listing tool, and the sibling set clarifies alternatives (mutations and availability check). It doesn't explicitly state 'use this instead of X', but the context is clear enough.

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

replace_dns_recordsReplace DNS recordsA

DestructiveIdempotent

Replace ALL DNS records of a given type+name (PUT) — this overwrites any existing records that match. Use it when exactly one record should exist and duplicates must be removed. Pass dry_run=true to preview the change.

ParametersJSON Schema

Name	Required	Description
`ttl`	No	Time-to-live in seconds (default 3600)
`data`	Yes	New record value
`name`	Yes	Record name/subdomain — use "@" for the apex/root record
`domain`	Yes	The root domain, e.g. "example.com"
`dry_run`	No	When true, make NO call to the GoDaddy API — just describe the change that would be made
`priority`	No	Priority for MX/SRV records (ignored for other types)
`record_type`	Yes	DNS record type: A, AAAA, CNAME, MX, TXT, NS, SRV, CAA, ...

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already indicate destructiveHint=true and idempotentHint=true, and the description confirms overwriting. It adds value by clarifying that ALL matching records are replaced and by highlighting the dry_run=true preview option, providing context beyond the annotations.

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 two sentences, front-loaded with the core action and overwrite warning, then the use case and dry_run note. Every word earns its place with zero fluff.

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 7-parameter schema and absence of an output schema, the description adequately covers the tool's purpose, destructive nature, use case, and preview option. It could mention response/error behavior, but annotations and schema fill most gaps, making it sufficiently complete for safe invocation.

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 all parameters already have clear meanings. The description adds no significant parameter semantics beyond what the schema provides; it only mentions type+name and dry_run, which are already covered.

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 tool replaces ALL DNS records of a given type+name, using the PUT method. This specific verb+resource+scope distinguishes it from siblings like add_dns_record or delete_dns_record.

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

Usage Guidelines4/5

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

It explicitly says 'Use it when exactly one record should exist and duplicates must be removed,' giving a clear when-to-use condition. However, it does not explicitly name alternative sibling tools or state when not to use it, so it falls short of a 5.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Aug 2, 2026
- First observedadd_dns_record
- First observedcheck_domain_availability
- First observeddelete_dns_record
- First observedlist_dns_records
- First observedreplace_dns_records

Install Server

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

TDQS

A4.4/5.0

Scored 2026-08-02 02:25 across 5 tools

Disambiguation5/5

Each DNS tool targets a distinct operation: list, add, replace, delete, and domain availability. No two tools overlap in purpose; add vs. replace are clearly differentiated by overwrite semantics and dry-run options.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case: list_dns_records, add_dns_record, replace_dns_records, delete_dns_record, check_domain_availability. There is no mixing of styles or vague verbs.

Tool Count5/5

Five tools is well-scoped for a DNS management server. The count covers the essential record operations plus a useful domain availability check without unnecessary bloat.

Completeness5/5

The tool set provides full CRUD coverage for DNS records: list (read), add (create), replace (update/overwrite), and delete. The dry-run options and record-type filters round out the surface, and the availability check addresses a common adjacent need.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

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
mcp
ai.customdomain
Custom domains for SaaS and AI agents: search, register, connect DNS, and issue HTTPS over MCP.
Networking & Infrastructure Developer Tools Cloud Platforms
2
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2

Related MCP Servers

Google Cloud DNS API MCP
Cloud Platforms Developer Tools
ag2-mcp-servers
F
license
Not graded
quality
D
maintenance
Auto-generated MCP server that enables interaction with Google's Cloud DNS API for managing DNS zones and records through natural language.
Updated a year ago (2025-07-16 13:55 UTC)
-
MCP Namecheap Server
App Automation Developer Tools
johnsorrentino
A
license
B
quality
D
maintenance
Provides integration with the Namecheap API for domain management operations, including domain listing, availability checks, and nameserver configuration. It allows users to interact with their Namecheap account through natural language commands in MCP-compatible clients.
Updated a year ago (2025-06-19 18:20 UTC)
3
32
20
MIT
Openprovider MCP Serverofficial
Networking & Infrastructure E-commerce & Retail
openprovider
A
license
B
quality
C
maintenance
MCP server for Openprovider.com that enables domain management actions such as checking availability, registering domains, listing domains, and managing contacts through natural language.
Updated 8 days ago (2026-09-03 05:55 UTC)
10
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
32
MIT

@appouse/godaddy-dns-mcp

Table of Contents

Quick start

Configuration

1. Get GoDaddy API credentials

2. Register the server with your MCP client

3. Any other MCP client

Environment variables

Tools

Parameters

Usage

Programmatic use

Security

Development

License

Available Tools

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Openprovider MCP Serverofficial