From ebebf94a41bcc5529c90bbeb500953e12803cad2 Mon Sep 17 00:00:00 2001 From: rkoster Date: Thu, 17 Sep 2026 17:47:25 +0200 Subject: [PATCH 1/3] docs: define MCP Filesystems research note --- ...17-mcp-filesystems-research-note-design.md | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 docs/superpowers/specs/2026-09-17-mcp-filesystems-research-note-design.md diff --git a/docs/superpowers/specs/2026-09-17-mcp-filesystems-research-note-design.md b/docs/superpowers/specs/2026-09-17-mcp-filesystems-research-note-design.md new file mode 100644 index 0000000..9d50b56 --- /dev/null +++ b/docs/superpowers/specs/2026-09-17-mcp-filesystems-research-note-design.md @@ -0,0 +1,30 @@ +# MCP Filesystems Research Note Design + +## Goal + +Add a sourced research note on the MCP Filesystems Working Group's proposal to make Resources +bidirectional for agent workflows. + +## Scope + +The note will cover the group's mission, proposed create/update/delete/stat operations, +optimistic concurrency control, change notifications, cache metadata, and its relationship to +existing MCP Resources and filesystem-like URIs. It will distinguish remote MCP resource +semantics from host-side filesystem materialization and authorization, which the charter leaves +out of scope. + +The Cloud Foundry analysis will consider agent workspaces, object/blob-backed resources, +service bindings, concurrent writers, cache invalidation, audit, and authorization boundaries. +It will identify the work as early-stage: the charter lists the main SEP as ideating. + +## Structure and evidence + +Create `research/mcp-filesystems.md` with the required four sections and frontmatter. Use the +official MCP Filesystems charter, MCP Resources specification, relevant SEP links listed by the +charter, and the reference filesystem server where useful. Label CF conclusions as analysis or +open questions. + +## Validation + +Run Devbox validation and tests, inspect whitespace/staged files, commit the note and plan on +`research/mcp-filesystems`, push, and open a PR targeting `main` without unrelated artifacts. From e8b4dfc009f25deb7239d06d4e6ce5b9029e70fe Mon Sep 17 00:00:00 2001 From: rkoster Date: Thu, 17 Sep 2026 17:48:05 +0200 Subject: [PATCH 2/3] docs: add MCP Filesystems research note --- ...026-09-17-mcp-filesystems-research-note.md | 27 +++++ research/mcp-filesystems.md | 110 ++++++++++++++++++ 2 files changed, 137 insertions(+) create mode 100644 docs/superpowers/plans/2026-09-17-mcp-filesystems-research-note.md create mode 100644 research/mcp-filesystems.md diff --git a/docs/superpowers/plans/2026-09-17-mcp-filesystems-research-note.md b/docs/superpowers/plans/2026-09-17-mcp-filesystems-research-note.md new file mode 100644 index 0000000..57698ff --- /dev/null +++ b/docs/superpowers/plans/2026-09-17-mcp-filesystems-research-note.md @@ -0,0 +1,27 @@ +# MCP Filesystems Research Note Implementation Plan + +> **For agentic workers:** Execute this plan inline with validation checkpoints. + +**Goal:** Add and publish a sourced research note on the MCP Filesystems Working Group and bidirectional Resources. + +**Architecture:** Describe the proposed wire-level resource operations and concurrency/cache semantics, then distinguish them from local filesystem mounting and authorization. Map the proposal to CF-hosted agent workspaces, object storage, service bindings, and platform audit. + +**Tech Stack:** Markdown, YAML frontmatter, Devbox, Git, GitHub CLI. + +--- + +### Task 1: Write `research/mcp-filesystems.md` + +- [ ] Add frontmatter with title `MCP Filesystems: Bidirectional Resources for Agent Workflows`, author `Ruben Koster (@rkoster)`, date `2026-09-17`, tags `[orchestration, durable-execution, inter-agent-comms, ecosystem-survey]`, `cf_areas: [capi, diego]`, `status: draft`, provisional ratings, and official charter/spec/SEP sources. +- [ ] Explain the working group's mission to make MCP Resources bidirectional and its early-stage/ideating status. +- [ ] Cover proposed `create`, `update`, `delete`, and `stat` operations, create-if-absent semantics, optimistic concurrency, and metadata such as existence, size, and last-modified. +- [ ] Cover change notifications, `ttlMs`, `cacheScope`, `lastModified`, and the relationship to existing resource update notifications and caching. +- [ ] Distinguish remote resource protocol semantics from host-side filesystem materialization, local disk/sandbox behavior, and authorization policy. +- [ ] Assess CF relevance for agent workspaces, blob/object stores, volumes, bindings, concurrent writers, cache invalidation, audit, and policy enforcement. +- [ ] Add open questions about URI namespaces, version tokens, conflicts, atomicity, tenant isolation, offline clients, and write authorization. + +### Task 2: Validate and publish + +- [ ] Run `devbox run validate`, `devbox run test`, and `git diff --check`. +- [ ] Stage only the note and approved spec/plan, commit `docs: add MCP Filesystems research note`, push `research/mcp-filesystems`, and open a checklist-complete PR targeting `main`. +- [ ] Verify PR metadata and CI with `gh pr view`. diff --git a/research/mcp-filesystems.md b/research/mcp-filesystems.md new file mode 100644 index 0000000..aadceb5 --- /dev/null +++ b/research/mcp-filesystems.md @@ -0,0 +1,110 @@ +--- +title: "MCP Filesystems: Bidirectional Resources for Agent Workflows" +author: Ruben Koster (@rkoster) +date: 2026-09-17 +tags: [orchestration, durable-execution, inter-agent-comms, ecosystem-survey] +cf_areas: [capi, diego] +status: draft +ratings: + platform-impact: + value: 78 + note: "Bidirectional resources could provide a standard workspace and artifact boundary for agents without coupling applications to one filesystem implementation." + maturity: + value: 38 + note: "The Filesystems Working Group is early-stage and lists its main Extensions Track SEP as ideating rather than finalized." + novelty: + value: 72 + note: "The proposal extends MCP Resources from read-oriented content to coordinated writes with concurrency and cache semantics." + actionability: + value: 68 + note: "The operations map to CF object storage, volumes, and workspaces, but URI, authorization, conflict, and tenant semantics remain open." +sources: + - https://modelcontextprotocol.io/community/working-groups/filesystems + - https://modelcontextprotocol.io/specification/latest/server/resources + - https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2571 + - https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2532 + - https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1708 + - https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem +--- + +## Summary + +The MCP Filesystems Working Group is exploring how to make MCP Resources bidirectional so an +agent can write results back to the service it reads from. Its proposed Extensions Track SEP +would define create, update, delete, and metadata-stat operations, optimistic concurrency, and +the interaction between writes, change notifications, and caching. The work is early-stage, +with the charter listing the primary SEP as ideating; for Cloud Foundry it is a potential +protocol boundary for agent workspaces and artifacts, not a filesystem mounting standard. + +## Key findings + +- **The group extends Resources rather than creating a parallel `files/*` primitive.** MCP + Resources already represent content by URI and include a `file://` scheme for resources that + behave like a filesystem. The Filesystems WG intends to make that existing surface writable. +- **The proposed operations cover basic resource lifecycle.** The charter identifies create, + update, delete, and `stat`. The metadata read would answer existence, size, and last-modified + information without fetching the resource body. +- **Optimistic concurrency is a core requirement.** The proposal must specify how two writers + avoid lost updates and how a client creates a resource under a create-if-absent precondition. + This implies version, etag, or equivalent precondition semantics even where the final wire + representation is not yet settled. +- **Writes affect notifications and caches.** The group plans to reconcile writes with + `notifications/resources/updated`, cache TTL and scope fields such as `ttlMs` and + `cacheScope`, and `lastModified` annotations. A write therefore changes both storage state + and how clients decide whether their local view is fresh. +- **Host filesystem behavior is deliberately separate.** The charter leaves host-side sandbox + and local-disk semantics out of scope. The WG is standardizing client/server wire behavior; + how an AI host materializes a URI into a local workspace remains a host concern. +- **Authorization is not being redesigned by this group.** The charter leaves write policy to + the existing MCP authorization specification and server/application policy. A server still + needs to decide which identity can create, update, or delete a resource. +- **Adjacent proposals expose the design space.** The charter references resource submission + for agent coordination, binary resource streaming, and a prior client-brokered filesystem + proposal. These efforts raise related questions about writes, binary content, transport, and + whether resource operations should be tools or protocol methods. +- **The work is not yet a finished standard.** The charter identifies the main Filesystem + Operations for Resources SEP as ideating and describes a biweekly working session with + provisional cadence. Implementers should expect proposal changes. +- **The reference filesystem server is a useful contrast.** Existing filesystem servers can + expose a configured local directory through tools, but that deployment model does not by + itself define remote resource write semantics, optimistic concurrency, or cross-client cache + invalidation. + +## CF relevance + +Cloud Foundry could use bidirectional MCP Resources as a portable boundary for agent workspaces, +build artifacts, reports, and durable task outputs. A CF-hosted agent might read a resource from +an object store or service and write a result back through the MCP server, while CAPI-managed +application metadata, service bindings, and platform policy remain outside the resource format. +The backing implementation could use S3-compatible object storage, a volume service, a database, +or an application-specific workspace rather than assuming local disk. + +The proposal's concurrency semantics are especially relevant to multi-instance agents. Diego +may run or replace multiple processes, and several agents or tools may update the same artifact. +Version preconditions, conflict responses, idempotent retries, and explicit ownership would be +needed to avoid silent lost updates. Cache metadata and resource notifications could help clients +avoid stale workspace views, but the platform would need to correlate resource changes with +application, space, agent, and audit identities. + +The protocol does not solve CF authorization or sandboxing by itself. A gateway or MCP server +would need to enforce space/org policy, validate bindings and workload identity, restrict URI +namespaces, and audit writes. Host-side materialization also remains a separate choice: CF could +provide a bound remote workspace, a mounted volume, or an application-managed projection, each +with different isolation and lifecycle properties. + +## Open questions + +- What URI namespace and tenant model should a CF-backed resource service use for orgs, spaces, + applications, agent sessions, and shared artifacts? +- Which version token or precondition semantics should CF expose for concurrent updates, and how + should clients resolve conflicts after retries or process replacement? +- Can object storage, volume services, and application workspaces share one MCP resource model + without hiding important atomicity and durability differences? +- How should resource notifications, TTLs, cache scopes, and `lastModified` map to CF event + streams and client reconnect behavior? +- Which component authorizes resource writes, and how should user, application, agent, and + delegated tool identities be combined? +- What isolation and redaction controls are needed when resource contents contain prompts, + credentials, source code, or tenant data? +- Should CF provide a standard remote workspace service, or leave resource semantics to MCP + servers and application teams? From 2decce2f1c564ae0972b40ae6148700c7aa3e09b Mon Sep 17 00:00:00 2001 From: rkoster Date: Sat, 19 Sep 2026 16:28:15 +0200 Subject: [PATCH 3/3] docs: update generated research map --- generated/research-map.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/generated/research-map.html b/generated/research-map.html index bbe5f21..a344f63 100644 --- a/generated/research-map.html +++ b/generated/research-map.html @@ -23,9 +23,9 @@

Focus use cases

Attested Workload Authority and Mediated Tool AccessExchange platform-attested workload identity for scoped authority while credentials and outbound tool access remain mediated by the platform.Strategic decision: Decide whether CF should become the portable trust and policy layer between agent workloads and the tools they invoke.
Gap, experiments, and evidence
Current CF gap
CF issues workload identity certificates but does not exchange them for scoped tool authority, keep third-party credentials out of workloads, mediate off-platform access, or record delegation-aware audit events.
Candidate POC
Exchange a Diego instance identity certificate for a short-lived scoped token, invoke one allowed tool through a credential proxy and egress mediator, deny another, and emit attributable audit events.
Candidate RFC scope
Define workload token exchange, authority and delegation claims, credential brokering, outbound mediation and policy enforcement, audit events, revocation, and integration boundaries for UAA, routing, and service brokers.

Core

Supporting

-
Gap, experiments, and evidence
Current CF gap
CF can stage apps and run ephemeral tasks but cannot cheaply compose a reusable environment with per-session workspace state, select stronger isolation, constrain session networking, or resume the session lifecycle.
Candidate POC
Start two isolated sessions from one content-addressed staged environment, attach separate mutable workspaces, apply per-session egress policy, stop one session, and resume it on fresh compute.
Candidate RFC scope
Define environment and workspace references, session identity and lifecycle, isolation classes, network policy, workspace persistence and cleanup, scheduling, quotas, and compatibility with existing CF staging and task APIs.

Core

Supporting

ResearchIdea

Platform Impact x Maturity

Emerging < Maturity > EstablishedLocal concern < Platform Impact > Platform-wide concern
Unplaced notes (0)
  • All notes are placed.
+
Gap, experiments, and evidence
Current CF gap
CF can stage apps and run ephemeral tasks but cannot cheaply compose a reusable environment with per-session workspace state, select stronger isolation, constrain session networking, or resume the session lifecycle.
Candidate POC
Start two isolated sessions from one content-addressed staged environment, attach separate mutable workspaces, apply per-session egress policy, stop one session, and resume it on fresh compute.
Candidate RFC scope
Define environment and workspace references, session identity and lifecycle, isolation classes, network policy, workspace persistence and cleanup, scheduling, quotas, and compatibility with existing CF staging and task APIs.

Core

Supporting

ResearchIdea

Platform Impact x Maturity

Emerging < Maturity > EstablishedLocal concern < Platform Impact > Platform-wide concern
Unplaced notes (0)
  • All notes are placed.
 -