Support Streamable HTTP transport

[andrea-tr2]

Thanks for releasing this MCP server, it's a great initiative!
Would you consider adding support for the Streamable HTTP transport layer defined in the MCP spec? This would enable stateless, cloud-native deployments and allow integration with clients that cannot rely on SDIO or local filesystem access for context injection.

Reference: https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http

[nickwinder]

Thanks for the request!

We'd love to support Streamable HTTP, but sadly because the protocol does not allow for sending of blobs (i.e. the documents to work on) with the tool call, it's not possible for the user to pass the document to be worked on. This is why we had to opt for a file system approach.

Although, we may have missed something? Can you think of another way around this?

[andrea-tr2]

@nickwinder You're absolutely right that MCP doesn't support sending blobs directly in tool calls.
But what if "It's a feature, not a bug"...? I know how that sounds :)

I mean... rather than seeing it as a temporary limitation to work around, something to be patched in a future spec, it might be better seen as a deliberate design decision.
If that's the case, then MCP's architecture intentionally separates references from payloads, following the "upload first, reference later" pattern that many major cloud platforms have migrated to:

• AWS S3 uses pre-signed URLs... upload once, reference everywhere.
• Google Drive assigns file IDs... all operations use the ID, not the file.
• Slack recently deprecated files.upload for a two-step process (upload -> reference)
• DocuSign uses envelope/document IDs throughout workflows.
• Azure leverages SAS tokens for fine-grained access control.
• Google Cloud Storage implements signed URLs for secure and scalable transfers.

For Nutrient DWS MCP Server with Streamable HTTP, a clean, spec-compliant implementation could look like this:

1. Upload endpoint: POST /upload -> returns a document reference ID.
2. MCP tool call: Accepts reference ID (not raw file data)
3. Processing: The server fetches the document via the reference.

This approach delivers what we need:

• Stateless, cloud-native deployments.
• Independent scaling (upload infra vs. processing logic)
• Full MCP compliance (works perfectly with JSON-RPC constraints)
• Security best practices (time-limited access, no embedded credentials)

Does that make sense? Or maybe I’m the one who’s missed something?

[nickwinder]

Yeah, that makes complete sense. I’m also exploring an “upload first” workflow in other areas. However, this approach still has significant limitations within the current MCP ecosystem:

• It can’t be agentic — meaning a model can’t autonomously discover files from the kinds of services you mentioned and post them to an MCP server which may live in a different environment.
• It’s not compliant with the MCP client specification, thus it can't be a generic solution — It'd be great if users could drive the selection of files no matter the MCP client used.

That’s why I believe the protocol would benefit from supporting resource advertising and fetching on the client side. This would enable both agentic and user-driven workflows within the MCP client, while also accommodating the services you’ve referenced.

[andrea-tr2]

@nickwinder thanks for surfacing the agentic gap so clearly... I can see your points about the limits of "upload-first" workflows and how your proposed MCP spec direction inverts the model and shifts the burden away from orchestration glue code:

• Client as resource provider: "Available resources: [manifest]"
• Server requests on-demand: fetch(resource_id)
• Client streams data: Maintains protocol boundaries while enabling autonomy.

One more thing... given MCP’s 1MB content limit and Base64 overhead (~750KB effective), have you considered a hybrid approach?

• Small files (<750kb): Direct embedding in resource.content
• Large files: Reference via resource.uri + streaming fetch
• Security: Client-side OAuth tokens for source systems (Slack, Drive, etc.)

Also curious how you envision partial document handling? For instance, if an agent only needs to annotate pages 5-10 of a 200-page PDF. Would this be client-side responsibility, or could fetch(resource_id) eventually support selective access?

Thanks again for pushing this forward.

[nickwinder]

I did play with base64 solutions near the start, but found LLMs could not reliably transfer such data.

I can see how partial document handling could be beneficial, but again that'd require some client side, or local document editing features, most of which are not native to the platforms.

BUT we are exploring alternatives, so keep your eyes peeled. :)