Servers catalog

An MCP entry exposes a server’s tools and resources to the agents behind your gateway. What distinguishes one entry from another is who supplies the credential.

​

Built-in and custom

Every catalog card carries the badge Built-in. A server you register yourself is Custom. The Origin filter is those two values. Status is a separate filter: Who supplies the credential is the decision that shapes the entry. A shared credential gives every caller the same upstream permissions and one line in the destination’s audit log; per-user accounts give each person their own permissions and their own line. For anything that reads or writes real data — issues, repositories, customer records — that difference is usually the whole decision.

​

Registering your own server

A custom entry points at either an MCP endpoint or an HTTP API. An MCP server URL is an http(s) streamable-HTTP endpoint. Name it, point at it, choose how it authenticates. An OpenAPI document is how you get tools out of an API that has never heard of MCP. Give TrustGate a URL to an OpenAPI 3.x document and it compiles the operations into tools. Validation runs before you can save and fails at a named stage — fetch, parse or compile — and on success reports how many tools it produced. That count is the number to read: a document that compiles to far fewer tools than the API has operations usually describes them too loosely for them to be exposed safely, and the fix is in the spec, not here. An API base URL overrides servers[0] from the spec, for the common case where the document is published with a placeholder host.

​

Authentication modes

User account is the default: each caller signs in once, the first time they use the instance, and reaches only what their own account reaches. Shared account is connected here instead — one Connect on the entry, by you — and every caller rides on it, which is what a team’s build bot or ticket tracker usually wants. Disconnecting it stops every caller at once. An application calling a User account instance has to name the person it acts for; the key on its own has no account there and the call is refused. A Shared account instance serves the application itself and every end user alike. See acting for end users. Manual OAuth registration also takes optional scopes, an RFC 8707 resource indicator, and whether the token endpoint expects the secret as basic auth or as a form field. When you edit an entry, blank secret fields mean keep what is stored. You will not clear a credential by not retyping it. An entry that forwards the caller’s own token cannot be switched to another mode after the fact.

​

What people can install for themselves

A gateway’s Employee portal is either open — anyone may install anything in it — or curated, where each person installs from the resources assigned to them. On a curated gateway, wanting something outside that assignment produces a request rather than a refusal. Approving it grants the server to the person who asked, or to one of their groups; the second turns a one-off into a standing rule and is usually what you want the third time the same request appears. Requests and their history live under Access, which is also where the assignments themselves are set.

​

Tools are exposed here, governed elsewhere

An entry exposes whatever tools its server advertises, unless you lock its tools. Which of them a given application may actually call is set on the application; how often any of them may run is a policy.

​

Locking a server’s tools

A server decides its own tool list, and it can change that list at any time. A tool it adds tomorrow, or a description it rewrites, reaches every application that uses the entry with nobody having looked at it. Applications that restrict their tools are covered, because a tool they did not name never reaches them. Applications that allow every tool, which is the default, are not. Lock tools closes that gap for the whole server. Once an entry is locked, only the tools you have approved are exposed. A new tool, or an approved one whose description or input schema changes, is held back until someone approves it.

​

Turning it on

Edit the entry and check Lock tools. The console lists the tools the server advertises right now, all checked, each with its full description and schema. Uncheck any you do not want, then confirm.

• Checked tools are approved.
• Unchecked tools are rejected. They stay hidden, and you can approve them later.

Approving the current list is what keeps a lock from cutting traffic: the moment it takes effect, every application keeps the tools it was already using. For a server where each user signs in with their own account, the list cannot be read ahead of time, because there is no account to ask with. Such a server is locked with nothing approved. Its tools appear for review the first time a user connects, and nothing is exposed until you approve them.

​

Reviewing tools

Review on a locked entry sorts its tools into To review, Approved and Rejected. The registry list shows how many are waiting. A changed tool is the one to read carefully. It is held back because the server already runs the new version: the definition you approved is no longer what a call would reach. Read the full description before approving it. It is text the server controls, and it is passed to your agents. Approving a tool exposes it straight away, and connected clients are told their tool list changed. Rejecting it keeps it hidden for as long as the server offers it. You can reverse either decision later. A hidden tool answers like a tool that does not exist. A client calling it by name learns nothing about what the server offers.

​

Turning it off

Unchecking Lock tools needs the Admin role. The entry then exposes every tool the server advertises again, including any it adds later. Your decisions are kept: if you lock the entry again, its tools come back to review against them. Locking reads a tool’s name, description and input schema. A server that changes what a tool does without changing how it describes it cannot be caught at the gateway. For that, rely on the server’s own controls and on the policies that govern each call.

​

Every server

TrustGate ships connection details for 199 MCP servers, which makes adding one a credential decision rather than an integration project. Anything not here is a custom server: an MCP URL, or an HTTP API described by an OpenAPI document.

​

Reading the table

Authentication is the column that decides how much work an entry is: GitHub and Linear each offer an API key beside OAuth. GitHub’s key is a personal access token; Linear’s is a personal API key. Both go out as Authorization: Bearer. The OAuth side is a forwarded account — User account or Shared account, as in OAuth (forwarded). The catalog declares the same pair for Atlassian (an API token), GitLab (a personal access token), Stripe (a restricted API key), and Supabase (a personal access token). You supply marks servers that are per-tenant rather than one global URL — your subdomain, your workspace, your region. Two things this list does not tell you. Whether a person may install any of these is Access. What an application may call is set on the application.

​

Cloud platforms

​

Developer tools and source control

​

Observability and incidents

​

Data and analytics

​

Project and product management

​

Productivity and docs

​

Communication

​

Customer support and ITSM

​

Sales, CRM and marketing

​

Finance and payments

​

Security and identity

​

Web, CMS and commerce

​

AI, search and automation