Feature Provisioning

How to provision which MCP features a gateway exposes in MCP Manager: for each server, choose to allow all, allow only selected, or block all tools (and the same for resources and prompts), preview a server’s live tools using an identity, and pin a tool by its name, title, or description so unreviewed changes stop passing the gateway.

When you add a server to a gateway, you decide exactly which of its tools, prompts, and resources the gateway exposes to clients. That decision is feature provisioning, and it’s how you apply least privilege in practice — exposing the handful of tools a job actually needs instead of a server’s entire surface. This page is the how-to; for why it matters and the security model behind it (including the defense against tool poisoning and rug pulls), see Feature Governance.

Provisioning features on a server is gated by the Manage feature provisioning settings capability. If you don’t see provisioning controls on a server within a gateway, your role doesn’t have it — capabilities are assigned per role and fully configurable, so access depends on the capability, not on any fixed role name. See the capabilities reference.

The three provisioning modes

For each server on a gateway, and independently for tools, prompts, and resources, you choose one of three schemes:

• Allow all — every capability of that type passes through.
• Allow selected — only capabilities matching an explicit allowlist pass; everything else is hidden and uncallable. This is least privilege in practice.
• Block all — no capability of that type is exposed.

Provisioning is fail-closed. A server you’ve just assigned to a gateway exposes nothing until you provision it — an empty allowlist passes no tools rather than defaulting to “expose everything.” Provisioning is the deliberate act of opening access.

Preview a server’s tools with an identity

To choose which tools to allow, MCP Manager shows you the server’s live feature list. Because a server can return a different set of tools to different identities, you first pick an identity to preview against — your own, or a shared one. MCP Manager fetches the tools that identity can see, so you select from the real, current list rather than guessing. (Picking the identity to preview is also where you set the server’s identity scheme — per-user or shared.)

Provision the tools you want

1. Open the server on the gateway

   From Gateways, open a gateway and select the assigned server you want to provision.

2. Pick an identity to preview

   Choose the identity scheme and select an identity to preview the server’s live tools, so the allowlist is built from the actual current capabilities.

3. Choose Allow selected for tools

   Set the tools scheme to Allow selected. Until you add something, the server still exposes no tools.

4. Add each tool you want

   Browse the previewed tool list and add the specific tools to expose. Each one you add becomes an allowlist entry.

5. Choose which fields must match

   For each added tool, choose which of its fields the gateway must match to let it through — its name, title, and/or description. See Pinning a tool by its metadata below.

6. Set prompts and resources, then save

   Set the prompts and resources schemes to Block all (or Allow selected) depending on what this gateway needs, then save.

Pinning a tool by its metadata

Each allowed tool is admitted only if it matches the fields you chose, exactly. How tightly you pin is a deliberate trade-off:

• Match on name only to tolerate the vendor improving a tool’s description over time.
• Match on name and description to freeze exactly the wording you reviewed — so if the description later changes, the tool no longer matches and is dropped rather than reaching the model with new, unreviewed text.

That second option is the control that neutralizes rug pulls and tool poisoning: you approve a specific version of a tool’s metadata, and anything that doesn’t match what you approved stops passing the gateway. The full reasoning is in Feature Governance.

Turn off prompts and resources you don’t need

Tools aren’t the only feature type a server can expose. If a gateway doesn’t need a server’s prompts or resources, set those types to Block all to remove them entirely — fewer features means less context, lower cost, and a smaller surface.

What clients see, and how it’s logged

Clients connecting to the gateway see one unified, filtered toolset, each tool namespaced by its server — only the capabilities you provisioned. Provisioning decisions are recorded in your logs: a capability removed from a list because it didn’t match the allowlist is logged as gateway_feature_filtered, and a direct call to a disallowed capability is logged as gateway_feature_blocked. That lets you confirm what a gateway exposes and catch the moment a previously-passing tool stops matching — for example, when an upstream server renames or rewrites it.

Further reading

Feature Governance

The security model behind provisioning — least privilege, and the defense against tool poisoning and rug pulls.

Curating exposed tools

How a gateway presents one filtered, namespaced toolset across many servers.

Identity Controls

Choosing the per-server identity you preview and provision against.

Viewing Logs

The gateway_feature_filtered and gateway_feature_blocked log types.