Follow Discord
Sweep 30 Oct 2026 · 01:02Z Build v2.1.314 532 read Stable v2.1.308 Latest v2.1.314 Next v2.1.314 Feeds RSS JSON llms.txt llms-full.txt Unofficial
One change · mcp

Filesystems Charter changedcommunity/working-groups/filesystems

Nearest release: v2.1.314, published 7 hours before upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.

Upstream edited this page at 30 Oct 2026 08:05 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 30 Oct 2026 08:07 UTC.

Upstream edited
Recorded here
Lines+42added
Lines−22removed
From line 8 where the diff opens
First seen 8 Sep 2026 this site's first read of the page
Recorded edits7to this page, all time

The whole hunk

from line 8, old and new numbered
/
lines
from line 8
88 
99## Mission Statement
1010 
11The Filesystems Working Group exists to make MCP Resources bidirectional, so that an agent can write a result back to
12the server it reads its inputs from. Agent platforms are converging on presenting services to models as filesystems, and
13Resources already addresses content by URI under a [`file://` scheme the specification defines as identifying "resources
14that behave like a filesystem"](https://modelcontextprotocol.io/specification/draft/server/resources#common-uri-schemes). Currently, Resources carries
15that surface in the read direction. The WG will produce a single Extensions Track SEP covering write operations,
16optimistic concurrency control, and the interaction with change notification and caching.
11The Filesystems Working Group exists to align MCP Resources with general filesystem semantics, so that MCP clients have
12one interface for discovering, retrieving and modifying filesystem-shaped resources across sources, and can do so
13efficiently. Agent platforms are converging on presenting services to models as filesystems, and Resources already
14addresses content by URI under a [`file://` scheme the specification defines as identifying "resources that behave like
15a filesystem"](https://modelcontextprotocol.io/specification/draft/server/resources#common-uri-schemes). The WG will determine which filesystem
16semantics fit MCP and produce one or more Extensions Track SEPs that apply those semantics consistently to Resources.
1717 
1818## Scope
1919 
2020### In Scope
2121 
22* **Specification Work**: One Extensions Track SEP, provisionally titled Filesystem Operations for Resources, covering:
23 1. **Operations.** Define create, update, delete, and a metadata read (`stat`) that answers existence, size and
24 last-modified for one URI without fetching the body.
25 2. **Optimistic concurrency control.** Specify how two writers avoid a lost update, and how a client creates a
22* **Specification Work**: One or more Extensions Track SEPs defining resource operations, covering:
23 1. **Scoped listing and directory traversal.** Investigate hierarchy-aware listing scoped to a URI, including an
24 operation that enumerates one level below a URI, analogous to `readdir`, traversal of a whole subtree, and how
25 both relate to the existing flat `resources/list` operation.
26 2. **Server-side search.** Investigate search and glob matching evaluated by the server, so a client can find content
27 without listing and reading every resource. This goes beyond resource templates, which describe the URIs a server
28 accepts. Together with scoped listing and traversal, this covers how a client discovers content on a server.
29 3. **Read semantics.** Investigate which filesystem read semantics fit MCP, including bulk reads of several URIs in
30 one request and whether the protocol can support a `seek` operation.
31 4. **Write and metadata operations.** Define create, update, delete, and a metadata read (`stat`) that answers
32 existence, size and last-modified for one URI without fetching the body.
33 5. **Optimistic concurrency control.** Specify how two writers avoid a lost update, and how a client creates a
2634 resource under a create-if-absent precondition.
27 3. **Change notification and caching.** Specify how a write interacts with `notifications/resources/updated`, the
28 time-to-live and cache scope fields `ttlMs` and `cacheScope`, and the `lastModified` annotation.
35 6. **Typed errors.** Define errors for resource operations, e.g. not found, already exists, precondition failed and
36 permission denied, so a client handles a failure the same way across servers. Currently, a missing resource
37 returns the generic `-32602` (Invalid Params).
38 7. **Change notification and caching.** Specify how filesystem operations interact with
39 `notifications/resources/updated`, the time-to-live and cache scope fields `ttlMs` and `cacheScope`, and the
40 `lastModified` annotation.
2941* **Cross-Cutting Concerns**: Reconcile the proposals that extend this primitive into one coherent design.
3042 [SEP-2571, Resource Submission for Agent Coordination](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2571)
3143 proposes `resources/create` and `resources/delete`.
from line 45
3345 proposes `resources/stream`.
3446 [SEP-1708, MCP Client-Brokered Filesystem Access](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1708)
3547 proposed a `files/*` method family standing beside Resources, and closed on 23 January 2026.
36* **Documentation**: Document the new operations in the specification, and give server authors guidance on choosing
37 between a resource write path and a tool-based one.
48* **Documentation**: Document the adopted filesystem semantics in the specification, and give server authors guidance
49 on choosing between a resource operation and a tool-based one.
3850 
3951### Out of Scope
4052 
4153* A parallel `files/*` primitive standing beside Resources. The WG broadens the existing Resources primitive.
54* A complete mapping of POSIX or another operating system's filesystem API. The WG will select the semantics that fit a
55 client-server protocol and document the rationale for any exclusions.
4256* Host-side sandbox and local-disk semantics. The WG standardizes the client and server wire format. How a host
4357 materializes resources into a filesystem for the model stays a host concern.
44* Authorization policy for writes, beyond stating where the existing MCP authorization specification applies.
58* Authorization policy for filesystem operations, beyond stating where the existing MCP authorization specification
59 applies.
4560 
4661### Related Groups
4762 
48* **File Uploads WG.** Both groups transfer content to a server. Coordination needed on where an upload-oriented flow
49 ends and a resource write operation begins.
63* **File Uploads WG.** Both groups transfer content to a server. Coordination is needed on where an upload-oriented flow
64 ends and a resource write operation begins. Discovery, search, metadata and small inline writes do not depend on
65 large-content transfer, and can progress independently of it. Tools already return resource links, so the groups
66 should also agree on whether a tool input that takes a file can take a reference to a Resource.
5067* **[Skills Over MCP WG](https://modelcontextprotocol.io/community/working-groups/skills-over-mcp.md).** The published
5168 [Skills extension](https://modelcontextprotocol.io/extensions/skills/overview.md) uses Resources for file reads and defines optional directory reading.
5269 It does not depend on filesystem write operations; coordinate on future resource operations that affect skills.
53* **Agents IG.** Multi-agent and job orchestration systems are the motivating consumers of a shared write path.
70* **Agents IG.** Multi-agent and job orchestration systems are the motivating consumers of shared filesystem semantics.
5471 
5572## Leadership
5673 
from line 119
102119 
103120### Success Criteria
104121 
105* An accepted Extensions Track SEP covering create, update, delete and `stat`, with a defined optimistic concurrency
106 control mechanism and a specified interaction with `notifications/resources/updated`, `ttlMs`, `cacheScope` and
107 `lastModified`.
122* One or more accepted Extensions Track SEPs defining scoped listing and directory traversal, server-side search, and
123 the supported read, write and metadata semantics, including bulk reads. The accepted work must record the WG's
124 conclusion on `seek`, define an optimistic concurrency control mechanism and a set of typed errors, and specify the
125 interaction with `notifications/resources/updated`, `ttlMs`, `cacheScope` and `lastModified`.
108126* Each proposal in this space resolved. SEP-2571 and SEP-2532 are open at time of writing, and each should end up folded
109127 in, superseded, or explicitly scoped out.
110128* Reference implementations in at least two Tier 1 SDKs.
111* Two independent server implementations exercising the write path against a common client.
129* Two independent server implementations exercising the adopted filesystem operations against a common client.
112130 
113131## Changelog
114132 
115133| Date | Change |
116134| - | - |
135| 2026-10-27 | Add search, bulk reads and typed errors to resource scope |
136| 2026-09-10 | Broaden scope to filesystem semantics |
117137| 2026-08-24 | Initial charter |
118138 
Feedback