Learn how to audit MCP server files and tool configurations with a 6-step methodology, configuration checklist, and guidance on automating MCP server analysis at scale.
Security engineers new to auditing MCP configurations often conflate the server-side audit with the broader agent security review. These are related but distinct workstreams. Keeping them separate prevents scope creep and makes each audit tractable.
An MCP audit focuses on the infrastructure and configuration layer of the Model Context Protocol. The goal is to answer: what servers exist, how are they configured, what tools do they expose, and do those tools operate with appropriate authentication and least-privilege permissions?
In-scope items include:
An MCP audit does not cover model behavior, prompt processing, or the agent-side reasoning that decides which tools to call. Those concerns belong to a broader AI agent security review. Static code analysis of the server's underlying application logic is also out of scope here.
The distinction matters because conflating these scopes leads to ghost chasing: reviewing theoretical configuration signals without runtime evidence of what actually happened. An MCP audit answers what the server is configured to do. Runtime visibility answers what it actually did.
Manual auditing of MCP configurations is practical for a small, known server inventory. The following six steps give security engineers a repeatable methodology for auditing MCP server tools and files.
Step 1: Discover All MCP Server Connections in Your Environment
Before auditing anything, build your server list. Query each AI platform in use (Copilot Studio, n8n, Amazon Bedrock, ChatGPT Enterprise, and others) for registered MCP connections. Check developer workstations for local configuration files. Common locations include:
~/.cursor/mcp.json (Cursor)~/.config/claude/claude_desktop_config.json (Claude Desktop, local only)Document every server URL, transport type (stdio vs. HTTP/SSE), and the agent or workflow that invokes it.
Step 2: Catalog Configuration Files for Each Server
For each discovered server, locate and retrieve its primary configuration file. Run a dedicated scanner to surface known vulnerability patterns. The Rust-based mcp-audit tool provides an "npm audit for MCP servers" workflow:
mcp-audit scan --config path/to/your-mcp-config.json --severity high
For output formats compatible with CI pipelines or GitHub Code Scanning, use SARIF:
mcp-audit scan --config path/to/config.json --format sarif -o results.sarif
mcp-scan from Stytch offers complementary coverage, focusing on installed MCP server manifests rather than a single config file. Run both tools where possible to maximize coverage.
Step 3: Enumerate Tools Exposed by Each Server
Each MCP server declares a tool list. Request that list directly using the MCP protocol's tools/list method, or review the server's manifest file. For each tool, document:
Step 4: Verify Authentication Mechanism
Check whether each server enforces authentication before accepting tool calls. Unauthenticated MCP server connections are a high-severity finding. Verify:
Step 5: Review Permission Scope and Credentials
Identify what credentials the server uses to call downstream systems. Hardcoded credentials in configuration files are a critical finding. Check whether the server uses maker mode credentials (fixed author-level tokens), which means any agent invoker inherits the credential owner's full effective authority regardless of their own permissions.
Step 6: Inspect Audit Logs for Completeness
Confirm the server generates logs and that those logs capture tool call events, caller identity, and timestamps. Gaps in log coverage create visibility gaps that make incident response impossible. Check log destination, retention period, and whether logs are forwarded to your SIEM.
The table below maps the six highest-priority configuration items for auditing MCP files: where to find each one, what to check, and what red flags indicate critical risk.
Configuration ItemWhere to Find ItWhat to CheckRed Flag IndicatorsServer config filePlatform agent settings, mcp.json, or server root directoryServer URL, transport type, enabled tools list, versionWildcard tool permissions, unknown transport endpoints, outdated server versionsTool definitionstools/list response or manifest fileTool names, input schemas, downstream API targetsTool description does not match declared function; tools accessing systems outside declared scopeAuthentication configServer config or platform connection settingsAuth method (OAuth 2.1, API key, none), token scopesUnauthenticated connections; overly broad OAuth scopes; tokens with admin-level accessCredential storageEnvironment variables, config files, secrets manager referencesWhether credentials are hardcoded vs. injected at runtimeHardcoded secrets in config JSON; shared credentials across multiple servers; maker mode fixed tokensLog configurationServer config, platform audit settingsLog level, event types captured, log destination, retentionNo logging enabled; logs not forwarded to SIEM; tool call events not capturedNetwork bindingServer config, deployment manifestBound interface (localhost vs. 0.0.0.0), public endpoint exposureServer bound to all interfaces; publicly accessible endpoint without authentication; no rate limiting
The credential storage row catches the most critical findings in practice. A server bound to localhost with no authentication is dangerous. A server using maker mode credentials with admin-level Salesforce access and no log forwarding is a machine insider risk that has already materialized. AI agent privilege escalation flows through exactly these misconfigurations.
Each configuration item above has two dimensions worth separating:
Manual auditing works when you have a short, known server list. In most enterprise environments in 2026, that precondition does not hold.
The prerequisite gap. You cannot audit servers you do not know exist. Shadow MCP servers spun up by business teams in n8n workflows, servers embedded in Cursor configurations on developer laptops, and servers connected through Copilot Studio flows created without IT oversight all sit outside your known inventory. One enterprise security team discovered over 370 AI agents they had no record of, all created within a single platform. Each of those agents potentially carries MCP connections that have never been reviewed.
The community MCP ecosystem accelerates this problem. Hundreds of open-source MCP servers are available for installation. Developers and business users add them to local configurations and workflow builders without any approval process. By the time a security team attempts a manual audit, the server count has already grown significantly.
The cross-platform discovery problem. MCP connections do not live in one place. They appear in n8n workflows as embedded MCP nodes, in Cursor and AI coding assistants as local config files on individual developer machines, in Copilot Studio as connector configurations inside agent definitions, and in custom agent frameworks as programmatic MCP client calls inside application code.
No single platform gives you a unified view. Manual discovery requires querying each platform separately, correlating results by hand, and repeating the process every time a new agent is deployed. That is ghost chasing at the infrastructure level.
The operational math. A typical enterprise running multiple AI platforms can accumulate hundreds of agent-to-server connections within months of initial deployment. Auditing each connection manually, following the six steps above, requires significant analyst time per server. At scale, the math does not work. The tooling available to most security teams was built for human-scale activity, not machine-speed agent proliferation.
Automation in MCP security operates at two distinct layers. Keeping them separate prevents confusion about what each tool actually does.
Layer 1: Code-Level Configuration Scanning
Tools like mcp-audit and mcp-scan operate at the server configuration and manifest layer. They scan known config files for vulnerability patterns, flag hardcoded credentials, identify unauthenticated connections, and produce machine-readable outputs for CI pipelines. This is server-side scanner work. It is valuable, repeatable, and integrable into deployment workflows.
The limitation: these tools only scan servers you already know about and can point them at. They do not discover shadow MCP servers. They do not tell you which agents connect to which servers across platforms. They do not score risk based on what those servers can actually access inside your SaaS applications.
Layer 2: Infrastructure Inventory and Classification
Before code-level scanning is actionable, you need to know which servers exist. Infrastructure-level visibility answers the prerequisite question: what MCP servers are active in this environment, which agents connect to them, and which connections are sanctioned versus unsanctioned?
Runtime visibility is the prerequisite for everything else at this layer. Tools that operate at the infrastructure and identity layer, rather than the code layer, can surface the full server inventory across platforms, classify each server as sanctioned or unsanctioned, and score connections based on the effective authority those servers carry.
Where Obsidian Fits in the MCP Audit Workflow
Obsidian operates at the infrastructure inventory layer, not the code scanning layer. Obsidian surfaces which MCP servers exist across your AI agent environment, which agents connect to them, and what risk those connections carry based on the permissions and credentials involved. It does not scan server code. It does not act as an inline proxy between agents and servers.
The practical workflow looks like this:
mcp-audit and mcp-scan against the servers Obsidian surfaces, starting with the highest-risk connections first.This workflow converts an impossible manual audit into a tractable, prioritized queue. Configuration is not reality. Runtime truth means knowing which servers are actually active, which agents are actually connecting to them, and which connections carry the highest blast radius before you open a single config file.