MCP Module Code Standard

Update — 2026-08-20: Spring AI MCP SSRF CVE-2026-45609 — Java/Spring framework-level SSRF as a new module code standard concern

SentinelOne disclosed CVE-2026-45609 — an unauthenticated SSRF vulnerability in the Spring AI mcp-security framework. This is the first MCP CVE in the Java/Spring ecosystem and the first to exploit framework-level server-side request handling. For the MCP Module Code Standard, this CVE adds a new deployment baseline concern: Java/Spring teams using framework-managed MCP servers must verify that the framework's request handling includes authentication and SSRF protections (allowlist-based egress filtering, internal-network access restrictions). The module code standard's authorization pattern (OAuth 2.0 + SPIFFE/SPIRE from NIST) applies to the framework's request handling, not just the MCP transport. A framework-managed MCP server that handles requests without authentication is not compliant with the module code standard, even if the transport layer is stateless. See the MCP Security Hardening Checklist for the authentication and SSRF verification controls.

Update — 2026-08-18: CoSAI token-exchange standard, MCP Project sandboxing baseline, OWASP GenAI baseline, MCP Ruby SDK bugs — the authorization pattern and the deployment baseline

Four developments in the August 16-18 window provide the standards-body authorization pattern and the deployment baseline that this code standard's module-level defensive posture has been building toward.

1. CoSAI token-exchange standard (August 18) — the authorization pattern for MCP-mediated handoffs. The Coalition for Secure AI published guidance establishing token exchange at every agent trust boundary as a foundational control principle for agentic workflows. For the MCP Module Code Standard, this is the authorization pattern for MCP-mediated agent-to-tool handoffs: every MCP module should exchange a token at the trust boundary, not hold a persistent credential. The module authenticates through a gateway that scopes the token to specific tools and actions, and the token expires in minutes with instant revocation. This validates and concretizes the "treat every MCP component as untrusted" principle: the module does not hold the agent's credentials — it receives a task-scoped token that grants access only to the specific tools and data fields the task requires. The standing-credentials guidance (agents should never hold persistent credentials) is the policy; the CoSAI token-exchange standard is the mechanism; this code standard's module structure is the implementation surface. Every register_tools() entry point should accept a task-scoped token, not a persistent credential.

2. MCP Project Sandboxing Baseline (August 16) — the deployment baseline from the spec authors. The Model Context Protocol project published formal security best practices requiring sandboxing or containerization for spawned processes and restricting file system access for MCP servers. This is the protocol's own security baseline — the most authoritative MCP-server-hardening guidance available. For the code standard, the sandboxing baseline means that every MCP module's deployment must include OS-level sandboxing (Landlock/Seatbelt/Windows ACL per the DeepSeek Harness pattern) — not just application-layer controls. The module runs in a sandboxed subprocess, the sandbox restricts filesystem access and system calls to a minimal set, and the module cannot reach the host filesystem or network regardless of what the application-layer controls do.

3. OWASP GenAI MCP Server Security Baseline (August 18) — the development-controls reference. OWASP GenAI published a practical guide for secure MCP server development covering authentication, authorization, session isolation, input validation, and hardened deployment. For the code standard, the OWASP GenAI baseline is the development-time reference: the module's directory structure, tool registration, error handling, rate limiting, and audit logging (all defined in this standard) map to the OWASP GenAI baseline's development controls. The code standard is the implementation; the OWASP GenAI baseline is the reference framework.

4. MCP Ruby SDK and file server bugs (August 16) — new CVE classes confirm the module-level defensive posture. Mallory.ai documented a DoS vulnerability in the MCP Ruby SDK and a file-disclosure flaw in an MCP server component caused by insufficient path validation. The CVE catalogue now spans Python, TypeScript, Java, Ruby, and C# SDKs — five languages, and the attack surface is protocol-wide. For the code standard, the Ruby SDK DoS extends the rate-limiting requirement (every module must implement rate limiting to prevent resource-exhaustion attacks), and the file-server directory traversal extends the input-validation requirement (every module must validate all path inputs to prevent directory traversal). The "treat all MCP components as untrusted" guidance is now confirmed by CVE data across five SDK languages — the module-level defensive posture this standard defines is not paranoia, it is the baseline.

See the MCP Security Hardening Checklist for the 12 controls that verify these standards before production and the governance checklist for the credential-architecture verification questions.

Update — 2026-08-15: DeepSeek Harness — "everything is a plugin" validates the module pattern

DeepSeek open-sourced the DeepSeek Harness on August 13-14, 2026 — an MIT-licensed agent runtime built on the Cordis meta-framework. The core design principle: "everything is a plugin." Models, tools, skills, sessions, sandboxes, filesystems, loops, orchestration, and UI are all implemented as swappable plugins with "no privileged core to patch." Extending the harness means mounting a plugin beside the others — not modifying a privileged core. 33,000+ GitHub stars within hours. The Register frames it as "Chinese AI labs keep moving forward while US labs play defense."

This is the strongest industry validation yet of the plugin/module pattern that this code standard describes. The standard exists so that every MCP module in the IdeaBosque orchestration backbone looks the same — same directory structure, same tool registration, same error handling, same audit logging. DeepSeek Harness proves that this pattern scales beyond a single organization: the most significant open-source agent runtime since Claude Code and Codex uses the same architecture. The harness's MCP client is a plugin; the tool registry is a plugin; the model adapter is a plugin; the session log is a plugin. The "no privileged core to patch" principle means that extending the system never requires modifying existing code — it requires adding a new plugin. This is the same principle behind the MCP module code standard: every connector is a module, every module follows the same structure, and adding a new connector never requires modifying the orchestration core.

The harness also includes an MCP client built in — confirming that MCP is the protocol layer for agent-to-tool communication in the plugin-first architecture. The module pattern this standard defines is not a vendor-specific convention; it is the industry-standard architecture for composable agent runtimes.

Why a code standard matters

Every connector we ship looks the same. That is not an accident — it is a discipline. When a second integration arrives, the agent's capabilities are easier to test, audit, and swap because every MCP module follows the same structure, naming, and error contract.

This document defines the standard for all MCP modules in the IdeaBosque orchestration backbone. It covers directory layout, tool registration, input/output schemas, error handling, rate limiting, audit logging, and PII boundary handling.

Directory structure

Each MCP module lives in its own directory under app/mcp_modules/ with a consistent layout:

app/mcp_modules//
  __init__.py
  module.py          # Tool registration + handlers
  schemas.py         # Input/output Pydantic models
  tests/
    test_module.py
  README.md

Tool registration

Every module registers its tools through a standard interface. The orchestration backbone discovers tools by scanning for the register_tools() entry point — no manual wiring.

def register_tools(registrar):
    """Register all tools provided by this module."""
    registrar.tool(
        name="search_catalog",
        description="Search supplier catalog by SKU or name",
        input_schema=SearchCatalogInput,
        output_schema=SearchCatalogOutput,
        rate_limit=120,  # calls per minute
    )

Error handling

Modules must raise typed exceptions, not bare strings. The backbone catches MCPToolError subclasses and converts them to structured responses the agent can reason about:

• MCPAuthError — credentials missing or expired
• MCPRateLimitError — upstream rate limit hit
• MCPTimeoutError — upstream call exceeded the configured timeout
• MCPValidationError — input did not pass schema validation
• MCPUpstreamError — upstream returned an error status

Rate limiting

Each tool declares its own rate limit in the registration call. The backbone enforces these per-agent, per-tool, and per-window. When a limit is hit, the agent receives a 429 response with a Retry-After header — it does not crash or retry blindly.

Audit logging

Every tool call is logged with: timestamp, agent ID, tool name, input hash (not raw input — PII boundary), output status, duration, and upstream system. Logs are written to structured JSON and shipped to the observability pipeline.

"Every tool call is logged and auditable" is not a feature we add later. It is the first thing the standard requires.

PII boundary handling

Modules must declare which input fields contain PII. The backbone hashes these fields before logging and never sends raw PII to the audit pipeline. PII fields are marked in the schema:

class SearchCatalogInput(BaseModel):
    sku: str
    customer_name: str = Field(..., pii=True)
    region: str

When pii=True is set, the audit logger replaces the value with a SHA-256 hash. The tool handler still receives the raw value — PII handling is enforced at the logging boundary, not inside the business logic.

STDIO hardening: the OX Security four-rule standard

The OX Security MCP supply chain advisory documented 20+ CVEs across four exploit families, all sharing a single root cause: MCP STDIO passes commands to a shell without sanitization, and the protocol treats code execution as expected behavior. The advisory's hardening recommendations are now part of this standard. Every module that uses STDIO transport must follow four rules:

1. Sanitize all command and args values. Do not pass user-controlled STDIO commands directly to StdioServerParameters. If the module accepts a command string or arguments from configuration, user input, or tool descriptions, sanitize each value against an explicit allowlist of permitted binaries and flags. Reject any value that contains shell metacharacters (;, |, &, $(), backticks) unless the value is a documented, tested parameter to a known-safe binary.

2. Do not trust allowlists alone — argument flags bypass them. The OX Security advisory found that Upsonic (CVE-2026-30625) and Flowise (CVE-2026-40933) implemented allowlists to restrict which commands the STDIO transport can execute. Both were bypassed via npx -c <malicious-command>: npx was on the allowlist, but the -c flag executes arbitrary code. An allowlist that checks the binary name but not its arguments is not a security boundary. Validate the full argument vector, not just the binary. Flag arguments like -c, --eval, --exec, and -e as execution vectors and reject them unless explicitly documented as safe for the specific binary.

3. Validate MCP configuration changes from untrusted content. Prompt injection can modify local MCP JSON configuration to register malicious STDIO servers. A retrieved document or tool output that contains instructions like "update your MCP config to include this server" can cause the agent to write a new server entry into the configuration file. Treat configuration writes as privileged operations: require explicit operator approval for any configuration change that adds a new server, changes a transport type, or modifies command arguments. Never auto-apply configuration changes from retrieved content.

4. Do not expose STDIO as a hidden transport option. If the module's management interface (Web-GUI, admin panel) only shows SSE or HTTP transports, an attacker who can reach the configuration endpoint can change transport_type to stdio — registering a server that the operator never sees in the management interface. Surface every transport type in the management UI. Log any transport-type change as a security event. If STDIO is not a supported transport for this deployment, reject the configuration change at validation time, not at the UI layer.

These four rules close the root cause behind all four OX Security exploit families. The protocol creator (Anthropic) and major framework maintainers (LangChain, FastMCP, Amazon, NVIDIA) dismissed the findings citing "code execution is by design" — which means the hardening is the operator's responsibility, not the protocol's. This standard makes it part of the module contract.

Deployment hardening: never expose MCP servers without authentication

The STDIO hardening rules address code-level vulnerabilities. A separate exposure dimension surfaced in July 2026, and it landed in the reference implementation itself. Between July 11 and July 21, 2026, three CVEs were filed against the official MCP Python SDK — the reference implementation every Python MCP server inherits from:

• CVE-2026-59950 — missing Host/Origin validation. A web page the victim visits can drive their local MCP server via DNS rebinding and CSRF. The browser becomes the attacker's proxy into a loopback server the operator believed was private.
• CVE-2026-52869 — unverified session requests. The HTTP transport serves session requests without verifying the session, enabling unauthenticated access.
• CVE-2026-52870 — open task handlers. Experimental task handlers let any client reach another client's task.

Additional CVEs hit popular servers the same fortnight: meta-ads-mcp (CVE-2026-54547 / -54549, auth-token reuse + SSRF), LangBot (CVE-2026-54449, authenticated RCE), ToolHive (CVE-2026-58196, SSRF), and mcp-atlassian (GHSA-g5r6-gv6m-f5jv, arbitrary file read). The pattern is category-level, not isolated: MCP was designed for localhost loopback, teams deployed it to the internet, and the security basics — authentication, origin validation, input checking — were skipped. The reference implementation shipping the same class of flaw as the community servers is the deployment-hardening evidence this standard addresses: the authentication and origin-validation rules below are not aspirational — they close the root cause behind CVE-2026-59950 and CVE-2026-52869.

Trend Micro's corrected follow-up scan found 1,467 publicly accessible MCP servers with no authentication or encryption — nearly tripled from the initial 492, not the "~2,000" previously cited. The escalation is not just the count: 1,227 of the 1,467 are running the deprecated SSE transport (the population most affected by both the July 28 spec migration and the security exposure), the execute_sql tool appears on 70 hosts, "Graphiti Agent Memory" (an agentic MCP server) is on 39 hosts — a prime target for exfiltrating memory-resident data — and at least three servers expose patient medical records via a "progress_note" tool. The threat widened from local STDIO configurations to cloud-deployed MCP servers reachable from the internet. Many of these servers exposed hardcoded credentials, tool endpoints, and system access to anyone who could reach the port.

BlueRock Security: 36.7% of 7,000+ MCP servers vulnerable to SSRF. BlueRock Security analyzed over 7,000 MCP servers and found 36.7% potentially vulnerable to Server-Side Request Forgery — a larger corpus than Trend Micro's 1,467 exposed-servers scan, and a different vulnerability class. SSRF lets an attacker coerce an MCP server into making requests to internal network resources the server can reach but the attacker cannot — cloud metadata endpoints, internal APIs, databases. The 36.7% figure is the new aggregate vulnerability statistic: more than one in three MCP servers can be tricked into probing the internal network. For B2B deployments, the SSRF risk is acute because MCP servers typically have access to internal systems (ERP, CRM, inventory databases) — a server that fetches a supplier catalog can be redirected to fetch the cloud metadata endpoint and leak credentials.

Three additional CVEs surfaced in the July 2026 wave, expanding the CVE timeline beyond the official SDK vulnerabilities:

• CVE-2025-68143 — path traversal. An MCP server allows file access outside the intended directory through crafted path arguments, enabling arbitrary file read on the agent's host.
• CVE-2025-68144 — argument injection. A tool that accepts command-line arguments can be coerced into executing additional flags the operator did not intend, similar to the STDIO allowlist bypass pattern documented in the OX Security four-rule standard above.
• CVE-2025-68145 — repository scoping bypass. A server that should be scoped to a single repository can access repositories outside its declared scope, exposing private code and secrets.

cyberdesserts.com confirmed that the July 28, 2026 protocol revision does not close the authorization-model gap — the structural vulnerability that lets a compromised tool description or output hijack agent behavior persists in the final specification. The stateless redesign improves operational efficiency but does not address MCP03 (tool poisoning), MCP06 (intent flow subversion), or MCP10 (context over-sharing). The governance layer remains the operator's responsibility — and this standard is the implementation contract for that responsibility.

Spec-final migration notes (July 28, 2026). The MCP 2026-07-28 specification shipped as final with a 12-month SSE deprecation policy: the SSE transport is deprecated and must be migrated to the Streamable HTTP transport within 12 months. All four Tier 1 SDKs (Python, TypeScript, Java, Kotlin) have shipped compatible versions. Modules using SSE transport must be migrated; modules using STDIO are unaffected. The migration is a transport-layer change — the tool registration, error handling, rate limiting, and audit logging rules in this standard are transport-agnostic. The module contract does not change; only the transport binding does.

The deployment-hardening rules:

1. Never expose an MCP server on a public interface without authentication. Every MCP server — whether STDIO, SSE, or HTTP transport — must require authentication (OAuth 2.1 with PKCE, API key, or mTLS). A server reachable at 0.0.0.0:3000 without authentication is a remote code execution surface, not a development convenience.

2. Bind to localhost or a private network. Production MCP servers bind to 127.0.0.1 or a private subnet. If external access is required, route through a reverse proxy with authentication, rate limiting, and TLS termination — not direct port exposure.

3. Never hardcode credentials in MCP configuration files. The Trend Micro scan found hardcoded API keys, database passwords, and OAuth secrets in publicly accessible MCP server configurations. Credentials must come from environment variables or a secrets manager — never from a JSON file that an attacker can read.

4. Encrypt all transport. STDIO is local-only by definition, but SSE and HTTP transports must use TLS. A plaintext HTTP MCP server on a public network exposes every tool call — including authentication tokens and PII — to network-level interception.

The Trend Micro scan is the deployment-side complement to the OX Security advisory: the code-level vulnerabilities (unsanitized STDIO, allowlist bypasses, configuration injection) become remotely exploitable when the server itself is exposed without authentication. Code hardening without deployment hardening is a locked door on an open porch.

Update — 2026-07-30: CVE-2026-34742 (Go MCP SDK DNS rebinding)

CVE-2026-34742 — Go MCP SDK DNS rebinding (prior to v1.4.0). The Go MCP SDK is the fifth Tier 1 SDK to receive a CVE, joining the Python (CVE-2026-59950), TypeScript, Java, and Kotlin SDKs that all speak the 2026-07-28 final specification. The vulnerability is the same class as the Python SDK's CVE-2026-59950: missing Host/Origin validation that lets a web page the victim visits drive their local MCP server via DNS rebinding and CSRF. The browser becomes the attacker's proxy into a loopback server the operator believed was private.

The fifth Tier 1 SDK CVE confirms that the DNS-rebinding attack surface is protocol-level, not implementation-level: each SDK independently shipped the same missing validation, because the protocol did not require Host/Origin validation. The deployment-hardening rule 2 in this standard — bind to localhost or a private network, route external access through a reverse proxy with authentication, rate limiting, and TLS termination — closes the root cause. The Go SDK v1.4.0+ patches the validation; modules built on earlier Go SDK versions must upgrade or enforce the binding rule at the deployment layer.

Update — 2026-08-06: Transport-mode security — the stateful streamable-HTTP attack surface

CVE-2026-16496 (CVSS 10.0, patched in Terraform MCP Server on August 5, 2026) is the first maximum-severity CVE in the MCP ecosystem and the first production evidence that the transport mode is a security dimension, not just an operational one. The vulnerability is a session-hijacking authorization bypass in the streamable-HTTP stateful transport mode: a user who obtains another user's MCP session ID can have their tool calls executed using that user's Terraform credentials. HashiCorp also patched CVE-2026-16498 (tenant isolation break) and CVE-2026-14869 (SSRF) in the same release. (The Hacker News, SentinelOne vulnerability database)

This adds a transport-mode-security rule to the deployment-hardening standard:

5. Prefer stateless transport; treat stateful streamable-HTTP as a security risk. The MCP 2026-07-28 specification moved to a stateless protocol core — the initialize/initialized handshake and Mcp-Session-Id header are removed, and stateful workflows use explicit handles instead of server-side sessions. The stateless design eliminates the session-hijacking attack class at the architecture level: a stateless server has no session to steal. The stateful streamable-HTTP transport mode that CVE-2026-16496 exploits is the mode the stateless core is designed to replace. If a module must run stateful streamable-HTTP (for compatibility with a client that has not migrated), treat it as a known-vulnerable configuration: bind it to a private network, require authentication on every session, and plan the migration to stateless transport on the same 12-month clock as the SSE deprecation. A module that exposes stateful streamable-HTTP on a public interface without authentication is in the same risk class as the 1,467 servers Trend Micro found with zero auth — plus the session-hijacking vector.

The OX Security advisory also expanded with additional CVEs beyond the original four exploit families: CVE-2026-30618, CVE-2026-33224, CVE-2026-30617 (Family 1 — STDIO command injection), CVE-2026-30625 (Family 2 — Upsonic allowlist bypass), CVE-2026-30615 (Family 3 — Windsurf prompt injection), CVE-2026-26015 (Family 4 — SSRF), plus CVE-2025-65720 (GPT Researcher RCE), CVE-2026-30623 (LiteLLM RCE), CVE-2026-30624 (Agent Zero RCE), and CVE-2026-54449 (LangBot RCE). The expanded inventory extends the supply-chain risk beyond MCP servers to the agent frameworks and orchestration layers that wrap them — signed provenance, pinned versions, and AIBOM manifests (the dependency control for MCP) are what make the expanded inventory detectable before it fires.

Update — 2026-08-07: MCP server discoverability and governance — the Black Hat 2026 product dimension

The full Black Hat 2026 product inventory (crn.com, August 4, 2026) adds a new dimension to the MCP code standard: MCP server discoverability and governance. Three products launched at Black Hat USA 2026 directly address the gap between the code standard (which governs how a module is written) and the deployment reality (which governs how many modules exist and who knows about them).

1. Cyera Agent Guardian — shadow MCP server discovery. The code standard assumes every MCP module is registered, documented, and follows the directory structure and error contract. Cyera's product reveals the gap: shadow MCP servers that do not follow the code standard exist in most enterprises — installed by individual developers, inherited from acquisitions, or deployed as proofs-of-concept that were never decommissioned. The code standard governs sanctioned modules; Cyera discovers the unsanctioned ones. For the code standard, the implication is that a module's README.md and AIBOM manifest are not just documentation — they are the registration record that a discovery tool like Cyera checks against. A module without a README and AIBOM is a module that a discovery tool will flag as shadow.

2. SailPoint Identity Security — MCP server identity lifecycle. The code standard's authentication rules (OAuth 2.1, never hardcode credentials) govern how a module authenticates. SailPoint's product adds the lifecycle dimension: each MCP server has an identity that must be provisioned, attested, and revocable through an identity governance workflow. For the code standard, the implication is that a module's authentication configuration is not just a deployment-time setting — it is an identity lifecycle that the identity governance platform manages. A module that hardcodes credentials cannot be governed through the identity lifecycle; a module that uses OAuth 2.1 with managed credentials can.

3. Check Point AI Network Firewall — MCP communications monitoring at the network layer. The code standard's PII boundary rules and audit logging govern what a module logs at the application layer. Check Point's product adds the network-layer dimension: the MCP communication channel — the traffic between agents and MCP servers — is now monitorable at the network level. For the code standard, the implication is that a module's audit logging (Application-layer) is complemented by network-layer monitoring — a module that does not log its tool calls at the application layer can still be monitored at the network layer, but a module that logs at both layers is the one that produces a complete audit trail.

The Black Hat 2026 MCP server discovery products add a "discoverability and governance" dimension to the code standard: a module that follows the directory structure, error contract, and security rules is a well-written module, but a module that is also registered in an identity governance platform (SailPoint), discoverable by a shadow-server detection tool (Cyera), and monitored at the network layer (Check Point) is a well-governed module. The code standard is the foundation; the Black Hat 2026 products are the governance layer on top.

Update — 2026-08-08: Skill/Plugin Security Scanning — vendor-side code standard enforcement

Anthropic shipped Skill/Plugin Security Scanning on August 6, 2026 — the first model-vendor-side supply-chain scanning for third-party Claude Code uploads (skills and plugins). The scanning inspects uploads for malicious content before they reach the marketplace. This is the vendor-side enforcement of the code standard's supply-chain controls: the code standard governs how a module is written (directory structure, error contract, PII boundary rules); Skill/Plugin Scanning governs what the model vendor does to verify that a third-party upload is not malicious before it reaches the agent's tool registry.

For the code standard, the implication is that a module's README.md and AIBOM manifest (the dependency control for MCP) now have a vendor-side verification path — but only for Claude Code skills and plugins. A module published to a marketplace that performs vendor-side scanning arrives with a vendor-attested safety baseline. A module published to a marketplace that does not scan arrives without that baseline. The code standard's signed provenance (the AIBOM manifest) remains the module-level control; Skill/Plugin Scanning is the marketplace-level control. Both are needed: the AIBOM proves what the module contains; the vendor scan proves the marketplace checked it.

The "9 of 11 MCP marketplaces accepted poisoned PoC submissions" finding — the supply-chain gap the code standard's signed provenance and pinned-version rules address — now has a vendor-side mitigation for Claude Code. For the broader MCP ecosystem, the code standard remains the module-level baseline, and the Terraform MCP CVE-2026-16496 (CVSS 10.0) remains the evidence that the transport-mode security rule is not optional.

Update — 2026-08-09: CISA KEV CVE-2026-42271 — MCP module code standards are now a federal compliance concern

CISA added CVE-2026-42271 (BerriAI LiteLLM, CVSS 8.7) to its Known Exploited Vulnerabilities catalog — the first MCP-adjacent CVE to receive the KEV designation. The vulnerability stems from two MCP server testing endpoints in LiteLLM versions 1.74.2 through 1.83.6 that allowed authenticated users to supply custom server configurations including commands and environment variables, executed as subprocesses without role-based access controls. Fixed in LiteLLM 1.83.7.

For the code standard, the KEV designation adds a "federal remediation mandate" dimension. The code standard's tool registration rule (the tool definition with inputSchema validation) and its STDIO hardening rule (the four-rule OX Security standard that prevents command injection) are no longer best practices — for federal agencies and their contractors, they are compliance requirements with a remediation deadline. The testing-endpoint command injection is closed by the code standard's tool registration (the testing endpoint must not accept arbitrary server configurations from non-admin users) and authentication rules (subprocess execution must require role-based authorization). The KEV mandate is the federal signal that MCP module code standards are now a compliance concern, not a best practice. See the MCP Security Hardening Checklist Control 1 and Control 4 for the control mapping, and the MCP Paradox article for the frictionless-to-fragile analysis.

Update — 2026-08-23: MCP New Roadmap — progressive discovery and agent identity as code-standard priorities

On August 22, 2026, the MCP maintainers published a new roadmap defining five priority areas for the next specification cycle. Two of them directly affect the code standard:

1. Progressive tool discovery — the roadmap addresses the "hundred tools" problem: "Connecting to a server with a hundred tools means the model pays for that entire surface before the user has asked a single question, and tool selection tends to get worse as the list grows." The 2026-07-28 spec already provides server/discover RPC and tools/list with ttlMs and cacheScope cache hints. For the code standard, progressive discovery is a structural pattern: a module's tool registration should expose a small entry point (a discover_tools function that returns a focused subset) and dynamically expand the surface based on the agent's current workflow. This extends the code standard's single-responsibility tool design — a module with 50+ tools should not dump all 50 schemas into the model's context window on connection. The discover_tools pattern keeps the context window lean and tool selection accurate.

2. Agent identity and enterprise-ready security — the roadmap recognizes that "more and more of the callers are agents running as cloud workloads with their own identity." The path forward includes DPoP (RFC 9449) to bind OAuth tokens to a client-held key, Workload Identity Federation via the IETF WIMSE working group, and the Enterprise-Managed Authorization (EMA) extension. For the code standard, this means a module's authentication configuration should accept task-scoped tokens (not persistent credentials), and the register_tools() entry point should validate a token's audience and expiry on every call. The code standard's OAuth 2.1 rule already requires managed credentials; the roadmap's agent identity work formalizes what "managed" means for workload callers.

The roadmap's HTTP-native transport unification priority — extending Streamable HTTP to local servers over stdio — does not change the code standard's transport rules (the stateless transport preference remains), but it means the STDIO and HTTP transport paths will converge on a single protocol. See the MCP Tutorial for a hands-on walkthrough of progressive discovery and agent identity in a production server.