Feature Governance

Feature governance is how MCP Manager decides which MCP capabilities — tools, prompts, and resources — a gateway exposes from each server, and which it hides. It is the principle of least privilege applied to MCP: an agent should see only the specific capabilities its job requires, not the entire, over-provisioned surface a server happens to offer. This is distinct from runtime protections, which scan the content of calls that are allowed through; feature governance controls what is exposed and callable in the first place.

​

Why govern features: the over-provisioning problem

Every tool a server exposes is described to the model in metadata — a name, a description, and an input schema — and that metadata is read straight into the model’s context on every request. Servers routinely expose far more tools than any one task needs (a single server’s tool count can swing from dozens to over a hundred between releases). Exposing all of them has three costs at once:

• Cost. Tool metadata is frequently many times larger than the user’s actual prompt, and you pay for those tokens on every call.
• Accuracy. Irrelevant tool definitions pull the model off course; a tighter, relevant toolset measurably improves how reliably it picks the right tool.
• Security. Every exposed tool is attack surface — a capability the agent could be tricked into calling, and a description that could carry a hidden instruction.

Feature governance addresses all three by letting an administrator expose only what’s needed. And because the gateway enforces the exposure, least privilege doesn’t depend on the vendor: a server that ships no tool-level enable/disable controls natively is governed exactly like one that does. The same idea is introduced from the gateway’s side in Curating which tools are exposed; this page covers the security model and the matching rules in depth.

​

The three provisioning modes

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

• Allowing all — every capability of that type passes through. Convenient, and the scheme a server gets when first assigned to a gateway, but it exposes the full surface.
• 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 — no capability of that type is exposed. Use this to switch off, say, prompts or resources entirely while keeping tools.

​

Pinning a capability by its metadata

Under Allow selected, each allowlist entry is a condition that matches a capability on the fields you choose — its name, its title, and its description. The matching is exact, and it combines in two directions:

• Within one condition, all the fields you specify must match (a logical AND). A condition that pins both name and description matches only a capability whose name and description are exactly what you approved.
• Across multiple conditions, any one match is enough (a logical OR). The first condition a capability satisfies admits it.

A capability that matches no condition is filtered out of the capability list the client sees and is denied if called directly — it is as if the tool does not exist on that gateway. You decide how tightly to pin each entry: match on name only to tolerate the vendor improving a description over time, or match on name and description to freeze exactly the wording you reviewed.

​

A defense against tool poisoning and rug pulls

Pinning on the description is the control that neutralizes two specific MCP attacks:

• Tool poisoning — a server embeds hidden instructions in a tool’s description or schema. Because that text enters the model’s context, a poisoned description is effectively untrusted code aimed at your agent.
• Rug pulls — a tool that was benign when you approved it is silently changed afterward, so its description (or behavior) turns malicious without any visible signal.

Both depend on the metadata changing out from under you. When you pin a tool by name and description, a changed description no longer matches the condition, so the tool stops passing the gateway — it is filtered out rather than forwarded to the model with its new, unreviewed wording. In effect, you approve a specific version of a tool’s metadata, and anything that doesn’t match what you approved is dropped.

​

Why an allowlist, not a denylist

MCP Manager filters by allowlist — you name what passes, and everything else is hidden. It deliberately does not offer the inverse: a denylist that exposes every capability except a named few you block. A denylist reads as convenient (“expose this server, just hide its send_email tool”), but it fails open the moment the upstream server changes, because the block is anchored to capability metadata the server itself controls:

• A renamed capability escapes the block. Block send_email, and if the server later renames it to dispatch_email, your rule no longer matches — the tool passes the gateway unblocked.
• A newly added capability is exposed unreviewed. If the server adds bulk_send_email, a denylist that names only send_email lets the new tool through with no chance for you to see it first.

Both are the rug pull above in another guise: the server changes what it offers, and a block-based rule silently stops protecting you. An allowlist fails the other way — closed. Anything you didn’t explicitly approve, including renamed or newly added capabilities, simply doesn’t pass until you review and add it. To get the convenience of “everything except one,” use Allow if conditions are met: add every capability the server currently offers, then remove the one you don’t want. You end up with an explicit allowlist, so any capability the server adds or renames later still has to be reviewed before it can reach a client.

​

How a governed decision appears in logs

Feature-governance decisions are recorded so you can audit them. In your logs, a capability removed from a list because it didn’t match the allowlist is logged with the type gateway_feature_filtered, and a directly attempted call to a disallowed capability is logged as gateway_feature_blocked. This lets you confirm what a gateway is exposing and catch the moment a previously-passing tool stops matching — for example, when an upstream server renames or rewrites it.

​

Feature governance versus runtime rules

Feature governance and runtime protections are complementary layers, and it helps to keep them distinct:

• Feature governance decides which capabilities exist on the gateway — applied to tools, prompts, and resources, before any call is made. It is about exposure and least privilege.
• Runtime rules scan the content of allowed calls — applied to tool calls and results — and can block, redact, or rewrite them in flight.

Together they form defense in depth: governance shrinks the surface to only the tools you intend, and runtime rules inspect what flows through that smaller surface.

​

Further reading

​

External sources