Configuration & Environment
An MCP server manifest that declares tools without specifying an authentication mechanism exposes every registered tool to unauthenticated callers. Sibling rules covering the same auth-missing-on-transport family at code level: MCP-217 (tools/list endpoint), MCP-268 (local HTTP).
CWE-306 (Missing Authentication for Critical Function) manifests here when an MCP server's JSON manifest omits or explicitly disables the `auth` / `authentication` field while still advertising callable tools. Any client — legitimate or malicious — can invoke those tools without presenting credentials. The flaw exists at the configuration layer, meaning no amount of correct application code compensates for the absent declaration.
MCP servers are designed to be discovered and invoked autonomously by LLM agents, which means a missing auth field is not a theoretical gap — an agent will call the tool the moment it appears in the manifest. Unlike a traditional REST API where a human developer consciously navigates to an endpoint, an LLM-driven pipeline will enumerate all advertised tools and invoke them without pausing to question whether credentials are required. Compound this with tool composition: one unauthenticated tool can chain into privileged downstream tools, amplifying the blast radius of the missing control.
// mcp.json — manifest with tools, auth explicitly disabled |
{ |
"name": "data-export-server", |
"version": "1.0.0", |
"auth": "none", |
"tools": [ |
{ |
"name": "export_records", |
"description": "Export all customer records as CSV.", |
"inputSchema": { |
"type": "object", |
"properties": { "table": { "type": "string" } } |
} |
} |
] |
} |
// mcp.json — manifest with bearer auth declared |
{ |
"name": "data-export-server", |
"version": "1.0.0", |
"auth": "bearer", |
"tools": [ |
{ |
"name": "export_records", |
"description": "Export all customer records as CSV.", |
"inputSchema": { |
"type": "object", |
"properties": { "table": { "type": "string" } } |
} |
} |
] |
} |
MCPSafe parses JSON manifests and evaluates two sub-rules: `manifest-explicit-no-auth` fires at ERROR when `auth` resolves to `none`, `false`, or `null`, or when `authentication` is `null`; `manifest-no-auth-declared` fires at MEDIUM when a `tools` array is present but none of the known auth keys (`auth`, `authorization`, `bearer`, `oauth`, `mtls`, `apiKey`, `api_key`, `basic`, `token`, `authToken`) appear anywhere in the top-level manifest object. Manifests that contain no `tools` array, or that are scoped to stdio-only transport with an explicit inline comment flag, are excluded from the second sub-rule.
See the full threat catalog for every documented detection.
MCPSafe runs this check — and every other rule in the catalog — on any MCP server you paste in.
Scan now