How do you audit which MCP servers a coding agent has connected?

Collect configuration from every location an MCP server can be declared, then record for each entry the server identity, transport, authentication scope, and full tool list. Configuration lives in at least four places: a project-level file such as .mcp.json committed to the repository, a user-level config in the developer's home directory, IDE-specific settings, and any organization-level policy file. Auditing only the committed one misses most of the estate.

For each server, capture what it is and what it can do. Server name, source URL or launch command, whether it runs locally or remotely, the OAuth scopes or API keys it holds, and the complete set of tools it exposes with their descriptions. The tool descriptions matter because they are instructions the agent follows, not documentation for humans.

Then check three things that periodic auditing exists to catch. Whether any server has changed its tool descriptions since approval, which is the rug-pull pattern where a benign server updates to exfiltrate on the next call. Whether any server is unpinned and pulling a floating version. Whether any holds credentials broader than the task requires, which is common when a server ships with a single all-scopes token.

Do this on a schedule and at every configuration change, because the population shifts constantly. A developer adding a server takes about ten seconds and generates no ticket.

Akto Atlas automates MCP server discovery across endpoints, inventorying connected servers, their tool surfaces, and their credential scopes, including the ones that never appeared in a committed config file.

An unaudited MCP server is an unreviewed dependency with a live token.