SEP-2166: Out-of-Band Resource Access via HTTPS URLs#2166
Conversation
|
FYI @SamMorrowDrums since this touches on your past feedback. |
Proposes adding optional httpUrl and httpUrlExpiresAt fields to the Resource interface, enabling MCP servers to provide direct HTTPS access URLs alongside the canonical MCP resource URI. This allows resources to be accessed both through MCP (via resources/read) and directly via HTTPS by processes that may not have an authenticated MCP client connection, such as code executing in sandboxed environments.
|
I am super supportive indeed @localden it aligns perfectly with our raw file API. |
|
@SamMorrowDrums Very cool! Who else do you think I should ping to continue moving this forward? |
|
@abrookins hard to say, it's maybe adjacent enough to SDK transports that the official discord transports working group might be interested in. |
nbarbettini
left a comment
There was a problem hiding this comment.
Review from a security and protocol perspective - I can see part of the problem this is intended to solve, but I think it might be putting the cart before the horse. Detailed comments below!
| **The gap**: Sandboxed code execution environments may not have an authenticated MCP client connection. Without an MCP client connection to call `resources/read`, they cannot fetch the resource via MCP. However, they may have network access to make an HTTP request. | ||
|
|
||
| Anthropic's ["Code Execution with MCP"](https://www.anthropic.com/engineering/code-execution-with-mcp) describes how agents can reduce context overhead by executing code that calls MCP tools directly. However, this approach requires the execution environment to have an authenticated MCP client connection, which not all sandboxes or subprocesses will have. |
There was a problem hiding this comment.
This smells like an XY problem to me - I understand that execution sandboxes may have network access without an MCP access token, but is a network fetch the only way to get resource contents into a sandbox? My understanding is that accessing a resource via MCP and storing in a temp file (which is copied to the sandbox) is also a solution.
|
|
||
| 2. **Sub-Agent Delegation**: A recursive LLM architecture where a parent agent delegates work to child agents. The parent receives a resource via MCP and needs to pass a reference the child can access without an MCP connection. | ||
|
|
||
| 3. **Large File Downloads**: GitHub, OneDrive, and similar services want to maintain their internal resource naming while providing signed download URLs for efficient content delivery. |
There was a problem hiding this comment.
(3) makes sense to me since it's the canonical use of pre-signed URLs. Per my comment above, (1,2,4) feel like changing the protocol to solve an implementation problem. I might be missing something!
|
|
||
| 3. **Expiration**: When `httpUrlExpiresAt` is provided, clients SHOULD treat the URL as invalid after that time. Servers MAY reject requests to expired URLs with appropriate HTTP status codes (401, 403, or 410). | ||
|
|
||
| 4. **Authentication**: The `httpUrl` SHOULD be self-authenticating (e.g., signed URL with token) or accessible without additional authentication. Servers MUST NOT require MCP-specific authentication for `httpUrl` access. |
There was a problem hiding this comment.
Note that pre-signed URLs typically have some tight security constraints. Since they effectively amount to a bearer token encoded in a URL, they are usually very short-lived. If we recommend signed URLs, we need to point this out.
There was a problem hiding this comment.
Ah, I see it's mentioned down in the Security Implications section. 👍
| ### Why Not Two ResourceLinks? | ||
|
|
||
| Servers could return two `ResourceLink` items — one with an MCP URI, one with an HTTPS URL. However: | ||
|
|
||
| 1. **Semantic confusion**: The LLM sees two items that represent the same resource | ||
| 2. **No explicit relationship**: Nothing indicates they're equivalent | ||
| 3. **Duplication**: All metadata must be repeated |
There was a problem hiding this comment.
What about two ResourceLinks with differing properties to help an agent (or code) understand the semantics of each? I worry that directly encoding httpUrl into the protocol and hardcoding its semantics to always mean "pre-signed or unprotected URL that can be accessed out of band" is a pretty big opinion for the protocol to make.
Friendly ReminderHi @abrookins! This SEP proposal has been inactive for 91 days. We wanted to check in:
If this proposal is no longer being pursued, please let us know and we can close it. Otherwise, any update on the current status would be appreciated! This is an automated message from the SEP lifecycle bot. |
Proposes adding optional
httpUrlandhttpUrlExpiresAtfields to the Resource interface, enabling MCP servers to provide direct HTTPS access URLs alongside the canonical MCP resource URI.This allows resources to be accessed both through MCP (via
resources/read) and directly via HTTPS by processes that may not have an authenticated MCP client connection, such as code executing in sandboxed environments.Motivation and Context
Large tool outputs create context overhead when passed through LLM conversations. While Anthropic's "Code Execution with MCP" pattern allows agents to reduce this overhead by executing code that calls MCP tools directly, this requires the execution environment to have an authenticated MCP client connection, which sandboxes and subprocesses may lack.
This proposal enables servers to provide HTTPS URLs that any HTTP client can fetch, bridging the gap between MCP-connected contexts and disconnected execution environments.
Related discussions:
Resource.uriScopeto enable direct reads #607: Resource.uriScope (closed — needs SEP)How Has This Been Tested?
easy-mcp-proxy implements this pattern using a custom response format. The proxy caches large tool outputs, generates signed HTTPS URLs with expiration, and returns preview text plus retrieval URLs to clients. The pattern works well used with Claude Desktop (using the "All domains" allow list for sandbox access) and coding agents such as Augment Code. If this SEP is accepted, easy-mcp-proxy would be updated to use the standardized fields.
Breaking Changes
None. Both fields are optional additions to the existing
Resourceinterface.Types of changes
Checklist
AI Disclosure
This SEP was drafted with AI assistance (Augment Code). The problem definition, use cases, and technical approach were developed collaboratively with the author providing direction and review.