How should organisations decide whether to keep an MCP tool or remove it?

Keep the tool only if it provides sandboxing, deterministic validation, authenticated access to a live system, or another capability the model cannot safely replicate. Remove it if it merely sequences commands, fetches docs, or wraps a terminal operation. That decision should be based on control value, not habit or legacy workflow design.

Why This Matters for Security Teams

An MCP tool is not just an integration choice. It changes the trust boundary between the model, the environment, and the systems the tool can touch. If a tool adds no meaningful control, it can increase the attack surface without improving safety or reliability. That is why the decision should be tied to security value, not whether the workflow feels convenient or modern.

For agentic systems, the key question is whether the tool provides a capability that the model cannot safely do on its own, such as authenticated access, deterministic validation, or sandboxing around risky actions. If it does not, then the tool may simply provide another path for prompt injection, command chaining abuse, or secret exposure. The OWASP Agentic AI Top 10 is useful here because it frames tool use as a security design issue, not a productivity feature.

Security teams also need to think about governance. A tool that remains in place should have a clear owner, documented purpose, logging, and a control objective that can be tested. If that cannot be stated plainly, the tool is usually carrying legacy value rather than security value. In practice, many security teams encounter tool sprawl only after an incident review shows that the “helpful” MCP layer had become an unmonitored path to sensitive systems.

How It Works in Practice

The decision process is best handled as a control review, not a product debate. Start by mapping what the MCP tool actually does, then compare that function against the risk it introduces. If the tool is only translating natural language into routine actions, it may be duplicating capabilities that the model, orchestration layer, or existing automation already provide. If it brokers access to a live system, enforces checks, or constrains execution, it may justify retention.

A practical review usually looks at four questions:

• Does the tool enforce a security control the model cannot enforce alone?
• Does it reduce risk through validation, approval, or bounded execution?
• Can the same outcome be delivered more safely through a narrower interface?
• Is there evidence of logging, authorization, and change control?

That last point matters because an MCP tool often becomes the place where identity, permissions, and secrets intersect with agent behaviour. If the tool authenticates to a target system, it should be treated like a privileged integration, not a convenience wrapper. The OWASP Top 10 for Agentic Applications 2026 is helpful for evaluating whether the tool is adding exposure through excessive authority, weak boundaries, or unsafe action handling.

Retention is usually justified when the tool adds deterministic safeguards, such as schema validation before execution, allowlisted commands, or a human approval checkpoint for sensitive operations. Removal is usually justified when the tool simply sequences commands, fetches documentation, or wraps a terminal operation that can be done more safely in a narrower control plane. These controls tend to break down when the tool is given broad network reach and persistent credentials because the model can be steered into actions the operator did not intend.

Common Variations and Edge Cases

Tighter tool governance often increases integration overhead, so organisations need to balance reduced attack surface against engineering effort and operational friction. That tradeoff is real, especially when teams have embedded MCP tools into fast-moving developer or support workflows.

There is no universal standard for when a tool is “worth keeping,” but current guidance suggests a few common exceptions. A tool may be justified if it provides a unique safety function, such as isolating execution in a sandbox, converting free-form input into a deterministic action, or mediating access to a system that should never be directly exposed to the model. In those cases, the tool is part of the control design, not just the interface.

Edge cases often appear in environments with hybrid legacy systems, high-volume support desks, or regulated operations. A tool that looks redundant in a lab may be essential in production if it enforces approvals, separates duties, or prevents direct access to secrets. Conversely, a tool that once made sense can become unnecessary once the underlying platform gains native policy enforcement. The right answer can change over time, so this decision should be revisited during architecture review, not frozen into an early implementation choice.

For teams formalising agent governance, the safest pattern is to keep only the minimum toolset needed to preserve control value and remove anything that exists mainly for convenience. That is the difference between a managed capability and an accidental privilege path.

Related resources from NHI Mgmt Group

• How should organisations decide whether to keep using traditional MFA?
• How can organisations decide whether to buy a standalone red teaming tool or a broader platform?
• How do organisations decide whether MCP should use OAuth, mTLS, or federation?
• How can organisations tell whether an MCP integration is safe to keep in production?