Putting your MCP server on your own domain takes one DNS record: pick a subdomain — mcp.yourcompany.com is the convention forming — point it where the SuperCognit dashboard tells you, and your server is served from your address, certificate handled. Nothing about the protocol changes. What changes is who the server appears to belong to, and for an MCP server that is worth more than it sounds.
The URL is most of the product surface
A traditional product has a homepage, screenshots, a listing somewhere. An MCP server has a URL. That URL is what gets pasted into a client configuration, what appears in your documentation, what one colleague forwards to another with the words 'add this'. There is no packaging around it. When the address is a platform subdomain, the platform is what people see; when it is your domain, the server reads as your infrastructure — because it is.
The OAuth moment
The first time someone connects, the server asks them to authenticate — SuperCognit servers implement OAuth 2.1 per the current MCP specification, issuer validation and CIMD registration included. An authentication prompt is a moment of judgement: people decide in about two seconds whether signing in feels right. A sign-in associated with your own domain matches the thing they believe they are connecting to. A sign-in from an address they have never heard of gets screenshotted and posted in the company chat with a question mark.
If you charge for it, this stops being cosmetic
SuperCognit lets you sell access to an MCP server per seat — Stripe subscriptions, invoices and payouts are built in, with SuperCognit as the merchant of record taking a platform fee. The moment money is involved, the address is part of the pitch. A 40-person accounting firm selling a tax-rules server to its clients is asking them to put an address in their tools and a subscription on their card; an address the firm visibly owns makes both requests easier to say yes to.
Addresses are load-bearing
Once your URL sits in fifty client configurations, it is infrastructure — every configuration that references it breaks if it moves. That argues for getting the address right before you distribute it widely, and right means one you control. The honest version of this argument cuts both ways: a domain you own is a domain you could point elsewhere. That the strongest case for a custom domain doubles as an exit option is, we think, how vendor relationships ought to work.
What it does not change
- Protocol behaviour: tools, knowledge and authentication work identically on either address, in Claude and any MCP client.
- Security: OAuth 2.1, issuer validation and per-workspace isolation are the same either way — a custom domain is identity, not armour.
- The build: same knowledge base, same tools, same chat agent published alongside.
Setting it up
Choose a boring hostname
mcp.yourcompany.com, or something equally dull. It will be typed into configuration files for years; cleverness ages badly there.
Add the DNS record
The dashboard shows exactly what to create at your DNS provider. Certificates are provisioned and renewed for you; there is nothing to babysit.
Publish, then treat it as permanent
The server answers on the new address. Put it in the docs, the onboarding guide, the sales one-pager — and never move it. Handing out the platform URL first and migrating later means updating every client config you no longer control.
A custom domain does not make a bad server good. It makes a good server look like what it is: a piece of your company's infrastructure that happens to speak MCP, at an address your customers will still trust — and still reach — years from now.