Skip to main content
The list of services your installation can connect to is data, not code. A platform admin adds a row in the admin panel and the connector appears for the organisations you grant it to. There is no code change, no database migration and no release of Ragen. That matters in two situations the old behaviour could not serve at all:
  • A service you use ships an MCP server, but Ragen has no built-in connector for it. You add it yourself.
  • Your company runs its own MCP server, on your own network. Previously this was impossible at any price without forking Ragen.
Only a platform admin can add a connector. The catalogue is installation-wide: an organisation admin can use what you grant them, but cannot point Ragen at a server of their choosing.

​
Add the connector

1

Open the catalogue

In the admin panel, go to MCP Catalogue. You’ll see every connector the installation offers, including the built-in ones.
2

Create an entry

Click Add a connector and fill in:
3

Test the connection

Click Test connection. Ragen opens an MCP session against the URL and lists the tool names it finds.This is the only way to tell a working endpoint from a typo before a user does. Don’t skip it.
4

Save

The connector is now in the catalogue and enabled.
5

Grant it to organisations

Go to Connectors in the admin panel. If an organisation’s allowlist is empty it gets everything; otherwise add the new slug to the organisations that should have it.
Users then connect it themselves in Settings → Connectors, exactly like a built-in.

​
Choosing the authentication type

​
Two things that catch people

​
The URL must end in /mcp

Give the entry https://mcp.example.com and the connector will be stored with one address and dialled at another, so no tools load. Test connection catches this — it probes exactly the URL you typed, and an MCP server answers only on its /mcp path. This is the main reason to use the button.

​
localhost is refused, and the checkbox does not change that

Ragen checks every catalogue URL against an SSRF policy, at save time, at connect time, and on every tool call. Ticking Allow a private address widens that policy to RFC 1918 space — 10.x, 172.16–31.x, 192.168.x — and to nothing else. Loopback stays refused with the box ticked, on purpose: cloud metadata services live on link-local addresses, and a flag that admitted everything the policy was written for would be a rename of “off”. So http://localhost:9005/mcp cannot be saved. The refusal reads “That address is private or reserved”, which sounds like the checkbox is the answer. It is not. Use instead:
  • your host’s LAN address — http://192.168.1.50:9005/mcp, box ticked;
  • a container name, if Ragen and the connector share a Docker network — that resolves to 172.x, box ticked;
  • a public hostname over HTTPS in production, box unticked.

​
A host your deployment vouches for

Some private networks cannot be reached through RFC 1918 addresses. Railway’s private network is an example: its *.railway.internal names resolve to an IPv6 unique-local address (fd…), and that may be the only address a service can reach, even where an IPv4 one is also published. Ragen refuses unique-local addresses even with the box ticked, because cloud metadata services live there too (fd00:ec2::254 on EC2). For a host like that, list it in CONNECTOR_TRUSTED_HOSTS. Set it on the web app, the API and the admin panel:
  • Separate entries with commas. host.example matches that host exactly. .example, with a leading dot, matches any subdomain of it, but not example itself.
  • Wildcards and IP ranges are ignored. List every host by name.
  • A catalogue entry pointing at a listed host connects without the address policy, just like a built-in connector’s MCP_*_SERVER_URL. Test connection in the admin panel probes it the same way.
The list is set in the environment by whoever runs the deployment. Nothing in the admin form can widen it. Two cases stay under the policy even when the server URL is trusted:
  • The connector also talks to another host. If its auth base URL is not on the list too, the trust does not apply. Otherwise it would also lift the policy from the address where users register their keys.
  • API_KEY_CUSTOM_HEADER connectors. Their URL is typed in by an organization user, not by you, so they are never trusted this way.
A connector that carries a credential requires HTTPS, with no exception. API_KEY_BEARER sends a user’s own API key and EXTERNAL_MCP sends an OAuth token; either would otherwise travel in clear text. Ragen refuses plain http:// for both.SERVER_SIDE may use http://, but that is not the same as it being private. No credential is exposed, and these still are: the x-customer-id header, which carries your organisation and user identifiers, and every MCP payload — the arguments each tool is called with and the data it returns.So plain http:// is for a network you control and trust: a private subnet, a Docker network, a development machine. On anything else, including any hop you do not own, use HTTPS.

​
Turning a connector off

Set an entry to disabled and it disappears from every organisation’s gallery and accepts no new connections — including organisations you granted it to. Connections people already have stop loading its tools. This is the switch to reach for when a service is misbehaving; it takes effect immediately and needs no deploy.

​
Built-in connectors

The connectors Ragen ships with are ordinary catalogue rows and appear in the same list, marked Built-in. Two differences:
  • You can enable or disable them, but not edit or delete them. Their shape is code.
  • Their server URL comes from environment variables (MCP_GOOGLE_SERVER_URL and siblings) rather than the row, so a database copied between environments cannot silently repoint them at the wrong host.

​
Next

Build your own connector

Scaffold an MCP server Ragen can connect to with one command.

Using connectors

What connectors do, and how users connect them.