MCP connector
Manage your DNS by talking to Claude.
Subdy ships an MCP (Model Context Protocol) server so Claude can manage your subdomains for you. It uses OAuth 2.1 — you approve access once in the browser, and the issued token shows up on API & MCP where you can revoke it any time. Available on every plan, including Free.
Server URL: https://mcp.subdy.io/mcp (Streamable HTTP).
Add to Claude
- In Claude (web or desktop) open Settings → Connectors → Add custom
connector and paste
https://mcp.subdy.io/mcp. - Claude opens the Subdy consent screen — sign in if needed and press Approve.
- Done. Ask Claude something like "list my subdy subdomains" to confirm the connection.
For MCP Inspector or other clients, the server advertises its
authorization server via WWW-Authenticate and RFC 9728 resource
metadata — the OAuth flow (Dynamic Client Registration + PKCE) is fully
automatic.
Tools
| Tool | Parameters | Does |
|---|---|---|
list_subdomains | — | your names with status and records |
check_availability | name | is a name free to register |
create_subdomain | name, ip?, issue_wildcard_certificate? | register a name, optionally point + order TLS |
set_record | subdomain, type, name, value, ttl? | create/replace a DNS record (upsert) |
update_ip | subdomain, ip | quick dyndns-style repoint |
delete_record | subdomain, type, name, confirm | destructive — refuses without confirm: true |
get_certificate | subdomain | TLS status and expiry |
get_usage | days? | DNS query volume, top names |
Ready-to-paste prompts
Copy one of these into Claude (or Claude Code with the connector added) and it will do the whole job with the Subdy tools — no manual steps.
Publish an app end-to-end (the big one — Claude Code figures out your server, creates the subdomain, wires the proxy and TLS, then verifies):
Publish this project at https://myapp.subdy.io end-to-end using the Subdy
MCP tools.
1. Work out how this project is deployed and find the public IPv4 of the
server that actually listens on 80/443 (check deploy configs, run
`curl ifconfig.me` on the server). If it is not deployed anywhere yet,
stop and tell me — do not guess an IP.
2. With the Subdy tools: check_availability for "myapp"; create_subdomain
with that IP and issue_wildcard_certificate: true; confirm it is active
via list_subdomains; wait for get_certificate to report "valid".
3. Configure my web server / reverse proxy to answer on myapp.subdy.io.
Prefer letting the proxy obtain its own certificate via HTTP-01
(Caddy/certbot) once DNS resolves; the Subdy wildcard cert is the
fallback (downloadable from the dashboard).
4. Verify for real: dig resolves to the server, `curl -I https://myapp.subdy.io`
returns 200 with a valid certificate, and the actual app renders.
5. Report what you changed, and never touch my other Subdy subdomains.Quick one-liners:
Is "myapp" free on Subdy? If yes, register it and point it at 203.0.113.7.My home IP changed — update myapp.subdy.io to my current public IP.Add a TXT record "v=spf1 -all" to myapp and show me all its records after.Phrases that work
- "Is
blogfree on subdy? If yes, register it and point it at 203.0.113.7." - "Point myapp at my new server 198.51.100.20."
- "Add a TXT record
v=spf1 -allto myapp." - "How many DNS queries did my names get this week?"
- "Delete the www CNAME on myapp." — Claude will ask you to confirm:
deletions never run without an explicit
confirm.