Skip to main content

Publishing & Claiming MCP Servers

The MCPBundles directory at https://www.mcpbundles.com/ is open. Any signed-in MCPBundles account can publish a remote MCP server URL, and the verified maintainer can claim the listing. This page covers both flows.

For a step-by-step walkthrough with the full publish, claim, and scoring sequence, read How to Publish an MCP Server to MCPBundles.

The two flows are separated on purpose:

  • Publishing creates the listing. It does not grant edit or scoring rights. Anyone can publish a reachable MCP server URL.
  • Claiming proves you control the server. It grants the right to edit listing metadata (name, description, category, logo, website, contact email, skill content) and to run quality scoring on the listing.

If publishing granted maintenance rights, anyone could publish someone else's server URL and inherit it. The claim flow closes that gap, including for self-publishers.

Before You Publish​

You will need:

  • A reachable MCP server URL. It must use HTTPS, be reachable on the public internet, and respond to tools/list. Streamable HTTP and SSE transports are both supported. Local addresses (localhost, 127.0.0.1, private network ranges) are rejected.
  • A name and short description. The name becomes the listing title, and the description appears on the directory card.
  • Optional details. A logo URL, a website URL, and a contact email. You can change these later once you have claimed the listing.
  • An MCPBundles account. Any signed-in account can publish from the website.
  • A contact file on your server. You need one to claim the listing. Step 1 in the guide above, and the section below, explain how to add it.
  • (For OAuth servers, optional) A token. Without one, the listing is created with no tools. Tools appear after a maintainer claims the listing and completes the sign-in. Publishing from the website does not require a token.

For MCP client OAuth (DCR, PKCE, federation) on published servers, see MCP Connect Auth.

MCPBundles MCP client authentication​

When you publish a remote MCP server that needs OAuth for MCP clients (Claude, Cursor, ChatGPT, and other certified hosts), you can choose how authentication is hosted:

OptionYou operateMCPBundles operatesBest when
Bring your own OAuthFull OAuth stack on your originDirectory listing + optional bundle proxyYou already run OAuth 2.1 with DCR
MCPBundles MCP client authenticationSign-in + federation callback onlyTenant authorization server, DCR, PKCE, bundle protected-resourceYou want publish-ready OAuth without building an authorization server

Enable MCPBundles handles MCP client authentication at publish time, or edit an existing listing. MCPBundles provisions a tenant authorization server per listing slug.

Two connect URLs, one tenant AS​

PathVendor MCP codeClient connects to
Bundle URL (fastest)Federation only, no pip or npm package on your MCP serverhttps://mcp.mcpbundles.com/bundle/{slug}/
Vendor originInstall mcpbundles-mcp-connect or @mcpbundles/mcp-connect-auth on your serverYour public MCP base URL

Both paths share the same tenant AS. Path B is the quickest way to get traffic from the directory: publish, configure federation, and point clients at the bundle URL.

Federation setup (required for both paths)​

  1. In the maintainer Connect Auth panel, set your federation sign-in URL (an HTTPS page where users sign in).
  2. Copy the federation secret once when it is shown. Store it server-side in your app.
  3. After the user signs in, call POST …/v1/federation/complete from your backend (see the integration doc).

Connect readiness​

The maintainer dashboard runs the same probe ladder as the CLI:

mcpbundles connect doctor --listing {slug} --env staging --surface bundle

Green readiness means public-config, JWKS, tenant AS metadata, and bundle protected-resource metadata are all live.

Optional add-ons​

  • Origin client telemetry. Cohort analytics when clients hit your origin directly (Path A). Bundle URL connections appear in Connections with no vendor code.
  • Claude and ChatGPT publishing assist. Connector URLs and registry export from listing metadata, when enabled on your listing.

Full reference: MCP Connect Auth for published MCP servers.

Publishing a Server​

Publishing is done on the website. There is no command-line publish step for normal users.

  1. Sign in to MCPBundles. Open the workspace menu and choose Publish a server, or go straight to https://www.mcpbundles.com/mcp-analysis?intent=publish.
  2. Paste your MCP server URL into the MCP Server URL box and click Run. MCPBundles analyzes the server and lists its tools.
  3. Click Continue to publish. To add the server to your workspace first, use Add to workspace. Then open the server's page and choose Publish to public directory.
  4. Complete the short ownership check. Use a work email on the server's domain, or use the code flow: MCPBundles emails a 6-digit code to a contact from your /.well-known/ file, and you enter the code back in the page.
  5. When the check passes, the listing is live at https://www.mcpbundles.com/skills/<slug>.

Workspace vs public directory: adding a server to your workspace does not make it public. Workspace copies stay private to your account until you publish them to the public directory.

What happens after you publish​

The listing is public as soon as it is published. You can find it on the directory home page at https://www.mcpbundles.com/, or by searching with https://www.mcpbundles.com/?q=<name>.

Listing cards can show these labels:

  • Publisher MCP server: the listing is hosted by the publisher.
  • One-click sign-in: clients can sign in through the server without manual OAuth app setup.
  • No sign in: the service does not need an account connection to start using its tools.
  • Tools: N: the number of tools discovered on the server.
  • MCP App: the server ships an interactive UI.

If a listing for the same server URL already exists, the publish step stops and links to it. Claim that listing instead of publishing a duplicate.

Tools come from your server. A server that needs OAuth and was published without a token starts with an empty tool list. Tools appear after a maintainer claims the listing and a credential is bound and signed in.

What "unclaimed" means​

An unclaimed listing is fully visible in the directory, and agents can discover it. The only thing missing is editing rights: nobody can change the listing's details or run quality scoring on it. The listing page shows a Claim this listing button.

Nobody has to claim a listing for it to stay up. An unclaimed listing stays in the directory as a community submission, and platform admins can correct it.

The MCPBundles directory is one place to list a server. For the official MCP Registry, follow Publish an MCP server to the MCP Registry. It covers a different system with its own server.json file.

Claiming a Listing​

Claiming is an ownership proof. MCPBundles reads contact addresses from a /.well-known/ file your server publishes, sends a 6-digit code to one of those addresses, and you enter the code back on the website.

Step 1: Publish a well-known file on your server​

MCPBundles looks for two files at the origin of your MCP server URL. For https://api.example.com/mcp, it checks https://api.example.com/.well-known/.... Either file is enough.

This file is built for the claim flow. The smallest valid shape is:

{
  "maintainers": [
    { "email": "owner@example.com" },
    { "email": "ops@example.com", "name": "Ops Team" }
  ]
}

The name field is optional. List your preferred contact first. Within the same source, file order sets the order shown in the claim dialog.

Option B: /.well-known/security.txt (RFC 9116)​

If your server already publishes a security.txt for vulnerability reporting, the claim flow reuses it. Any Contact: line that is a mailto: address is accepted:

# https://example.com/.well-known/security.txt
Contact: mailto:security@example.com
Contact: mailto:owner@example.com
Contact: https://example.com/security
Expires: 2027-01-01T00:00:00.000Z

URL-form contacts are skipped because they cannot receive a code. Unsigned files are accepted.

If both files are present, addresses found in both are listed first in the claim dialog, then JSON-only addresses, then security.txt-only addresses.

Check that the file is publicly reachable before you publish. A 404 at that URL means the claim step has nothing to read.

Step 2: Email privacy rules​

  • Normalization for dedup. Addresses are lowercased, +tag aliases are stripped, and Gmail dot variations are collapsed. Several addresses that route to the same inbox cannot be used to bypass per-listing rate limits.
  • Masking for display. The claim dialog shows masked addresses such as s*******@e******.***. The full address is never shown on the page. You pick the address by recognizing its shape, and MCPBundles sends the code to the full address on the server side.

If none of the masked options matches your contacts, stop. Someone else may control that file.

Step 3: Run the claim flow​

From the public listing page (/skills/<slug>), click Claim this listing:

  • If you are not signed in, you sign in first and land on the server's page with the claim dialog open.
  • If you are signed in, the claim dialog opens on the server's page.

The dialog has three states:

  1. Eligibility check. MCPBundles fetches the well-known files and shows the masked candidate addresses. If none are found, it lists the URLs it tried.
  2. Choose an address and send the code. MCPBundles sends a 6-digit code that expires after 10 minutes to the address you select. Resending is rate-limited per listing.
  3. Enter the code. On a correct match, the listing is claimed, and the maintainer controls become available on the listing.

If the code expires or is wrong three times, the flow restarts at the send step.

What claiming grants​

A successful claim grants two rights on the listing:

  • Edit listing metadata. Name, description, category, website URL, logo URL, contact email, and skill content.
  • Run quality scoring. Re-run the quality check against the server's tools and skill content. The verdict appears on the public listing. For what the scorer measures, read Rating MCP Server Quality.

Claiming does not let you publish new versions (the listing always points at the live URL), suspend or unpublish the listing (platform admins only), or see credentials that other workspaces bound to the server.

After You Claim​

Claimed listings get a listing maintainer panel on the server's page in MCPBundles. From there you can:

  • Edit the public listing. Changes appear on the public page on the next page load.
  • Score the listing again. Re-run scoring after you change tools or skill content, so the listing shows the current verdict.
  • View the public page. Open /skills/<slug> to see the listing as visitors see it.

Connect your account​

For OAuth servers, the scorer needs a credential bound to the listing so it can read the live tool list. Complete the sign-in on the server's page once after claiming. Servers that need no sign-in can be scored straight away.

Hand off maintenance​

There is no transfer flow yet. To move a claim to a different maintainer, email hello@mcpbundles.com. A platform admin releases the claim, and the new maintainer runs the claim flow themselves.

Quality Scoring​

MCPBundles runs an LLM-as-judge rubric over each published server and shows the verdict on the public listing. It scores each tool (purpose clarity, parameter quality, disambiguation, density) and the skill content (domain context, workflow guidance, tool disambiguation, operational knowledge, additive value, conciseness).

The scorer also reads each tool's annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint).

A few rules affect the score most:

  • Skill content that tells users to get, paste, or configure credentials is automatically rated Bad. MCPBundles captures credentials and injects them on the server side.
  • A server needs a bound credential and discovered tools before it can be scored. Without them, the listing shows no score rather than a zero.
  • The public listing shows only the most recent run.

Only the maintainer sees the per-tool breakdown and the prioritized list of suggestions. Fix the top items, then run scoring again.

Archive and Republish​

Archiving hides a listing from the directory. The listing's data is kept, and republishing brings it back. Only platform admins can archive or republish a listing. To take a listing down or bring one back, email hello@mcpbundles.com with the listing URL.

Publish an MCP App Listing​

An MCP App is an interactive UI that your server ships alongside its tools. A listing for a server with an app gets an MCP App label and appears on the MCP Apps page. MCPBundles recognizes an app from either of these signals:

  • A resource whose mimeType is text/html;profile=mcp-app, returned by resources/list.
  • A tool with _meta.ui.resourceUri set to a ui:// URI, returned by tools/list.

Most servers use both. This resource serves the app:

{
  "uri": "ui://acme/dashboard.html",
  "name": "Acme Dashboard",
  "mimeType": "text/html;profile=mcp-app",
  "_meta": {
    "ui": {
      "csp": {
        "connectDomains": ["https://api.acme.com"],
        "resourceDomains": ["https://cdn.acme.com"]
      },
      "prefersBorder": true
    }
  }
}

This tool opens it. The underscore in _meta is the MCP wire format, and it is the most common thing people get wrong:

{
  "name": "get_sales_summary",
  "description": "Sales totals for a period",
  "_meta": {
    "ui": {
      "resourceUri": "ui://acme/dashboard.html"
    }
  }
}

A parameter named resourceUri does not count as an app. Hosts block origins that are not listed in ui.csp, so add every origin the app calls to connectDomains and every origin it loads assets from to resourceDomains. After you change the app, score the listing again from the maintainer panel so it picks up the change. For the full setup, read Publishing an MCP App.

Common Failure Modes​

"No verifiable contact addresses found." The server responded, but neither /.well-known/security.txt nor /.well-known/mcpbundles.json returned a usable contact. The claim dialog lists the URLs it checked. Publish one of those files with a mailto: contact or a maintainers[].email entry, then try again.

"This listing isn't open to claims." A platform admin has turned off claiming for this listing, usually because the vendor runs the server directly and chose not to take part. The reason appears in the dialog. If you think this is wrong, email hello@mcpbundles.com.

"This server URL is already in the public directory." Publishing matches on the server URL. If the existing listing is unclaimed and yours, claim it rather than publishing again. The error message links to it.

The publish step rejects your URL. The URL is probably a local or private address, is not HTTPS, or does not answer tools/list. Check that the URL is public and HTTPS, then test the server's tools with MCP Inspector.

OAuth listing has no tools after publish. This is expected when you publish without a token. Claim the listing, then complete the sign-in on the server's page. Tools are discovered when the credential is saved.

"Code arrived but verification fails." The code expires after 10 minutes, so request a new one. If the code is current, check that you picked the address you actually control. Two addresses can look similar once masked, and only one of them receives the code.

The listing has no MCP App label. Check tools/list and resources/list on your server directly. The resource MIME type must be exactly text/html;profile=mcp-app, and the tool metadata must use _meta.ui.resourceUri. If both are correct, connect the server again so discovery can finish.

See Also​