MCP Filesystems Working Group: bidirectional Resources

Current status

The MCP specification repository now contains an official Filesystems Working Group charter. PR #3282 merged the charter on 8 September 2026. The charter defines a standards workstream for making MCP Resources bidirectional so a client can write results back to the same server from which it reads inputs.

The maturity boundary is important: the charter’s active “SEP: Filesystem Operations for Resources” work item is still Ideating. There is no accepted or Final filesystem-operations SEP, and the current released MCP specification remains 2026-07-28.

Surface	Current evidence
Group	MCP Filesystems Working Group
Charter	Merged into the official MCP specification repository
Planned standards deliverable	One Extensions Track SEP for filesystem operations on Resources
Active work-item status	Ideating
Current released MCP Resources	resources/list, resources/read, templates, list-change notifications and subscriptions
Released resources/create / update / delete / stat?	No
Native UHP relationship	No standardized UHP↔MCP Filesystems binding established

Caution

A Working Group charter is not a protocol release. The methods and concurrency rules below are the WG’s intended design scope, not behavior an MCP 2026-07-28 client or server can assume.

Why the Working Group exists

MCP Resources already model data addressable by URI. The released 2026-07-28 Resources surface lets clients enumerate and read resources, and file:// identifies resources that behave like a filesystem without requiring those resources to map to a physical local filesystem.

The Filesystems WG targets the missing reverse direction: standardized resource mutation. Its mission is to let agents and applications work against cloud drives, repositories, object stores, virtual filesystems and similar resource stores through one resource model instead of requiring a separate project-specific write API for every server.

Planned filesystem-operations surface

The charter says the first Extensions Track SEP is expected to cover:

• Create a resource.
• Update an existing resource.
• Delete a resource.
• Metadata / stat operations.
• Optimistic concurrency control so concurrent writers can detect and avoid lost updates.
• Create-if-absent semantics for atomic creation without accidental overwrite.
• Consistent interaction with existing resource-change notifications and caching metadata, including notifications/resources/updated, ttlMs, cacheScope and lastModified.

The WG also intends to provide guidance on when a mutation should be represented as a Resource operation versus an ordinary MCP Tool. That distinction matters because a generic resource write expresses storage semantics, while a domain tool may represent a higher-level business action with different validation and authorization requirements.

The WG deliberately stays inside Resources

The charter rejects a second parallel files/* primitive family. The direction is to extend the existing Resources model instead of creating a competing filesystem namespace.

It also keeps several concerns outside this workstream:

• host-side sandbox policy and local-disk access semantics;
• defining a new authorization framework beyond MCP’s existing authorization model; and
• a generic local filesystem API detached from Resources.

That scope prevents “filesystem support” from being misread as permission for an MCP server to write arbitrary host files. A file:// resource is a protocol identifier for a filesystem-like resource; it is not evidence of direct host-disk authority.

Existing proposals are inputs, not the finished standard

The charter explicitly calls out earlier open proposals that the WG must reconcile:

• SEP-2571 proposes resources/create and resources/delete for resource submission and cleanup. Its pull request remains open.
• SEP-2532 proposes resources/stream for large binary delivery. Its pull request remains open and Draft.
• The older SEP-1708 parallel files/* direction is listed as closed/superseded context rather than the chosen architecture.

The charter therefore establishes ownership and direction without blessing any one earlier proposal as the final wire contract.

How this relates to UHP

UHP and the MCP Filesystems work operate at different boundaries:

Product / application
        │
        │ UHP: task/session execution + input files / output artifacts
        ▼
Complete agent harness
        │
        │ MCP: resource access through an MCP server
        ▼
Resource store
        │
        │ Filesystems WG: proposed create/update/delete/stat semantics
        ▼
Cloud drive / repository / object store / virtual filesystem

UHP standardizes how a client drives a complete harness and transfers execution inputs/results through its task, session, file and artifact contract. The Filesystems WG is standardizing how an MCP client and MCP server may mutate Resources.

Those surfaces can compose. A UHP-served harness could use an MCP server whose future Resources extension supports writes. That would not make the MCP server a UHP server, would not make Resource writes UHP file operations, and would not establish native UHP adoption by the MCP implementation.

The overlap is nevertheless worth tracking: once standardized, bidirectional MCP Resources could become a common inner-harness persistence boundary for repository edits, generated files and other durable agent outputs that are later surfaced through a separate UHP artifact/file boundary.

What to watch next

The next evidence that should materially change this page is:

1. a concrete Filesystem Operations SEP entering review or becoming Accepted;
2. the SEP reaching Final and landing in the canonical MCP specification/extension surface;
3. Tier-1 SDK or reference implementations shipping the agreed operations; and
4. the charter’s target of at least two independent server implementations demonstrating interoperability.

Until then, describe MCP Filesystems as official Working Group standards work with an Ideating SEP, not as released bidirectional Resource behavior.

Primary sources

• MCP Filesystems Working Group charter
• PR #3282 — add the Filesystems Working Group proposal
• MCP 2026-07-28 Resources specification
• SEP-2571 — Resource Submission for Agent Coordination
• SEP-2532 — Resource Streaming for Binary Content Delivery

Related: see UHP vs MCP for the overall protocol-layer comparison and Skills Over MCP for the separate Agent Skills distribution extension.