Supported configuration formats
JSON and YAML agent configuration formats supported by Foo Guard.
Page text and source link for your AI assistant. Nothing is sent automatically.
Foo Guard analyzes supported JSON and YAML agent configuration structures used by the normalized agent model.
Use consistent field naming and valid JSON/YAML syntax. Invalid syntax produces configuration errors rather than rule findings.
Native MCP configuration files
Paste or upload the existing JSON or YAML file; no conversion to Foo Guard's agent schema is needed for these declaration formats:
- Cursor and Claude: a top-level
mcpServersobject keyed by server name. - VS Code / Copilot: a top-level
serversobject from.vscode/mcp.json. The portablemcpServersobject is also supported. - Continue: a top-level
mcpServerslist, with a uniquenameon each entry inconfig.yaml.
For example, this VS Code configuration is inspected directly:
{
"servers": {
"example": {
"type": "stdio",
"command": "npx",
"args": ["example-mcp-server@1.2.3"]
}
}
}The equivalent Continue declaration is:
name: Example configuration
version: 1.0.0
schema: v1
mcpServers:
- name: example
command: npx
args: [example-mcp-server@1.2.3]These examples illustrate syntax, not a package recommendation. Findings retain paths in the original document. The same normalization is used by browser assessments, the CLI, and repository scans of selected files; this does not change which files a repository selects for scanning.
Coverage and limits
Foo Guard checks declared connection settings and supported launch dependencies, including non-loopback HTTP connections and unpinned npx packages. It does not execute commands, contact servers, resolve variables, read referenced files, or infer runtime capabilities from package names. A configured server is not evidence that it is running. Disabled declarations are still inspected as stored configuration.
Use strict JSON (without comments or trailing commas) or YAML. Nested client settings, TOML, client-specific permissions and sandbox settings, and runtime capability verification are not covered by these adapters. Continue uses imports must be replaced with their resolved server declarations before scanning. A successful scan is not validation of the client's entire configuration and does not establish runtime safety.
The Library Find tool servers and Gateway import flows have separate format support; these additions apply to static scanning.
Format references: VS Code MCP configuration and Continue config.yaml.
Documented MCP package context
New static assessments recognize direct npx registry declarations for @modelcontextprotocol/server-filesystem and @modelcontextprotocol/server-memory in supported MCP containers. Open MCP package context in a new or saved assessment to see the original declaration path, catalog version, and reviewed documentation source.
This is package-family context inferred from documentation, not an observed tool inventory or verification of the installed package version. It never supplies rule capability flags and does not change findings, severity, scores, or policy decisions. Unknown packages are not treated as safe. No package is downloaded, started, or contacted.
The first catalog covers direct npx declarations and its supported --package options. Shell wrappers, Docker, uvx, aliases, local paths, and Git/URL dependencies remain outside this catalog. Existing assessments are not retroactively reinterpreted; run a new scan to obtain package context. Repository scan detail and exported reports do not yet present this additional context.
Catalog updates must preserve published versions and pinned source revisions for saved assessments, include an official source and scope limitations, and pass tests proving that package context cannot influence deterministic findings or scores.