MCP Security Scanner

Foo Guard inspects configuration before execution. If an agent file describes Model Context Protocol tools, those tool declarations are reviewed the same way as any other tool: filesystem access, network access, database access, shell execution, credentials, permissions, and whether a human must approve a change.

Foo Guard does not start MCP servers, speak the MCP protocol, or probe a running server. A top-level mcpServers list is not launched and is not treated as a dynamic capability inventory. The security scan evaluates the normalized tools, permissions, credentials, and autonomy you declare in JSON or YAML.

Why MCP configuration is a security boundary

An MCP client is often a short config that names servers and the tools those servers expose. The risk is in that declaration. A filesystem server pointed at a home directory, a GitHub server that can open pull requests, and a shell tool with no approval step are different products from a read-only documentation search.

Those choices are visible before the process starts. Waiting until a tool call happens means the risky capability is already installed. An MCP security scanner that reads the config can fail a change while it is still a diff.

What Foo Guard will flag

Map each MCP tool onto the fields Foo Guard already understands. The rules then apply without a separate MCP runtime.

A local desktop assistant that lists filesystem, GitHub, and Postgres MCP servers is scanned through those explicit tool entries. The server command lines in mcpServers are not executed and are not, by themselves, a finding. If the tool entries omit the dangerous capability, the scan will not invent it from the server package name.

Inspect configuration before execution

Use the browser analyzer to review one file. Use the CLI or GitHub Action in CI when the MCP client config lives in a repository. Team workspaces can publish a Foo Guard Security check on the pull request that changes the file. The check reports pass or fail from policy. It does not attach a SARIF file, and it does not connect to the MCP server under test.

Secret-like values in the configuration are detected as credential findings. Foo Guard does not call the upstream service to see whether a token still works. Saved snapshots redact those values.

A configuration that can be reviewed

Write the dangerous part in the tool entry, not only in the server launch command. This fragment is the kind of input Foo Guard can score. The mcpServers block can sit in the same file for the client that will start those processes. Foo Guard will not run npx and will not open the filesystem path.

tools:
  - name: mcp_filesystem_read
    description: Read files exposed by a local filesystem server
    readsData: true
    accessesFilesystem: true
    modifiesResources: false
  - name: mcp_github_create_pr
    description: Open a pull request through a GitHub MCP server
    modifiesResources: true
    arbitraryHttp: true
    requiresApproval: true

The filesystem tool is a read. The pull-request tool is a write that also makes arbitrary HTTP calls, and it records that a person must approve it. Drop requiresApproval on a tool that modifies resources and the approval rules have something to evaluate. Leave arbitraryHttp false when the tool does not call the network, including when some other field says the network is restricted.

How this fits the rest of the product

MCP scanning is not a second product. It is the same AI agent security scanner applied to MCP-style tool definitions. Repository thresholds still come from .fooguard.yml, and merge blocking still depends on GitHub and CI enforcement.

Supported input is JSON and YAML that Foo Guard can normalize. There is no IDE extension that watches an MCP config as you type, and there is no scheduled re-scan of a running server. When the file changes in Git, scan that revision.

Scan an MCP-style configuration