Connection Types
Connection Types
<!-- Taxonomy reconciled with the MCP / HTTP / CUSTOM badges shown in the catalog. Custom services documented. Revoke path corrected. US spelling. -->
Not every service connects to Gatekeeper the same way. Which type you're dealing with changes who sets it up, what you can adjust yourself, and what "revoke" means.
There are two things to look at, and people often confuse them: the badge on a service in the catalog, which tells you how it's integrated, and who supplied the credential, which tells you what you can change.
The badges in the Services catalog
Every service in the catalog carries a type badge.
| Badge | What it means | Examples |
|---|---|---|
| MCP | The service speaks the Model Context Protocol natively. Gatekeeper connects to its MCP server. | HubSpot, Atlassian, Cloudflare, Grafana, Honeycomb, Make |
| HTTP | The service is exposed as a set of HTTP API operations rather than an MCP server. | Bitbucket, Google Sheets, the Microsoft 365 family |
| CUSTOM | Your own MCP server or HTTP API, added by you. Gatekeeper detects what it needs. | Anything you host |
| SETUP | Shown alongside a badge when the service needs extra configuration before use. | AWS (an IAM role you control), Fireblocks |
The badge affects how Gatekeeper talks to the service. It doesn't change how policy works — every connection is evaluated the same way regardless.
Who supplied the credential
This is the part that determines what you can change.
|
|
You connected it | Your organization supplied it |
|---|---|---|
| How it's set up | You click Connect and log in to the service yourself | An administrator supplies an API key centrally |
| Permissions | You pick from the service's requestable scopes at connect time | Fixed by the key — there are no scopes to select |
| To change permissions | Reauthenticate with a different scope selection | You can't; the key must be reissued |
| To revoke | Revoke the grant yourself under Sessions → Downstream | Requires an administrator |
| Typical use | Most services | Infrastructure and security tooling, where per-person login isn't practical |
Organization-supplied connections appear in your Services list already connected and marked as such. If you need broader access to one, that's a conversation with your administrator — there's nothing to adjust from your own Services page.
In both cases Gatekeeper never receives your password. For connections you make yourself, it receives an authorization grant.
Custom services
If a tool you rely on isn't in the catalog, you can add it yourself. Choose Custom in Services and point Gatekeeper at your own MCP server or HTTP API; it works out what the service needs.
Custom services behave like any other once added — same policy evaluation, same audit records, same credential handling.
Per-tool enablement
This is worth calling out separately, because it's the most common cause of a confusing failure.
Independently of your policies, an administrator can enable or disable individual tools on a service. A disabled tool isn't a policy denial — the tool simply isn't there. Your agent won't see it when it lists what's available, and if it tries to call it anyway the call fails as unrecognized rather than as blocked.
So there are two separate reasons an agent can't do something:
| Symptom | Cause | Fix |
|---|---|---|
| Action blocked, with a reason | Policy decision | Adjust the policy |
| Tool not found or not listed | Tool disabled on the service | Enable the tool |
Checking which of the two you're dealing with saves a lot of time. If your policy looks correct and the action still won't run, check tool enablement before rewriting the rule.
Checking what you have
Your Services list shows every service, its badge, its status, and how many tools are enabled. If a service shows as connected but your agent can't see any of its tools, that's an enablement question rather than a connection one.