Independent developer guide. Not affiliated with HarnessRouter or the official UHP project.

MCP Filesystems: resource writes, maturity and implementation choices

The MCP Filesystems Working Group is designing resource mutation semantics. Its charter is useful planning evidence, but a working-group proposal is not a deployed write API.

Page reviewed 4 Oct 2026 Source and review policy

Current guidance and dated source history

Specify the write contract before selecting a transport

The current Filesystems charter, checked 4 October 2026, still marks filesystem operations Ideating. An implementation can expose writes through tools today, but it must document its own mutation semantics. The UHP side remains UHP 2026-09-28 Draft; a session file and an MCP resource URI are separate objects.

For a shared document edit, settle these points before allowing unattended execution:

Target and ownership: resolve the URI at the selected server, and verify the principal can mutate that object. A file:// resource is not permission to write the client’s disk.
Precondition: establish how the server identifies the revision being changed. If it offers no conditional-write contract, serialize changes in your application or expose the overwrite risk explicitly.
Result: distinguish accepted work, committed bytes and a merely queued operation. For long-running writes, preserve the MCP task handle.
Recovery: define how to inspect the object after a timeout; retry only under the server’s documented duplicate-prevention rules.

Fixture	Expected contract evidence
Two clients edit the same starting revision	Conflict or explicitly documented overwrite behavior
Read allowed, write denied	Denial without mutation
Connection drops during a rename	Inspection establishes the source/destination state; no invented success

These are suggested acceptance fixtures. They do not imply that proposed resources/update messages are released or that this guide executed a server’s write implementation.

What is available, and what is still a proposal?

The Filesystems charter, reviewed 4 October 2026, still marks Filesystem Operations for Resources and taking up SEP-2571 as Ideating. Do not infer standardized resources/create, resources/update or resources/delete support from the existence of the group.

Surface	What the reviewed evidence establishes
Base Resources	A standard read/context primitive
Skills extension	Skill discovery and resource reads, including optional advertised directory reads
Filesystems charter	Planned mutation, metadata and concurrency semantics
A server-specific write tool	That server’s documented business/storage operation
UHP artifacts/files	A separate outer harness-execution file boundary

If you need writes today

Inspect the actual server’s advertised tools and published contract. Define the target resource, authorization scope, overwrite behavior and conflict response. Test a stale revision and a denied write in an isolated fixture before relying on the operation in unattended work. A successful read or directory listing says nothing about permission to mutate that resource.

The charter’s optimistic-concurrency and create-if-absent goals address a practical failure: two agents must not silently overwrite each other’s work. Treat the charter as a design direction until a published specification and your target implementation define the wire messages.

Keep skill reads and host files separate

The Skills extension uses Resources, but its optional directory-read method does not ship the Filesystems group’s mutation proposal. Likewise, a resource URI does not grant arbitrary access to a client’s local disk. The client, server and operating-system sandbox retain their own authority boundaries.

Use MCP Tasks for long-running operations and the UHP API reference for the separate execution-artifact contract. The dated source history below retains proposal provenance; open-PR statuses there are historical snapshots, not newly verified merge states.

Historical source notes — baseline reviewed 18 Sep 2026

The following evidence preserves the earlier review and its links. “Current”, “stable” and “main” inside this section refer to that historical cutoff; they are not new release or compatibility claims. Use the guidance above for the current scope.

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.

On 18 September 2026, MCP PR #3372 merged as 24efd6e7 and updated the Filesystems charter after publication of the official Skills extension. The charter now makes the boundary explicit: io.modelcontextprotocol/skills uses existing Resources for file reads and defines optional directory reading, but does not depend on the Filesystems WG’s proposed write operations. This is documentation of the now-published Skills relationship, not a promotion of the Filesystem Operations work item and not a new MCP base-spec revision.

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
Published Skills relationship	Skills uses standard `resources/read` plus optional `resources/directory/read`; it does not require filesystem write operations
Released `resources/create` / `update` / `delete` / `stat`?	No
Native UHP relationship	No standardized UHP↔MCP Filesystems binding established

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 published Skills extension is read-oriented, not the write SEP

The Filesystems charter now explicitly coordinates with the Skills Over MCP Working Group because the published Skills extension already builds on the Resources primitive. A server that declares io.modelcontextprotocol/skills serves skill files through standard resources/read; if it additionally declares directoryRead: true, it implements the extension’s optional resources/directory/read method for listing direct children of a directory resource.

That optional directory method is a Skills extension operation, not evidence that the Filesystems WG has shipped its proposed write surface. The Skills specification depends only on the base Resources primitive and does not require resources/create, resources/update, resources/delete, stat, optimistic-concurrency semantics or create-if-absent behavior. Future resource operations may affect Skills, which is why the charter now names the coordination point explicitly.

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:

a concrete Filesystem Operations SEP entering review or becoming Accepted;
the SEP reaching Final and landing in the canonical MCP specification/extension surface;
Tier-1 SDK or reference implementations shipping the agreed operations;
the charter’s target of at least two independent server implementations demonstrating interoperability; or
accepted filesystem-resource operations that materially alter how the published Skills extension navigates or mutates resources.

Until then, describe MCP Filesystems as official Working Group standards work with an Ideating SEP, not as released bidirectional Resource behavior. Keep the published Skills extension’s read/directory surface separate from the Filesystems WG’s still-proposed write semantics.

Primary sources

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