Connector Catalog
Remote MCP connectors you can add in one step, what the Verified and Tested marks mean, and what they do not mean.
Studio → Settings → Tools → Catalog lists remote MCP connectors that ELIZON has checked against a fixed set of criteria. Adding one creates an ordinary MCP server (see Tools) with the URL and sign-in method already filled in, so you can add it and connect it in one step.
The catalog is reference data that ships with ELIZON. Your deployment reads it from the release it runs; it never fetches the list, the descriptions or the icons from the internet. Requests leave your deployment only to the servers users add and connect: when they connect, and on every tool call an agent or workflow makes to them afterwards.
Verified is not a security audit
The catalog checks how a connector is reached and how it signs you in. It does not review what the vendor's tools do with your data after you authorize them, and it says nothing about a vendor's security, data residency or legal standing. Names and logos belong to their owners. Listing is not an endorsement or affiliation.
How a connector gets into the catalog
ELIZON keeps its own list of candidate connectors in the repository (catalog/seed/connectors.csv), changed only by reviewed pull requests. Being on that list makes a connector a candidate. It is listed in the Catalog tab only when both of these hold:
- it passes all seven criteria below (it is Verified), and
- it has a description written by ELIZON and approved by a maintainer. No vendor's tagline or marketing text is copied.
Candidates that do not pass are kept out of the tab and counted, with the reason, in the build report each release carries.
The seven criteria
A probe checks most criteria. It runs on a maintainer machine or in ELIZON's own CI, before each release and once a month, and never at your runtime. The probe sends one unauthenticated MCP request and reads the connector's public sign-in documents. It never logs in, never follows a sign-in redirect and never sends a credential.
| Criterion | In plain words | Who decides |
|---|---|---|
| V1 | Vendor-operated HTTPS endpoint | A maintainer records that the endpoint runs on a domain the vendor controls. A shared hosting domain with no vendor evidence fails. |
| V2 | Speaks MCP over Streamable HTTP | The probe: the endpoint answers an MCP request, or asks for sign-in the way an MCP server does. The older /sse transport fails. |
| V3 | Sign-in is discoverable | The probe finds the connector's sign-in documents, or the vendor documents another way to sign in (an OAuth app, an API key, none). |
| V4 | Listed by the vendor or the MCP Registry | The probe finds the endpoint in the MCP Registry under a namespace the Registry ties to the publisher, or on a vendor documentation page. |
| V5 | Terms permit listing | A maintainer records that the vendor's terms allow ELIZON to list the connector's name, URL and tool names. |
| V6 | Not on the denylist | The build checks catalog/denylist.yaml. |
| V7 | Probed within 30 days | The build checks that the probe result is no older than 30 days at the release cut. |
The entry's detail drawer shows each criterion with its result and the probe date.
What Verified means
Verified is ELIZON's own label. It means V1 to V6 passed and the probe result was no older than 30 days at the release cut (V7). That is all it means:
- It is not a security audit of the vendor or of its tools.
- It does not cover what the vendor's tools do after you authorize them, or where the vendor processes your data.
- It is not a statement by the vendor, by the MCP Registry or by any other party.
- It describes the connector on the probe date. A vendor can change its endpoint afterwards.
A connector whose latest probe failed stays Verified, from its last passing probe. After two failed probes in a row it is listed as a delist candidate in the probe report, for a maintainer to decide. V7 is still measured against that last passing probe: if it is more than 30 days older than a release cut, that release does not list the connector.
What Tested on ELIZON means
Tested on ELIZON is a separate mark, with a release number. It means a maintainer added the connector, connected it and made one tool call on that ELIZON release. For connectors that need an OAuth app, the test used an OAuth app the operator registered with the vendor, the same way you would (see Manual OAuth apps).
Tested is a record of one successful run, not a promise that every tool works or that it keeps working on later releases. A connector without the mark shows "Not tested on ELIZON yet"; it may work, nobody has recorded a run.
Sign-in methods
The Sign-in filter and the detail drawer show how the connector signs in, taken from the probe or from the vendor's documentation (the card's chip shortens OAuth (automatic) to OAuth):
| Shown as | What happens when you connect |
|---|---|
| OAuth (automatic) | You sign in with the vendor in a pop-up. ELIZON registers itself as an OAuth client with the vendor, so there is nothing to set up first. |
| OAuth app required | The vendor does not let ELIZON register itself. An administrator registers an OAuth app with the vendor first (see Manual OAuth apps). |
| API key | ELIZON sends a key you create in the vendor's console with every request. The key is stored as an organization secret and referenced as {{secret.KEY}}, never shown to agents. |
| None | The connector is public. No credentials are sent. |
| Unknown | The probe could not tell. ELIZON tries OAuth when you connect; if that fails, edit the server to add credentials. Changing the sign-in method detaches it from the catalog (see Custom servers). |
| Not supported | ELIZON cannot complete this connector's sign-in yet. The card says so with the reason, and Add and connect is disabled. |
Adding a connector
Open an entry and choose Add and connect, offered for a fixed-URL connector whose sign-in is OAuth (automatic), API key or None. Every other entry (a per-tenant connector, OAuth app required, Unknown) offers Add, and you connect after setting it up. The Add dialog asks:
- Scope. This project, or the whole organization (as for any tool).
- Name and identifier. The identifier is how agents and workflows name the server. If one already exists in that scope, a number is added (
gmail-2); you can change it. - URL. Read-only for a fixed-URL connector; an input for a per-tenant connector.
- Credentials, where the sign-in method needs them.
Adding and connecting needs the Editor role in the project. Once connected, the server's tools appear in the Agent Builder's tool picker like any other MCP server's.
Per-tenant connectors
Some vendors give each customer their own endpoint (for example a host under your company's account name). The catalog entry for such a connector has no URL. It has a pattern instead, taken from the vendor's documentation, and the Add dialog shows the host it expects.
You type your tenant's URL when you add the connector. ELIZON refuses a URL that does not match the pattern, naming the pattern, because that URL is where your OAuth token would be sent. Policy checks (below) are run on the URL you type.
A per-tenant connector is listed only when its pattern is recorded. A candidate without one cannot pass V1.
Manual OAuth apps
A connector marked OAuth app required needs an OAuth app that you register in the vendor's developer console, because the vendor does not offer automatic client registration. Each ELIZON deployment registers its own app: the address the vendor sends you back to belongs to your deployment, so one app cannot serve every installation.
- In the vendor's developer console, create an OAuth client of the web application kind. The entry's Vendor setup guide link opens the vendor's instructions.
- Add your deployment's redirect URI to it. The Add dialog shows it, with a copy button:
<API_URL>/api/v1/workspace/tools/mcp/oauth/callback, whereAPI_URLis your api-gateway's public address. - Paste the app's Client ID and Client Secret into the Add dialog, then connect. ELIZON requests the scopes the connector advertises; the vendor's consent screen lists them.
Google connectors
Google Drive, Gmail and Google Calendar need an OAuth app of your own. Follow Google's setup guide for its MCP servers: create an OAuth client of type Web application and select Use this client for an AI-powered agent.
Choose the app's audience with care:
- Internal (only users of your Google Workspace organization). Sign-ins do not expire after a week. It needs a Google Workspace organization, and every user who connects must belong to it.
- External, in Testing. Each user who connects must be added as a test user (Google allows up to 100). Google expires a test user's authorization and refresh token after 7 days, so these servers need a reconnect every week. When a Google server stops working after about a week, connect it again.
Blocked by policy
An Organization's policies apply to catalog connectors before anyone adds them. A tool rule can name a catalog entry as mcp_catalog:<slug> (in the policy editor, the Catalog connectors group of the tool picker). It covers every MCP server added from that entry. For a fixed-URL entry it also covers any server added by hand with the same URL, so re-creating a blocked connector manually does not get around the rule. URLs are compared after normalization (host case, default port, trailing dot), and only HTTPS URLs match. A per-tenant entry has no URL to compare, so its rule covers only servers added from the catalog, until they are detached.
An entry is shown as Blocked by policy when the project's effective policy denies it, or when a host it contacts is not on the network (egress) allowlist. The entry stays visible with the reason: the policy, the rule and, for a network block, the host. Add is refused with the same reason, and connecting is refused naming the host.
If an entry is blocked for the project but not for the organization, Add opens with the organization scope chosen. A project whose policy denies the connector still cannot bind or run its tools.
Update available
When a new ELIZON release changes a catalog entry you have added (its URL or URL pattern, its sign-in method or the hosts it contacts), the server and the card show Update available. Review update shows the old and new values side by side. Nothing changes until an Editor applies it. Applying it disconnects the server and clears its tool list, so you connect it again; credentials issued for a different host or authorization server are removed.
If an entry is removed from the catalog, servers already added from it keep working unchanged. They show "No longer in the catalog" with the catalog version it left in, and get no further updates.
Custom servers
When you edit the URL or the sign-in method of a server added from the catalog, it is detached from the catalog and shows as Custom. The edit dialog warns you before you save. Changing the URL or the sign-in method also clears the server's OAuth sign-in, so you connect it again. A Custom server has no Verified or Tested mark and gets no catalog updates, and its catalog entry shows as Not added again. A server you added by URL yourself carries no catalog mark at all.
A policy rule that names a fixed-URL catalog entry still applies to a Custom server, or to one added by URL, whose URL equals that entry's URL. A rule that names a per-tenant entry no longer applies once the server is detached.
Changing the catalog
The catalog changes only through reviewed pull requests to the ELIZON repository. How to propose a connector, correct an entry or ask for an entry or a logo to be removed is in catalog/CONTRIBUTING.md.