Feature Provisioning

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. The filtering is enforced entirely by the gateway, so it works for every server — including one whose vendor offers no tool-level enable/disable controls of its own. What you can block is never limited by the upstream server’s settings. 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. For a guided walkthrough that provisions a trimmed toolset on a new gateway, see Build a team gateway.

​

The three provisioning modes

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

• Allowing all (shown as Allowing all tools, Allowing all resources, or Allowing all prompts) — every capability of that type passes through. This is the scheme a server gets when you first assign it to a gateway.
• Allow if conditions are met — only capabilities matching an explicit allowlist pass; everything else is hidden and uncallable. This is least privilege in practice.
• Blocking all (shown as Blocking all tools, and so on) — no capability of that type is exposed.

MCP Manager filters by allowlist only: there is no “allow everything except these” denylist mode, and that’s deliberate — see Why an allowlist, not a denylist for the reasoning.

​

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

​

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.

​

Filter and gate by tool type

MCP tools can carry annotations — behavioral hints the upstream server attaches to a tool, such as whether it only reads data or might delete it. MCP Manager surfaces those hints as a tool’s tool type and lets you use them in two ways: to filter the lists you provision from, and to gate an allowlist condition. Every tool’s annotations appear in a Tool type column on the Available, Provisioned, and Conditions tabs. Each reported annotation shows as an icon — its -off variant when the value is false — and annotations the server didn’t report are left out. Hover any icon for a tooltip stating that annotation’s value, such as Read-only is true. The four hints are independent — a tool can be read-only and open-world at once — so each renders on its own.

​

Filter the list by tool type

On the Available, Provisioned, and Conditions tabs, open Filter by tool type to narrow which rows are shown. The dropdown has one section per annotation — Read-only, Destructive, Idempotent, and Open world — and within each you can check is true, is false, and/or is unknown. Select all and Deselect all toggle every box at once.

• The checks are combined with OR, across every section: a row is shown if it matches any box you’ve checked. With nothing checked, everything is shown — the trigger reads “Filter by tool type”; check one box and it reads “Filtering by 1 annotation”, more than one and it reads “Filtering by N annotations”.
• is unknown matches tools whose server didn’t report that annotation — a state distinct from true or false.
• The same filter sits on all three tabs and shares one selection: it narrows the Available and Provisioned lists of tools, and on the Conditions tab it narrows the allowlist rules to those that gate on the annotations you’ve checked.
• The filter composes with the search box, so you can stack a Destructive is true filter on top of a name search to scan, say, every delete-style tool on a large server.
• Filtering applies to tools only. Prompts and resources don’t carry these hints, so the control doesn’t appear for them.

Filtering only changes what you see while provisioning; on its own it doesn’t change what the gateway exposes. To make a tool-type rule actually gate traffic, add it to the allowlist as a condition.

​

Gate an allowlist on tool type

A condition is an allowlist entry that admits tools by a rule rather than by naming a single tool — it lives on the Conditions tab next to the tools you’ve pinned by name. When you add one, you can constrain it on annotations alongside name, title, and description. Each annotation offers is true, is false, is unknown, or No value — and No value is the default, meaning “don’t constrain on this annotation.” A single condition combines its constraints with AND: a tool matches only if it satisfies every field you set. So Read-only is true on its own admits every tool the server marks read-only, without your naming each one; add Open world is false to the same condition and it narrows to tools that are both read-only and closed-world. The allowlist as a whole combines its entries with OR: a tool is exposed if it matches any entry — any tool pinned by name, or any condition. That lets you pair a broad rule (“all read-only tools”) with specific pins (“plus these three write tools I reviewed”) on the same server. The filter and a condition use opposite logic by design: the filter casts a wide net with OR so you can eyeball several types at once, while a condition tightens with AND so one rule can be precise. is unknown in a condition gates to tools whose server didn’t report that hint — a way to single out or quarantine unannotated tools, distinct from true or false. Identical conditions are de-duplicated, so adding the same rule twice is a no-op. However you build it, a condition is enforced like any other allowlist entry: non-matching tools are filtered out of what clients see, and a direct call to one is blocked — see What clients see, and how it’s logged.

​

What each annotation means, and how far to trust it

The four annotations come straight from the Model Context Protocol tool specification. When a server sets one to true, it means: A tool shows unknown for any annotation its server didn’t report. MCP Manager surfaces that gap honestly rather than guessing — which is worth knowing, because it differs from the MCP spec’s own defaults: the spec assumes an unannotated tool is the riskier case (not read-only, potentially destructive, not idempotent, and open-world). An “unknown” in MCP Manager is therefore an absence of information, not a claim of safety.

​

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