Seven Tools to See Who's Using Which MCP Servers in 2026

MCP servers spread through engineering teams in 2026 the same way unsanctioned SaaS once did, quietly and without a registry. Anthropic’s Model Context Protocol launched in late 2024 as a standard way to wire AI assistants into tools and data, and by this year more than 10,000 public servers were live. Developers spin them up on local ports and inside IDE plugins, each one holding OAuth tokens to GitHub, Google, or Notion.

The catch is that almost no one in IT can see them. A typical 100-engineer org runs 15 to 30 unvetted MCP configs, and roughly 40% of public servers ship with no authentication at all. An AI agent can reach real company data through a connection security never approved or logged.

The seven tools below each answer a version of the same question from a different angle. Some discover servers across your whole stack, others enforce identity and policy at runtime. Together they cover who is connecting to which MCP servers, what those servers can touch, and how to govern that access.

Table of Contents

• Torii
• Lasso Security
• Operant AI
• Obot AI
• Lunar.dev
• Pomerium
• Descope

Torii

Torii comes at MCP visibility from the SaaS side rather than the network side. It’s an AI management platform that discovers every application running across a company, and that net now pulls in AI tools and the SaaS those MCP servers actually connect to. Instead of sniffing localhost ports, Torii reads expense and finance records, SSO and OAuth sign-in logs, direct integrations, and a browser extension, then ties each tool back to the named employees using it.

That gives IT and finance one inventory that covers who adopted a given AI tool, what it costs, and who still has access. When someone leaves, automated offboarding revokes that access so stray tokens don’t linger. The Torii platform pairs this discovery with renewal alerts and access-request intake, so governance runs as a loop rather than a one-time audit.

Where Torii fits the MCP problem:

• Surfaces shadow AI tools through finance, SSO, and browser signals
• Maps every app and account back to a specific employee
• Revokes access automatically during offboarding
• Tracks spend and renewals alongside access

Pros:

• Finds AI tools other scanners miss by reading spend and identity data
• Connects every tool and login to a named person
• Closes the loop with automated offboarding and renewals
• Covers the full SaaS estate, not just MCP traffic

Cons:

• Priced for enterprise coverage, so it isn’t the cheapest option
• Focused on SaaS and shadow IT, with no on-premise runtime control

Lasso Security

Lasso Security takes the security-native route and starts by finding every MCP server in use. It automatically discovers servers across Claude Code, Claude Desktop, Cursor, Windsurf, and custom agents, then scores each one on risk based on its permissions, actions, and tool descriptions. A server that can delete files or reach production data ranks higher than one that only reads a calendar.

From there, Lasso monitors every tool call in real time to catch prompt injection and memory poisoning. It scans tool descriptions for hidden instructions that try to hijack an agent. Built-in data loss prevention spots and masks PII, API keys, and credentials moving through those calls, and audit trails map back to NIST, OWASP, and MITRE frameworks. The Lasso MCP security product also ships a self-hostable open-source gateway on GitHub for teams that want to run it themselves.

What Lasso brings to MCP oversight:

• Automatic discovery and risk scoring for every connected server
• Real-time scanning for prompt injection and poisoned tool descriptions
• DLP that masks secrets and PII inside tool calls
• Audit mapping to NIST, OWASP, and MITRE

Pros:

• Risk scores make it easy to triage which servers to lock down first
• Open-source gateway option alongside the managed product
• Strong coverage of injection and data-leak threats

Cons:

• Security focus means less spend or license context
• Newer vendor with a smaller public track record

Operant AI

Operant AI runs at the network layer and treats MCP traffic as something to defend in real time. Its MCP Gateway sits inside the AI Gatekeeper platform, earned a mention in Gartner’s MCP Gateways innovation report, and is listed on the Okta Integration Network. The core idea is a framework Operant calls 3D Runtime Defense, short for discover, detect, and defend.

The discover step auto-catalogs every MCP tool and agent across cloud and Kubernetes deployments, then draws live traffic graphs of what talks to what. Detect assigns trust scores to servers and flags untrusted ones, while defend blocks them outright and enforces least-privilege execution inside trust zones. Sensitive data crossing an MCP boundary gets redacted on the fly. Because Operant’s gateway ties into Okta, identity-aware rules extend to non-human agent identities running in AWS Bedrock and Kubernetes.

Where Operant stands out:

• Live traffic graphs across cloud and Kubernetes deployments
• Trust scoring with real-time blocking of untrusted servers
• Least-privilege enforcement inside defined trust zones
• Identity-aware controls for agent and machine identities

Pros:

• Built for scale across multi-cloud and container environments
• Gartner recognition and Okta integration add credibility
• Blocks threats live rather than reporting them after the fact

Cons:

• Runtime depth suits platform teams more than lean IT shops
• Heavier setup than a discovery-only tool

Obot AI

Obot AI centralizes governance by pulling everything into one catalog. Its MCP Gateway aggregates the tools, resources, and prompts from every connected server into a single unified view, plus a Skills Registry, so teams only ever connect to servers an admin approved. That curated list becomes the control point.

Access control in Obot goes deeper than server-level permissions allow. It enforces access at the individual tool level, covering not just which servers a person can reach but which tools inside those servers they can call, with Auditor, Owner, and user roles. Protocol-level audit logging captures connection setup, tool execution, and lifecycle changes, and tracks request rates, latency, and errors for each interaction. Network egress control stops a server from calling destinations it shouldn’t. The Obot gateway supports local, remote, multi-tenant, and composite servers, and runs open-source, in the cloud, or on Kubernetes.

What Obot puts in one place:

• A single approved catalog of tools, resources, and prompts
• Tool-level access roles, not just server-level
• Protocol audit logs covering setup, execution, and changes
• Egress control to block unauthorized outbound calls

Pros:

• Tool-level permissions give fine-grained control
• Open-source and self-hostable for full ownership
• Handles composite and multi-tenant server setups

Cons:

• Catalog model needs upkeep as servers change
• Self-hosting adds operational work

Lunar.dev

Lunar.dev wraps everything behind a single gateway and vets servers before they ever go live. Its product, MCPX, is a production-grade aggregating gateway where clients connect only to MCPX, which then proxies and routes to the backend servers, with discovery built in for local and remote services. The standout is what happens before a server joins the registry.

Lunar runs a risk-evaluation sandbox that checks each server for data-exposure paths before an admin publishes it to the internal registry. Once live, it logs a full attribution chain that traces a single action from user to agent to model to server to the exact tool call, with immutable logs and Prometheus metrics. A feature called tool hardening locks specific tool parameters to fixed values so an agent can’t pass unsafe inputs. Admins curate the approved registry through Lunar.dev and bundle capabilities into Tool Groups assigned per team.

Where Lunar.dev goes deep:

• A sandbox that risk-checks servers before they reach the registry
• Full attribution from user down to the individual tool call
• Parameter-level tool hardening against unsafe inputs
• Per-team Tool Groups built on a curated registry

Pros:

• Catches risky servers pre-production, not after deployment
• Attribution chain pinpoints exactly who did what
• Parameter locking blocks unsafe tool inputs

Cons:

• Gateway model means routing all traffic through MCPX
• Aimed at teams comfortable running infrastructure

Pomerium

Pomerium is a zero-trust proxy that keeps internal MCP servers off the public internet. It sits between MCP clients and your servers, terminates TLS, and handles all authentication at the perimeter so the servers themselves never face the open web. Worth flagging upfront: its MCP support is still experimental as of mid-2026.

Pomerium’s auth model splits into two distinct layers for client and server credentials. Users sign in downstream through your existing identity provider, while Pomerium quietly manages and refreshes the upstream OAuth tokens for connected services like GitHub, Google, Notion, and Linear, so the MCP client never touches those credentials. Fine-grained rules use an mcp_tool criterion in Pomerium Policy Language for per-tool allow and deny decisions enforced on every request, rather than relying on static scopes. Every tool call is logged with its method, name, and parameters. Autonomous agents get their own service-account identities through Pomerium.

What Pomerium controls at the perimeter:

• Internal MCP servers shielded from the public internet
• Two-layer OAuth that hides upstream credentials from clients
• Per-request, per-tool policy rather than static scopes
• Service-account identities for autonomous agents

Pros:

• Open-source zero-trust proxy with a mature policy language
• Per-request tool rules give precise control
• Keeps servers and credentials out of client reach

Cons:

• MCP support is still experimental
• Proxy setup assumes some infrastructure know-how

Descope

Descope handles the identity and authorization layer that MCP access depends on. Its Agentic Identity Hub, at version 2.5 as of June 2026, lets your own service act as an OAuth 2.1 provider through Inbound Apps, so MCP clients authenticate with delegated, least-privilege scopes. Outbound Apps handle the reverse, managing the credentials agents need to call external services.

Descope assesses risk at the moment of registration, before any credentials exist. Dynamic Client Registration and CIMD evaluate an agent first, and each agent then receives a dedicated identity with per-tenant, per-tool scopes plus progressive elevation as trust grows. New CIBA flows require out-of-band human approval before an agent can invoke a sensitive tool. A central control plane watches for rogue agents, ships audit logs to your SIEM, and layers on top of existing identity providers, so teams bring their own auth rather than rip and replace. You can see the full picture through Descope.

What Descope governs:

• Your service acting as an OAuth provider for inbound MCP clients
• Managed credentials for agents calling outbound services
• Risk checks at registration before credentials exist
• Human approval gates for sensitive tool calls

Pros:

• Purpose-built for agent and MCP identity
• Human-in-the-loop approval for risky actions
• Layers onto existing identity providers

Cons:

• Identity focus, not server discovery or spend
• Best value for teams already building agent infrastructure

How to Choose an MCP Visibility Tool

The right pick depends on where your MCP risk actually sits. Teams worried about runtime threats lean toward Operant AI or Lasso Security, while those standardizing access through a gateway look at Obot AI or Lunar.dev. Pomerium fits zero-trust shops keeping servers off the public web, and Descope suits anyone building agent identity from the ground up.

Before any of that, though, you have to know which AI tools and MCP connections exist at all. That discovery problem is where Torii starts, finding shadow AI across the stack and tying it back to the people behind it.

Frequently Asked Questions

Why does MCP visibility matter now? +

MCP visibility matters because thousands of public servers exist and many lack authentication. A typical 100-engineer org runs 15 to 30 unvetted configs and roughly 40% expose OAuth tokens to GitHub, Google, or Notion, risking unapproved data access.

How do discovery tools find MCP servers? +

Discovery tools use different signals: platforms like Torii read SSO, expense, finance, and browser data to map apps to users, while other tools scan network traffic, local ports, agent registries, and integrations to detect MCP servers and linked SaaS accounts.

What runtime protections block unsafe MCP servers? +

Runtime protections include real-time traffic inspection, trust scoring, least-privilege enforcement, prompt-injection detection, redaction of sensitive data, and live blocking of untrusted servers. Vendors like Operant and Lasso provide these controls across cloud, container, and runtime environments.

How can gateways and registries help govern MCP access? +

Gateways and registries centralize governance by requiring servers to register before use, offering pre-production sandboxing, tool-level permissions, parameter hardening, and a curated catalog so admins control which tools, prompts, and teams may access specific server capabilities.

How should organizations protect OAuth tokens and agent identities? +

Protect tokens by terminating authentication at the perimeter, hiding upstream credentials from clients, issuing dedicated agent identities with least-privilege scopes, using dynamic client registration, and enforcing human approval gates for sensitive tool calls, as in Pomerium and Descope.

Which factors should guide choosing an MCP visibility tool? +

Choose based on where risk lives: runtime threat defense (Operant, Lasso) versus discovery and spend visibility (Torii), gateway governance (Obot, Lunar), zero-trust perimeter (Pomerium), or agent identity controls (Descope), plus team size and infrastructure maturity.