SEP: Resource Submission — client-to-server resource creation for agent coordination · Issue #2570 · modelcontextprotocol/modelcontextprotocol · GitHub Skip to content Navigation Menu Sign in Appearance settings * Platform * AI CODE CREATION * GitHub Copilot Write better code with AI * GitHub Copilot app Direct agents from issue to merge * MCP Registry Integrate external tools * DEVELOPER WORKFLOWS * Actions Automate any workflow * Codespaces Instant dev environments * Issues Plan and track work * Code Review Manage code changes * Code Quality Enforce quality at merge * APPLICATION SECURITY * GitHub Advanced Security Find and fix vulnerabilities * Code security Secure your code as you build * Secret protection Stop leaks before they start * EXPLORE * Why GitHub * Documentation * Blog * Changelog * Marketplace View all features * Solutions * BY COMPANY SIZE * Enterprises * Small and medium teams * Startups * Nonprofits * BY USE CASE * App Modernization * DevSecOps * DevOps * CI/CD * View all use cases * BY INDUSTRY * Healthcare * Financial services * Manufacturing * Government * View all industries View all solutions * Resources * EXPLORE BY TOPIC * AI * Software Development * DevOps * Security * View all topics * EXPLORE BY TYPE * Customer stories * Events & webinars * Ebooks & reports * Business insights * GitHub Skills * SUPPORT & SERVICES * Documentation * Customer support * Community forum * Trust center * Partners View all resources * Open Source * COMMUNITY * GitHub Sponsors Fund open source developers * PROGRAMS * Security Lab * Maintainer Community * GitHub Stars * Archive Program * REPOSITORIES * Topics * Trending * Collections * Enterprise * ENTERPRISE SOLUTIONS * Enterprise platform AI-powered developer platform * AVAILABLE ADD-ONS * GitHub Advanced Security Enterprise-grade security features * Copilot for Business Enterprise-grade AI features * Premium Support Enterprise-grade 24/7 support * Pricing Search / Sign in Sign up Appearance settings You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert Uh oh! There was an error while loading. Please reload this page . modelcontextprotocol / modelcontextprotocol Public * Notifications You must be signed in to change notification settings * Fork 1.8k * Star 9.2k * Code * Issues 69 * Pull requests 78 * Discussions * Actions * Projects * Security and quality 1 * Insights Additional navigation options * Code * Issues * Pull requests * Discussions * Actions * Projects * Security and quality * Insights SEP: Resource Submission — client-to-server resource creation for agent coordination   #2570 New issue Copy link New issue Copy link Closed Closed SEP: Resource Submission — client-to-server resource creation for agent coordination #2570 Copy link Description cswelker opened on Apr 14, 2026 Issue body actions Title: Resource Submission (resources/create) Author: Chris Welker ( @cswelker ) Status: Proposal Type: Standards Track Abstract This SEP proposes adding a resources/create method to the MCP specification, allowing clients to submit resources to a server and receive a URI back. This enables agents to package and transfer content — prompts, configs, data — to MCP servers without requiring custom tools, enabling a class of coordination patterns that the current spec cannot address. Motivation The current MCP resources spec is read-only from the client's perspective. Servers expose resources; clients list and read them. This works well for static server-owned content but breaks down in multi-agent and job orchestration scenarios where a client needs to deliver content to a server for later use. Concrete use case: job function registration Consider an orchestrator MCP server that accepts job function definitions — YAML configs + associated prompts — from clients. When a job is registered, its resources (prompts, templates, configs) must be stored server-side so the job can execute later without depending on the submitting client being available. Today, this requires a custom tool (e.g. register_resource ). This works but forces every orchestration system to reinvent the same pattern. If resource submission were part of the spec, any MCP server could accept resources using a standard interface, and clients could submit resources to any compliant server. The broader pattern: agent-to-agent coordination Multi-agent systems frequently need to pass content between agents via an intermediary server: * Agent A submits a document for Agent B to process * An orchestrator stores prompts/templates that worker agents will use at runtime * A client pre-loads context that a long-running job will need after the client disconnects In all these cases, the client is the source of a resource, not just a consumer. The current spec has no standard way to express this. Proposal Add a resources/create method: Request { "method" : " resources/create " , "params" : { "name" : " prospect-research-prompt " , "mimeType" : " text/plain " , "content" : " Research the following company and extract: ... " , "metadata" : { "ttl" : 3600 , "tags" : [ " prompts " , " prospecting " ] } } } Response { "uri" : " resource://prospect-research-prompt/abc123 " , "name" : " prospect-research-prompt " , "mimeType" : " text/plain " , "createdAt" : " 2026-04-14T00:00:00Z " } The returned URI can then be referenced anywhere a resource URI is accepted — in tool calls, job definitions, agent handoffs. Optional: resources/delete A corresponding resources/delete method for cleanup, scoped to resources the client created. Design Considerations Server-side storage is the server's concern. The spec should define the wire format only — how the server stores, indexes, or expires resources is implementation detail. TTL as optional metadata. Clients can signal that a resource is ephemeral. Servers may or may not honor it — same pattern as cache hints. Auth scoping. Resources created by a client should be readable by any client with appropriate access, or scoped to the submitting client. The spec should leave this to server implementation but define that the URI returned is the canonical reference. Binary content. content should support base64-encoded binary as well as plain text, using mimeType to signal encoding. Why not a custom tool? Custom tools work. But they push a general coordination primitive into application-specific territory. Every orchestrator, every job runner, every agent handoff system ends up building the same thing with slightly different interfaces. resources/create is the natural complement to resources/read . The spec already has the concept; this just makes it bidirectional. Prior art * HTTP PUT / POST for resource creation is universal * S3 presigned upload URLs follow the same pattern: submit content, get a reference back * MCP's own prompts primitive is close but scoped to server-defined prompt templates, not client-submitted content Reactions are currently unavailable Activity Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment Metadata Metadata Assignees No one assigned Labels No labels No labels Type No type Projects No projects Milestone No milestone Relationships None yet Development No branches or pull requests Issue actions * Open in GitHub Copilot app Footer (c) 2026 GitHub, Inc. Footer navigation * Terms * Privacy * Security * Status * Community * Docs * Contact * Manage cookies * Do not share my personal information You can’t perform that action at this time.