MCP Declaration Validation: Reference Servers Adopt "Fail Closed" Security Posture

A new PR to the Model Context Protocol servers repository adds strict validation for tool/resource/prompt declarations at startup. When an MCP server encounters an unknown declaration in its manifest, it now fails immediately rather than silently ignoring it. This "fail closed" approach is a meaningful security hardening for the growing MCP ecosystem.

About the Contributor

davidahmann has been contributing to MCP infrastructure, previously adding a deterministic CI check-state classifier to improve build reliability. This PR continues a theme of hardening MCP's reference implementations for production use.

The Problem: Silent Acceptance of Bad Configuration

MCP servers load configuration at startup that declares what tools, resources, and prompts they expose. Before this change, if the configuration contained typos or unknown entries, servers would silently ignore them:

{
  "tools": ["read_file", "write_flie"],  // typo: "flie"
  "toools": ["search"]  // typo: "toools"
}

In this example, write_flie would be silently skipped (unrecognized tool), and toools would be silently ignored (unrecognized section). The server would start successfully but with fewer capabilities than intended.

Security implication: Silent failures mask misconfiguration. A security-critical tool that's typo'd away creates a false sense of protection — operators think a capability is active when it isn't.

What Changed Technically

The PR adds declaration manifest validation across four core MCP servers:

everything — the reference "kitchen sink" server
filesystem — file operations server
fetch — HTTP request server (Python)
git — Git operations server (Python)

Validation now fails deterministically on:

Unknown sections (e.g., toools instead of tools)
Non-array section values
Non-string entries within arrays
Unknown declaration names (e.g., write_flie)

Each server has targeted tests validating these failure modes.

Why "Fail Closed" Matters

The security principle of "fail closed" (also called "fail secure") means that when something goes wrong, the system defaults to a secure state. In networking, a fail-closed firewall blocks traffic when it can't determine if the traffic is allowed. In MCP, a fail-closed validator blocks startup when configuration is ambiguous.

The alternative — "fail open" — would be to accept the configuration and hope for the best. This is convenient for development but dangerous in production, where silent misconfiguration can create security gaps.

Ecosystem Maturity Signal

This PR is part of a broader pattern in the MCP ecosystem:

Security audits revealed vulnerabilities in core servers
Cross-platform fixes hardened path handling
SECURITY.md updates moved to GitHub Security Advisories

As MCP moves from experimental to production use, reference implementations are adopting enterprise security practices. Fail-closed validation is table stakes for deployments where misconfiguration can expose sensitive data.

Implications for MCP Server Authors

If you maintain an MCP server, consider adopting this pattern:

Define a schema for your declaration manifest
Validate strictly at startup — unknown fields are errors
Fail loudly with clear error messages explaining what's wrong
Test validation with intentionally malformed configs

The investment in strict validation pays off in operational reliability — it's much easier to fix a startup error than to debug why a tool isn't working in production.

Source: modelcontextprotocol/servers#3391