Skip to main content
The registry connector brings in a server someone else already published, rather than wrapping the underlying API yourself. The source is the Model Context Protocol registry (registry.modelcontextprotocol.io). Noorle reads a mirror of it, refreshed on a regular cadence. Access is read-only — Noorle does not publish to it.

​
Creating one

In the Portal, Connectors → New connector → MCP Registry. Search for the server by name, pick a version, then supply a bearer token if the server needs one. An empty search box lists the latest remotes. The registry holds thousands of remote-capable servers, so searching beats browsing.

​
Remote servers only

Noorle offers remote-capable servers only, and dials them over Streamable HTTP. Registry entries that ship a stdio transport exist upstream but are filtered out — Noorle does not execute processes on your behalf.

​
Configuration

What a server needs is declared in its own registry metadata: which environment variables, which are secret. Everything you enter as a secret is stored as AES-256-GCM ciphertext. Registry connectors authenticate with no credential or a bearer token. If a server needs an OAuth flow, add it as a Custom MCP connector instead.

​
What you get

The connector exposes the server’s tools, namespaced under the connector’s namespace. Bind it to an agent or a gateway like any other capability. Registry connector tools are Act tier, kind-wide.

​
Upstream is upstream

Two consequences worth planning around:
  • The server’s tool list changes on its author’s schedule, not yours. Noorle sends no notifications/tools/list_changed, so a client caching a gateway’s tools/list refreshes on the ttlMs hint rather than on a push.
  • Rate limits and outages belong to the upstream service. Noorle does not add a per-connector limiter in front of them.

​
Next