Discover MCP servers with the MCP server registry

Every environment in your integrator.io account has an MCP server registry: one URL that lists the environment's MCP servers, each with the URL a client uses to connect to it. The registry answers each caller with only the MCP servers that caller can connect to, based on access you already manage in integrator.io: each API token's scope, each workspace user's MCP server access, and the access you grant end users. Agents, scripts, and developer tools that read the registry find their MCP servers when they run, so you don't have to collect server URLs and hand them out one at a time.

The registry follows the MCP Registry v0.1 specification from the Model Context Protocol project, so tools built for MCP registries can read it when they send a Celigo credential. It's read-only and never grants access. It reflects the access you've set up and changes as soon as that access changes.

When to use the MCP server registry

• An agent or script needs to know which MCP servers it can use. Have it read the registry with its own credential instead of keeping a hardcoded list of server URLs. When you add a server or grant access to one, the agent finds it the next time it reads the registry.
• You want to confirm what a credential can reach. Read the registry with an API token or personal access token to see exactly which MCP servers it can connect to, for example before you hand a token to a partner or an integration.
• You keep a catalog of approved MCP servers. A catalog, gateway, or developer tool that reads the MCP Registry format can read your Celigo MCP servers with a Celigo credential, instead of having them copied in by hand.
• Developers need one URL, not a list. Give developers your registry URL. Each of them sees the MCP servers that their own credential can use.

What the registry lists for each caller

The registry applies the same access rules as connecting to an MCP server, so it lists a server only when the caller has access to it.

These rules apply to every caller:

• Disabled servers never appear. When you turn a server off, it leaves every caller's list immediately. When you turn it back on, it returns for the callers who have access to it.
• People who sign in see only servers they can sign in to. A sign-in lists MCP servers that have an identity provider set up, either Celigo Identity or Token validation. A server that accepts only API tokens doesn't appear, because a sign-in can't connect to it.
• A person who's both a workspace user and an end user sees their end-user access when they sign in. It's the same access that applies when they connect to a server.
• Each environment has its own registry. A registry lists only its own environment's servers. In accounts that use the production and sandbox toggle, servers in the sandbox aren't listed.
• Deleted servers don't appear, including servers in the recycle bin.

PAT access reflects the token owner's access at the moment of each request. If you change the owner's MCP server access or remove them from the account, the PAT's list changes on its next request.

Before you begin

• Your environment's MCP account alias. The alias is part of every MCP server URL in the environment: it's the segment after /mcp/. Account owners and administrators can also find it under Account > Company > Company info > MCP account alias. Each environment has its own alias. 

• A credential: an API token, a personal access token, or a client that signs in through Celigo Identity. See Create and manage API and Personal Access tokens.

There's nothing to turn on. Every environment that has an MCP account alias has a registry.

Find your registry URL

Your registry URL is your region's API address, then /mcp/, your MCP account alias, and /registry/v0.1/servers:

https://api.integrator.io/mcp/<MCP account alias>/registry/v0.1/servers

The API address depends on the region you sign in at:

For example, if you sign in at integrator.io and your production MCP account alias is acme-corp-prod, your production registry URL is https://api.integrator.io/mcp/acme-corp-prod/registry/v0.1/servers. A non-production environment uses that environment's alias, such as https://api.integrator.io/mcp/acme-corp-sandbox/registry/v0.1/servers.

Important: Changing your MCP account alias changes your registry URL along with every MCP server URL in the environment. The old registry URL stops returning your servers, so update every agent, script, and tool that reads the registry after you change the alias.

Read the registry

To read the registry, send an HTTP GET request to your registry URL with your credential in the Authorization header. Tools that read MCP registries send this request for you. To try it yourself, use a command-line tool such as curl:

1. Copy an API token or personal access token. See Create and manage API and Personal Access tokens.
2. Send the request, replacing the token and the alias with your own (example below).
3. Read the response. Each entry in servers describes one MCP server (example below).

curl -H "Authorization: Bearer <your token>" \
  "https://api.integrator.io/mcp/acme-corp-prod/registry/v0.1/servers"

{
  "servers": [
    {
      "server": {
        "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
        "name": "com.celigo.acme-corp-prod/support-tools",
        "title": "Support tools",
        "description": "Ticket lookup and escalation tools for the support team.",
        "version": "1.0.0",
        "remotes": [
          {
            "type": "streamable-http",
            "url": "https://api.integrator.io/mcp/acme-corp-prod/support-tools",
            "headers": [
              {
                "name": "Authorization",
                "description": "Bearer token for the MCP server.",
                "isRequired": true,
                "isSecret": true
              }
            ]
          }
        ]
      },
      "_meta": {
        "io.modelcontextprotocol.registry/official": {
          "status": "active",
          "publishedAt": "2026-03-02T09:14:00.000Z",
          "updatedAt": "2026-08-14T09:12:33.000Z",
          "statusChangedAt": "2026-03-02T09:14:00.000Z",
          "isLatest": true
        },
        "io.celigo.registry/entry": {
          "visibility": "entitled",
          "access": "entitled"
        }
      }
    }
  ],
  "metadata": { "count": 1 }
}

These fields tell you what each server is and how to reach it:

For every field, the paging options, and the error responses, see MCP server registry API reference.

Search the registry

Add search to return only the servers whose name or registry name contains the text you enter, ignoring case:

https://api.integrator.io/mcp/acme-corp-prod/registry/v0.1/servers?search=support

Page through a long list

The registry returns up to 30 servers per request. Add limit to ask for up to 100. When more servers are available, the response's metadata includes a nextCursor value. Send it back as cursor to get the next page.

Connect to a server from the registry

Each server's url in remotes is its MCP endpoint, which uses the Streamable HTTP transport. To connect to a server:

1. Add the url to your MCP client or agent as a remote MCP server.
2. Authenticate the same way you read the registry, as described below.
3. With an API token or personal access token, send the token in the Authorization header as a bearer token. For these callers, each entry's remotes[0].headers lists the Authorization header as required.
4. With a sign-in, the client asks you to sign in when it first connects. A server whose identity provider is Token validation asks you to sign in with that identity provider instead of Celigo Identity.

Note: A personal access token can connect to an MCP server and list its tools, but it can't run the server's Celigo Tools or APIs. To run them from a script or an agent, use an API token or sign in.

Control what the registry shows

The registry has no settings of its own. To change what a caller sees, change the access you've already given.

Changes apply the next time the caller reads the registry. There's nothing to publish or refresh.

Understand empty lists and errors

An empty list isn't an error. A valid credential that can't connect to any servers in the environment gets a successful response with no servers:

{ "servers": [], "metadata": { "count": 0 } }

A valid credential gets this response when:

• It doesn't have access to any enabled server in the environment.
• It belongs to a different account or environment than the alias in the URL.
• The alias in the URL doesn't belong to any account.

The registry responds the same way in each case, so a response never reveals which accounts or servers exist.

401 Unauthorized means the request had no credential the registry could use: no Authorization header, or a token that's invalid, expired, or revoked. The response includes a WWW-Authenticate header that points to the registry's protected resource metadata, which names Celigo Identity as the place to sign in. Clients that support MCP sign-in use it to start signing in. A token that your own identity provider issued for a server that uses Token validation can't read the registry, and it gets the same response.

For every response the registry can return, see MCP server registry API reference.

Read a non-production environment's registry

Use an API token or personal access token that was created in the same environment as the registry. A token from your production environment gets an empty list from a non-production environment's registry, in the same way that it can't connect to that environment's MCP servers. A sign-in through Celigo Identity works in any environment you have access to.

Names reserved for the registry

Because the registry shares the /mcp/<MCP account alias>/ path with your MCP servers, some names are reserved:

• An MCP account alias can't be registry or portal, in any capitalization.
• An MCP server's Relative URI can't be /registry, /oidc, or /portal, in any capitalization. It can be up to 128 characters long, including the leading slash.

Frequently asked questions

Does the registry give anyone access to my MCP servers?

No. The registry lists only the servers a caller can already connect to. To give someone access, grant it the way you do today, and the registry reflects the change.

Why doesn't the registry list a server I can see in AI studio?

Check that the server is turned on, that the credential has access to it, and that you're reading the registry for the server's environment. An API token with Custom access, or a user who doesn't have access to all MCP servers, sees only the servers they've been given. If you signed in, also check that the server has an identity provider set up. If you're also an end user in the account, your end-user access applies when you sign in.

Can I add the registry URL to Claude, Cursor, or another AI client?

No. The registry URL lists MCP servers. It isn't an MCP server itself, so an AI client can't connect to it. Add each MCP server's own URL to the client.

Can I use the registry as the private MCP registry in VS Code?

VS Code doesn't send a credential when it reads an MCP registry, so it receives 401 Unauthorized from your MCP server registry and shows no servers.

Can I change MCP servers through the registry?

No. The registry is read-only. Create and change MCP servers in AI studio > MCP servers, or with the /v1/mcpservers API.

How do I know when a server changes?

Read the registry again. Each entry's updatedAt value, under _meta, shows when the server last changed. The registry doesn't support fetching only the changes since a date, so read the full list each time.

Is the registry format final?

The registry follows version 0.1 of the MCP Registry specification, which the Model Context Protocol project marks as a preview. The version is part of the registry URL, so a later version of the specification can be served at a new URL instead of changing this one.

Related articles

• MCP server registry API reference
• MCP server overview
• Manage MCP servers
• Set up authentication for an MCP server
• Create and manage API and Personal Access tokens
• Invite users and manage access to MCP servers
• Invite and manage end users
• Create and manage capability sets on MCP servers