Surface allowed_tools as a UI control in the agent builder for MCP tool scoping

[Aditya Bhaskar (InspectorAB)]

Technical Feedback

allowed_tools already exists as a config option when attaching MCP tools to an agent, so the backend capability for per-agent tool scoping is there. But it's only reachable as an API/config parameter, not exposed anywhere in the agent builder UI.

Today, connecting an MCP server through the agent builder grants access to the full discovered tool catalog, with no visible step to select a subset for that specific agent. For servers with 20+ tools, every schema lands in the model's context regardless of what the agent actually needs, which increases token overhead and the chance of the model picking the wrong tool from an oversized list.

Desired Outcome

Surface allowed_tools as a first-class step in the agent builder UI: when connecting an MCP server, show the discovered tool list and let the user check/uncheck which tools that specific agent can access instead of it only being settable via API/config.

Current Workaround

The only way around this today is deploying a separate, narrowly-scoped MCP server per agent, so each server's full catalog happens to match what that agent needs. That's real infrastructure overhead hosting, auth, and monitoring multiplied by the number of agents — for something that should be a config-time decision, not an infra-topology decision. Most teams can't reasonably do this for every agent they build.

[Jannik Reinhard (JayRHa)]

A per-agent tool selection step would make this much easier to operate. Useful acceptance criteria would be:

• Show discovered tool names and descriptions before attaching the server.
• Persist the explicit allowlist with the agent version and preserve it when reopening the agent in the portal.
• Require an explicit choice before newly discovered server tools become available to an existing agent.
• Keep tool scope distinct from server authentication and approval settings.

Since API-based scoping is already described here, a documented API configuration could also serve as an interim path without deploying a separate MCP server for every agent. It would help to document which API and agent types support that configuration and whether editing in the portal preserves it.