Feature Governance

Documentation Index

Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt

Use this file to discover all available pages before exploring further.

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. 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:

• Allow all — every capability of that type passes through. Convenient, but exposes the full surface.
• 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. 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.

​

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