Home Docs Model Context Protocol

One capture · mcp

One read of Model Context Protocolmcp-20261030T080707Z

5 pages moved out of 359 read.

Pages moved 5 significant first

Pages read 359 in this capture

Captured 30 Oct 2026 08:07 UTC

Corpus hash 4b378a8f21dd corpus-hash

What this read moved

1-5 of 5

community/working-groups/filesystems Changed · +42 / -22 lines

from line 8

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

extensions/auth/enterprise-managed-authorization Changed · +44 / -3 lines

## Implementation support

from line 4

55The Enterprise-Managed Authorization extension (`io.modelcontextprotocol/enterprise-managed-authorization`) enables organizations to control MCP server access centrally through their existing identity provider (IdP). Instead of each employee authorizing each MCP server individually, the organization's IT or security team manages access policies in one place.

7> **[Specification](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/enterprise-managed-authorization.mdx)**

7> **[Specification](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/enterprise-managed-authorization/2026-07-28/enterprise-managed-authorization.mdx)**

88>

99> Full technical specification for the Enterprise-Managed Authorization

1010> extension.

from line 20

2020* Onboarding new employees requires them to manually authorize dozens of services

2121* Offboarding requires revoking access across every service individually

2222

23Enterprise-Managed Authorization solves this by introducing the organization's IdP as the authoritative decision-maker. The IdP (such as Okta, Azure AD, or a corporate SSO system) controls which MCP servers employees can access, and under what conditions. Employees authenticate with their corporate identity — the same credentials they use for email, Slack, and other work tools — and the IdP grants or denies MCP server access based on organizational policy.

23Enterprise-Managed Authorization solves this by introducing the organization's IdP as the authoritative decision-maker. The IdP controls which MCP servers employees can access, and under what conditions. Employees authenticate with their corporate identity — the same credentials they use for email, Slack, and other work tools — and the IdP grants or denies MCP server access based on organizational policy.

2424

2525## When to use it

2626

from line 137

137137

138138Check the [client matrix](https://modelcontextprotocol.io/extensions/client-matrix.md) for current implementation status across MCP clients. Enterprise-Managed Authorization typically requires client-level support from the organization's IT team in addition to the MCP client application.

139139

140## Implementation support

141

142> [!NOTE]

143>

144> This list is not comprehensive. It records documented support only, so a missing product or an empty cell does not mean that a role is unsupported.

145

146Two products take part in the flow besides the MCP client: the enterprise IdP that issues the

147ID-JAG, and the MCP server's authorization server that accepts it and returns an access token. One

148product can fill both roles. The table lists products with public documentation for at least one

149role and uses the vendor's own release label: **Available** (in a production release with no

150pre-release label), **Early access** (gated by plan, environment, or request), and **Experimental**

151(the vendor's pre-release label).

152

153The IETF OAuth working group defines ID-JAG in

154[draft-ietf-oauth-identity-assertion-authz-grant](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/).

155Implementations track different draft revisions, so check each vendor's documentation for the

156revision it targets.

157

159| - | - | - | - |

160| [Athenz](https://github.com/AthenZ/athenz/blob/master/docs/zts_token_exchange_requirements.md) | Available | Available | Open source. ZTS issues ID-JAGs through token exchange and accepts them through the JWT bearer grant. |

161| [Auth0](https://auth0.com/docs/ai-agents-mcp/cross-app-access) | | Early access | Cross App Access for Resource Apps, early access on Enterprise, B2B Pro, and B2B Essential plans. Auth0 validates ID-JAGs from an external OIDC or SAML enterprise connection. |

162| [AuthPlane](https://github.com/authplane/authserver/blob/main/docs/guides/federation/enterprise-managed-auth-xaa.md) | | Available | Self-hosted authorization server for MCP. Accepts ID-JAGs through the JWT bearer grant, enabled by default since v0.2.0. |

163| [Descope](https://docs.descope.com/agentic-identity-hub/enterprise-managed-authorization/validate-id-jags) | Available | Available | Agentic Identity Hub [issues ID-JAGs](https://docs.descope.com/agentic-identity-hub/enterprise-managed-authorization/issue-id-jags) for agents through token exchange. As the MCP server's authorization server, Descope validates ID-JAGs against per-tenant trusted issuers and returns Descope access tokens. |

164| [Janssen Project](https://docs.jans.io/stable/janssen-server/auth-server/endpoints/identity-assertion-authz-grant/) | Available | Available | Since 2.2.0, off by default behind the `identity_assertion_authz_grant` feature flag, targeting draft revision 04. |

165| [Keycloak](https://www.keycloak.org/securing-apps/identity-assertion-jwt-authorization-grant) | | Experimental | Accepting role since 26.7.0 behind the `identity-assertion-jwt` feature flag. The guide targets draft revision 01. |

166| [Okta](https://developer.okta.com/docs/concepts/xaa/) | Available | Available | Cross App Access (XAA). [Issuing](https://developer.okta.com/docs/guides/xaa-agent-to-app/main/) is included in Okta SSO for Identity Engine orgs, capped at 250 ID-JAGs per user per resource app per month. Higher volume requires Okta for AI Agents. [Custom authorization servers](https://developer.okta.com/docs/guides/ai-agent-token-exchange/authserver/main/) accept Okta-issued ID-JAGs through the JWT bearer grant with Okta for AI Agents. |

167| [Ping Identity](https://docs.pingidentity.com/pingfederate/13.1/release_notes/pf_release_notes_131.html#identity-assertion-jwt-authorization-grant-id-jag) | Available | Available | PingFederate 13.1 and later. Issues ID-JAGs through token exchange on an SP connection and [accepts them](https://docs.pingidentity.com/pingfederate/13.1/administrators_reference_guide/pf_configuring_oauth_assertion_grant_idp_connection.html) on an OAuth assertion grant IdP connection. |

169| [Stytch](https://stytch.com/docs/connected-apps/guides/cross-app-access) | | Available | Connected Apps in B2B projects exchange an ID-JAG from an external workforce IdP for a Stytch access token through the JWT bearer grant. |

170| [ThunderID](https://thunderid.dev/docs/use-cases/ai-agents/mcp-authorization/enterprise-managed-authorization/) | Available | Available | Open-source IAM project of LF Decentralized Trust, 1.0 and later. Ships a dedicated Enterprise-Managed Authorization guide covering both roles. |

171| [WorkOS AuthKit](https://workos.com/docs/authkit/mcp#cross-app-access) | | Early access | WorkOS enables Cross App Access per environment on request, with no server code changes needed after that. Not supported with Standalone MCP Auth. |

172

173Server frameworks that accept ID-JAGs include Cloudflare's

174[`workers-oauth-provider`](https://github.com/cloudflare/workers-oauth-provider) (experimental

175`enterpriseManagedAuthorization` option since 0.7.0) and

176[FastMCP](https://gofastmcp.com/servers/auth/oauth-proxy#identity-assertion-sep-990) 4.0 and later

177(beta). The [Cross-App Access directory on oauth.net](https://oauth.net/cross-app-access/)

178is a community list that also covers requesting applications. For MCP client support, see the

179[client matrix](https://modelcontextprotocol.io/extensions/client-matrix.md).

180

140181## Related resources

141182

142183> **[ext-auth repository](https://github.com/modelcontextprotocol/ext-auth)**

from line 184

143184>

144185> Source code and reference implementations

145186

146> **[Full specification](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/enterprise-managed-authorization.mdx)**

187> **[Full specification](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/enterprise-managed-authorization/2026-07-28/enterprise-managed-authorization.mdx)**

147188>

148189> Technical specification with normative requirements

149190

extensions/auth/oauth-client-credentials Changed · +2 / -2 lines

from line 4

55The OAuth Client Credentials extension (`io.modelcontextprotocol/oauth-client-credentials`) adds support for the [OAuth 2.0 client credentials flow](https://datatracker.ietf.org/doc/html/rfc6749#section-4.4) to MCP. This enables automated systems to connect to MCP servers without interactive user authorization.

7> **[Specification](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/draft/oauth-client-credentials.mdx)**

7> **[Specification](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/oauth-client-credentials/2026-07-28/oauth-client-credentials.mdx)**

88>

99> Full technical specification for the OAuth Client Credentials extension.

1010

from line 392

392392>

393393> Source code and reference implementations

394394

395> **[Full specification](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/draft/oauth-client-credentials.mdx)**

395> **[Full specification](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/oauth-client-credentials/2026-07-28/oauth-client-credentials.mdx)**

396396>

397397> Technical specification with normative requirements

398398

extensions/auth/overview Changed · +1 / -1 lines

from line 49

4949

5050## Specification

5151

52Both extensions are specified in the [ext-auth repository](https://github.com/modelcontextprotocol/ext-auth/tree/main/specification/draft). They use the standard MCP [extension negotiation](https://modelcontextprotocol.io/extensions/overview.md#negotiation) mechanism: clients declare support in the `extensions` field of the `io.modelcontextprotocol/clientCapabilities` they send in each request's `_meta`, and servers advertise theirs in the capabilities returned by [`server/discover`](https://modelcontextprotocol.io/specification/draft/server/discover).

52Both extensions are specified in the [ext-auth repository](https://github.com/modelcontextprotocol/ext-auth/tree/main/specification/stable). They use the standard MCP [extension negotiation](https://modelcontextprotocol.io/extensions/overview.md#negotiation) mechanism: clients declare support in the `extensions` field of the `io.modelcontextprotocol/clientCapabilities` they send in each request's `_meta`, and servers advertise theirs in the capabilities returned by [`server/discover`](https://modelcontextprotocol.io/specification/draft/server/discover).

5353

seps/2133-extensions Changed · +1 / -1 lines

from line 63

6363* A repository has a set of maintainers (identified by MAINTAINERS.md) appointed by the core maintainers that are responsible for the repository and extensions within it (e.g. [ext-auth MAINTAINERS.md](https://github.com/modelcontextprotocol/ext-auth/blob/main/MAINTAINERS.md), [ext-apps MAINTAINERS.md](https://github.com/modelcontextprotocol/ext-apps/blob/main/MAINTAINERS.md)).

6464* Extensions SHOULD have an associated working group or interest group to guide their development and gather community input.

6565

66An *extension* is a versioned specification document within an extension repository, e.g. [https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/draft/oauth-client-credentials.mdx](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/draft/oauth-client-credentials.mdx)

66An *extension* is a versioned specification document within an extension repository, e.g. [https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/oauth-client-credentials/2026-07-28/oauth-client-credentials.mdx](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/oauth-client-credentials/2026-07-28/oauth-client-credentials.mdx)

6767

6868* Extension specifications MUST use the same language as the core specification (i.e. \[[BCP 14](https://www.rfc-editor.org/info/bcp14)] \[[RFC2119](https://datatracker.ietf.org/doc/html/rfc2119)] \[[RFC8174](https://datatracker.ietf.org/doc/html/rfc8174)]) and SHOULD be worded as if they were part of the core specification.

6969