When a developer wires an AI coding assistant or agent into a Model Context Protocol (MCP) server, that connection rarely shows up in a traditional SBOM. There's no package.json entry, no import statement that a dependency scanner recognizes as a "dependency" — just a client object instantiated somewhere in application code that opens a channel to an external tool provider. On August 4, 2025, Snyk shipped an answer to that blind spot: it expanded its AI Bill of Materials (AI-BOM) to detect and map MCP servers directly from source code, producing a CycloneDX 1.6 manifest that shows exactly which servers, tools, and resources an AI application talks to. This post walks through how that detection mechanism actually works, based on Snyk's published documentation, and what it does and doesn't cover.
What Problem Is Snyk AI-BOM's MCP Detection Actually Solving?
It's solving the problem that MCP connections are invisible to conventional software composition analysis (SCA) tools because they're runtime protocol relationships, not package manifest entries. A team can add langchain-mcp-adapters to requirements.txt and an SCA scanner will flag that one library — but it has no way of knowing that the code then uses that library to open a stdio_client connection to an internal "PaymentServer" that exposes a "chargeCard" tool, or a public MCP server pulled from an unvetted GitHub repo. Snyk's own framing calls this the difference between "what's in your AI stack" and "where it runs": an AI-BOM without MCP visibility lists the SDK, but not the servers, tools, or data sources the SDK is actually being used to reach. Snyk's expanded AI-BOM, part of an August 2025 release Snyk called "Secure At Inception," was built specifically to close that gap by treating MCP client-server relationships as first-class components in the bill of materials.
How Does Snyk Actually Detect an MCP Server in Application Code?
It uses static source code analysis, not runtime traffic inspection or network scanning. Per Snyk's documentation, running snyk aibom against a codebase parses source files looking for known MCP client instantiation patterns — for example, the standard mcp Python library's ClientSession and stdio_client/streamablehttp_client calls, or usage through higher-level frameworks that wrap MCP such as pydantic-ai, openai-agents, langchain-mcp-adapters, and smolagents. As of the current CLI (v1.1298.3 or later), this analysis runs across Python, Java, JavaScript, and Go projects. When the scanner finds a client instantiation, it follows the code to identify the server it connects to (Snyk's own example traces a client through to a server it names "MathServer") and the tools or resources that server exposes (in that example, an "add" tool). Because this is static analysis of source, it can surface MCP connections without ever executing the application or the MCP server itself — but it also means detection is bounded by which client libraries and coding patterns Snyk's parser recognizes, which Snyk describes as "a growing number of popular libraries and patterns" rather than a fixed, complete list.
What Does the Resulting AI-BOM Actually Contain?
It's a CycloneDX v1.6 JSON document with a dependency graph, not a narrative report. Each MCP client becomes a component with a unique identifier, each detected server becomes a linked component with its declared name, and each tool or resource the server exposes is captured underneath it — so the manifest reflects the full chain from application → client → server → tool. The same command also inventories other AI supply chain elements in one pass: foundation models like GPT-4, open-weight models like Llama-4 (with model cards and licensing metadata where available), and agent/tool-calling framework usage. Output options extend beyond raw JSON: the --html flag embeds a visualization of components and relationships, --upload (paired with --repo) persists the AI-BOM to a Snyk Organization for tracking over time, and --json-file-output (available from CLI v1.1303.0) writes the manifest to a file instead of stdout. The command exits 0 on a successful scan, 2 on failure, and 3 if it finds no supported files in the target directory — a practical signal that the codebase either has no AI/MCP usage or uses patterns the scanner doesn't yet recognize.
Does AI-BOM Detection Also Check Whether an MCP Server Is Vulnerable?
No — AI-BOM's MCP detection is inventory, not vulnerability assessment; that's handled by a separate, complementary tool. Snyk pairs AI-BOM with an MCP/agent scanner (distributed as snyk-agent-scan, installable via uvx snyk-agent-scan@latest) that targets a different layer: instead of parsing application source, it enumerates MCP servers actually configured on a developer's machine by reading the local configuration files of tools like Claude Desktop, Claude Code, Cursor, Windsurf, VS Code, Gemini CLI, and roughly a dozen other supported agent clients. Once it finds a configured server, the scanner connects to it, retrieves its tool descriptions, and checks for known risk patterns — prompt injection, tool poisoning, tool shadowing, and "toxic flows," where chained tool permissions or data paths combine in ways that let one compromised or malicious tool influence another. Because this step involves actually connecting to and invoking configured MCP servers, Snyk documents that it prompts for user consent before executing stdio server commands and recommends running it in a sandboxed environment when scanning untrusted third-party configurations. The two tools are meant to be read together: AI-BOM answers "what MCP servers does this application depend on," and agent-scan answers "which MCP servers are actually running on this machine and are any of them dangerous."
What Is Toxic Flow Analysis and How Does It Relate to MCP Detection?
Toxic Flow Analysis (TFA) is a preview-stage detection framework Snyk introduced alongside the expanded AI-BOM to catch multi-step risks that a simple server inventory can't reveal on its own. Rather than evaluating a single MCP server or tool in isolation, TFA looks at the relationships between tools and servers across an agentic workflow — for instance, a tool that ingests untrusted external content (a webpage, an email, a file) feeding directly into a second tool that has write access to a sensitive system, with no validation step in between. Snyk describes this as identifying indirect prompt injection, tool poisoning, and runtime exfiltration paths that emerge only from how components are chained together, not from any one component's code. Because TFA depends on the same MCP dependency graph that AI-BOM's detection produces (client → server → tool chains), the two capabilities are architecturally linked: AI-BOM builds the map, and TFA analyzes the map for dangerous paths through it.
What Are the Practical Limits of This Detection Approach?
Coverage is bounded by supported languages and known client patterns, and detection stops at the source-code boundary. The snyk aibom command currently supports four languages (Python, Java, JavaScript, Go), so MCP usage in a codebase written in, say, Rust or C# won't be picked up by this static analysis path today. Within supported languages, detection depends on recognizing specific library calls and idioms; an MCP client wired up through a bespoke or unusual pattern that doesn't match Snyk's known signatures may not surface in the AI-BOM even though the connection exists at runtime. And because AI-BOM itself doesn't execute code or connect to servers, it can tell you a server named "MathServer" is referenced in code without independently verifying that server's identity, ownership, or trustworthiness — that verification is the job of the separate agent-scan tool, which does connect to configured servers and inspect what they actually offer. Teams evaluating this capability should treat AI-BOM as an inventory foundation that needs to be paired with runtime/configuration scanning and policy enforcement to become a complete MCP risk-management workflow, which is consistent with how Snyk itself packages the two tools together.
How Safeguard Helps
Whichever scanner produces the inventory, the underlying challenge is the same one supply chain security teams have faced with every prior generation of dependencies: an AI-BOM or MCP server list is a point-in-time snapshot, and the servers, tools, and permission chains it describes keep changing as engineers add new agent integrations, swap MCP implementations, or connect to third-party servers outside any sanctioned catalog. Safeguard focuses on turning that kind of inventory into continuous, enforceable posture — correlating MCP and AI component data against known-vulnerable versions, flagging newly introduced servers or tool permissions that fall outside policy, and giving security teams a single place to track drift across every repository and environment rather than re-running a scan and re-reading a manifest by hand. If your organization is already generating AI-BOM or MCP inventory data through tools like Snyk's, Safeguard can help operationalize that data — turning static visibility into ongoing detection, alerting, and remediation workflows across your software supply chain.