An MCP server your agent uses exposes 12 tools, but your security team requires the agent to only be able to invoke 3 specific tools from that server. How should you enforce this restriction?
Select an answer to reveal the explanation.
Short Explanation and Infographic
An MCP allow list is the security bouncer at the door — the server might offer 12 tools, but the allow list only lets 3 onto the dance floor. You configure it in the agent definition alongside the MCP server entry, listing the specific tool names the agent is permitted to call. The runtime enforces this at call time, refusing any tool invocation not on the list, without requiring any changes to the MCP server itself.
Full explanation below image
Full Explanation
MCP allow lists provide fine-grained control over which tools an agent can invoke from a given MCP server. This is a client-side (agent-side) restriction — the server continues to advertise all its tools, but the agent runtime filters the available set down to only those explicitly permitted in the allow list. This is the correct approach when you cannot or do not want to modify the MCP server.
Option A is incorrect for two reasons. First, modifying the MCP server source code to remove tools is an invasive change that affects all consumers of that server, not just this agent. Second, if the server is a shared or externally maintained service, you may not have the ability to modify it. The allow list approach maintains server integrity while still enforcing per-agent restrictions.
Option B is correct. MCP allow lists are configured within the agent's tools section, nested under the specific MCP server entry. A tools_allowed (or equivalent) array lists the exact tool names the agent may call. When the model attempts to invoke a tool not on the list, the runtime rejects the call before it reaches the MCP server. This provides defense in depth: even if the model is prompted to call a restricted tool, it cannot succeed.
Option C is incorrect. There is no max_tools parameter in the MCP agent specification. Tool selection by the model is based on semantic relevance to the current task — it is not a numerical limit, and it would not provide security guarantees since a different 3 tools might be selected on each run.
Option D is incorrect. GitHub Actions environment protection rules govern when workflows can run and which environments they can deploy to. They do not intercept MCP tool calls at runtime, and they operate at the workflow level, not within an agent's tool invocation path.
Key exam point: allow lists are agent-side configuration; they restrict what the agent can call without touching the MCP server definition.