Why inventories drift
Developers and employees can configure local MCP connections directly on laptops, IDEs, and desktop clients without passing through a central gateway.
Use case
Discover shadow MCP before it becomes an unknown dependency.
Identify supported clients and server declarations from the edge where MCP adoption begins, while keeping configuration distinct from active use.
Talk to AxLoopDiscover from endpoints
Supported configuration paths, runtime evidence, and device context reveal MCP evidence that server-side inventories may not see.
Add ownership context
A useful finding connects the client, device, user, server, tool, version, destination, and approval state so teams can investigate safely.
Visibility before control
Discovery creates the evidence needed to assess risk, assign ownership, remove obsolete connections, or bring useful workflows into governance.
Common questions
Answers, briefly.
- What is shadow MCP?
- Shadow MCP is any MCP client, server, tool, or connection operating outside the approved inventory or without clear ownership and review, often configured directly on a developer laptop.
- Why can't a central registry find shadow MCP?
- A registry only knows what was registered. Local MCP servers configured in desktop clients and IDEs never pass through it, so discovery has to start on the endpoint where configuration lives.
- What should a shadow MCP finding include?
- The supported client, device or user scope, declared server, transport, safe executable identity, source, and capability classification where available. Active use and destinations require separate evidence.
- How often should shadow MCP be checked?
- Continuously. New servers can appear any day as developers experiment. Ongoing discovery keeps the inventory current instead of relying on periodic audits.
AxLoop AI
Start with evidence at the edge.
Discover what exists. Build toward understanding the interaction.