MCP Hosting Working Group #220
Replies: 40 comments 48 replies
-
|
FYI, Glama is by far the largest hosting provider of MCPs. We are getting close to hosting 3k instances. I don't think WebSockets are necessary at all. SSE works perfectly fine, and scales better than websockets. The default SSE implementation provided in https://github.com/modelcontextprotocol/typescript-sdk has some stability issue. I plan to port our internal SSE transport to their official repository or release it as a standalone project (maybe part of https://github.com/punkpeye/mcp-client). The hardest part by far is how to make these servers persistent at scale, while keeping it cost effective. We've solved this problem, but it was a considerable amount of effort. However, on that point, the MCP protocol is evolving to also support stateless/HTTP based instances. The second issue (which is not specific to hosting), is that many of the servers simply do not work or do not have clear instructions for how to interact with them. I've seen different approaches thrown around. Smithery have been committing Dockerfiles to every repository. I appreciate the intention but many (most) of them do not work (as a result, I see this more of a growth hack than a genuine strategy to help the community). We ended up building an entire automated pipeline that uses a combination of AI, virtualized environments, and dedicated docker builders/registries, to evaluate, build, test and deploy servers. That's a lot of effort, and part of the biggest value prop on our part. If you are thinking of entering this space, you will need to figure that part out. More recently, we also allow MCP server authors to claim servers and edit the build configuration. Something that I have been exploring is consolidating different MCP providers under a single marketplace/gateway. I am sprinting towards providing a universal platform for logging, monitoring, payments, and credential sharing, and other providers can plug and play into the ecosystem. Drop me an email to [email protected] if you'd like to participate. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @punkpeye, Sorry, I forgot to mention Glama. I have to say: I really appreciate everything you do for the community. I’m open to reconsidering my stance on WebSockets. Maybe we can gather feedback on the current SSE implementation and work on making it more reliable. While I still believe we need unofficial support for WebSockets—at least for clients—I’m happy to discuss it further.
We fully recognize that challenge, which is why we believe pooling our efforts can be highly beneficial for everyone.
I completely agree. We need a solid approach to defining MCP packaging, as it seems to be a challenge for every MCP host. At the very least, ensuring that MCPs can be deployed seamlessly on any provider (Glama, Blaxel, Toolbase, etc.) without compatibility concerns should motivate us to tackle this issue.
That’s an excellent initiative, and I think it aligns perfectly with this Working Group. Here, we can define shared primitives that different providers can adopt. By the way, here’s a Google Doc I drafted quickly today—happy to challenge it and remove WebSocket from scope if needed: https://docs.google.com/document/d/10vK4VABLXVqlkT_1mKbzPJIf44NJp7UKYFj4yFJ_ALE/edit?usp=sharing. Let me know if you want direct edit access! |
Beta Was this translation helpful? Give feedback.
-
|
I would love to become part of this workgroup! With FLUJO, among other things, I am trying to provide a unified solution for "hosting" MCP servers locally. For this reason I already built a hotswap MCP bridge some time ago that is yet to be integrated. The idea is that FLUJO can manage and proxy MCP servers for other MCP clients while allowing a centralized management of API keys and env variables in FLUJO. For this reason I am very interested and eager to contribute to this WG! Count me in! |
Beta Was this translation helpful? Give feedback.
-
|
Hey @mario-andreschak! I appreciate you joining in! Let’s see how it goes—I believe gateway/proxy/bridge can definitely be a major stream within this WG, as it significantly expands MCP capabilities. I drafted a document today—let me know your thoughts on it from a bridge provider's perspective too: https://docs.google.com/document/d/10vK4VABLXVqlkT_1mKbzPJIf44NJp7UKYFj4yFJ_ALE/edit?usp=sharing. |
Beta Was this translation helpful? Give feedback.
-
|
@Joffref The document looks promising, right now I have not much to add on. The most important aspects I could think of right now (Discovery, Packaging, Transport improvements) are already mentioned in the document. I think Discovery is the most important aspect from a "local hosting" point of view. I imagine this ecosystem to grow and applications to emerge that have MCP capabilites - but are not per sé standalone MCP Servers. Imagine Google Chrome or Adobe Photoshop providing MCP-Server capabilites: We will not be able to "package" that, and likewise the influence we have on those big players will be marginal. The proxying/briding should be standardized too! Currently there are different approaches, each with their own focus. I've seen MCP Bridge, Hotswap MCP Bridge , MCP Proxy, MCP Proxy Python Supergateway.. There needs to be a better way. Because once we implement a new transport standard, all those solutions will already be outdated. Redarding configuration of MCP servers - (I am referring about the actual So while stdio should be supported by every server - and we could theoretically start a server with the stdio configuration and then connect with a different transport - that is just tedious and there is no standard on how to "combine" two different configs. At least nothing I am aware of. we're furthermore missing a "type" (stdio|sse|...) property on the general transport config union type to identify the type of transport config. Once this whole WG moves forward: How can I make sure to not miss out on any meetings? I want FLUJO to become somewhat of a reference implementation for MCP Clients, so it's of utmost importance to me to keep track of the latest developments and contribute my experiences with MCP. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @mario-andreschak, thank you for your careful review!
I hadn’t seen it that way, but that actually makes a lot of sense. I feel like this is also where bridges come into play. Am I understanding your vision correctly?
Could you elaborate on this point? As far as I understand, you'd like to specify the command to spin up the server locally, such as:
I was thinking about creating a public Google Group where we can share documents and meeting schedules. What are your thoughts? What would be the best solution? Again, thank you to you and the FLUJO team for your dedication to the WG! |
Beta Was this translation helpful? Give feedback.
-
Yes, absolutely. Maybe allow me to elaborate on FLUJO, because it's not just a mcp bridge.
For this reason, FLUJO needs to
You understood it perfectly! I am open to this discussion. And I would love to hear other opinions from other Hosters. I personally would say: If you're simply "using" an SSE based MCP Server as a Client, you dont need to spin it up. On the other hand: If you're "hosting" them, you need a way to start them. I may be mislead here, that was just my personal conclusion. Thats why I proposed to move the You already understood all that perfectly.
That sounds great! I will stay tuned for that. I dont know what's the best option here but Google Groups sounds fine to me. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the valuable feedback I received since the original publication! I've edited the original post and add the draft proposal for the MCP Hosting WG. The document, I hope, now better reflects a wider range of potential topics based on the discussion I had (like multi-tenancy, packaging, discovery, etc.) to ensure it's more inclusive from the start. Please consider this the latest version for discussion. Continued feedback is very welcome! |
Beta Was this translation helpful? Give feedback.
-
|
I’m very keen to be a part of the this group to help with discovery and connective layers. I’ve been building out open prototypes for adding mcp discovery over dns and with ideas for a concierge agent for the network graph layer between mcp systems and making good progress https://mcpintegrate.com/ |
Beta Was this translation helpful? Give feedback.
-
|
There’s a lot of great stuff from cloudflare implementing the new proposed remote mcp standard bridging out of stdio https://blog.cloudflare.com/remote-model-context-protocol-servers-mcp/ |
Beta Was this translation helpful? Give feedback.
-
|
I came across it yesterday, and it's definitely a solid approach. I'd love to bring some of their ideas into the WG, especially the OAuth approach, which I believe is well-suited for MCP hosting platforms. |
Beta Was this translation helpful? Give feedback.
-
|
Identity rbac per tool exposure control at the discovery layer makes a lot of sense to me |
Beta Was this translation helpful? Give feedback.
-
|
Do you mean introducing impersonation at the MCP level or the MCP "gateway"? So you can restrict the tools available to the agent depending on the user who called it? |
Beta Was this translation helpful? Give feedback.
-
|
yes, essentially a smart identity aware gateway layer that controls which which mcp tools in the inventory to expose based on who called it and even the context of the request. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Joffref - Thank you for kicking this off. I'm from AWS Identity and Access Management, and would love to join this working group! I'm hoping to contribute on improving user and agent authentication and authorization, especially when an MCP server is hosted somewhere, and needs to interact with downstream resource server(s) and other agents in one or multiple trust domains. There are many other aspects as well, e.g., how to run some coarse-grained authorization, or scale them up and down across a fleet of compute instances. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @fei-yuan! Thanks for your support—we love seeing cloud providers be part of this! AuthN/AuthZ is definitely something that requires an extensive specification effort. Just yesterday, I was talking about how we, as MCP providers, are currently building our own architectures without a structured approach. This will never succeed and will be a nightmare for end-users, given how complex it can be—especially with factors like impersonation, server-to-server authentication, and more! Let me know if you'd like writing access to the draft proposal to expand on Auth use cases. |
Beta Was this translation helpful? Give feedback.
-
Yes, exactly - and I'd like us to move away from impersonation, to delegation instead. Happy to add content to the draft proposal. |
Beta Was this translation helpful? Give feedback.
-
|
@Joffref I'm curious if you see this all as a single scope of work. Some of the things you mention are certainly worth standardizing. Other things, IMO, would be better left to implementation details of service providers. For example:
We've obviously seen a lot of work going into auth spec details from the MCP core team with the initial introduction of auth, and I'm sure there would be interest specifically in tackling enhancements on that issue by issue. Those things are all worth standardizing - you need coordination among providers of different services to bring value props to end users - and I think very much would benefit from your thinking here. Infra details like load balancing, scalability, deployment strategies, monitoring, and logging -- I'm not as convinced you need a specification for those. While I don't expect there to be a single "MCP host service" out there that 100% of the community uses, I do expect there to be maybe a handful of major providers serving 80% of the community, and a long tail of niche providers serving the rest, self-hosting on barebones infra included. Key thing here is that you don't need to solve some major coordination problem. The hosting service providers can just be opinionated and optimize for their target market. I think it's fair to discuss the last bit if you feel strongly on it, but my suggestion is to break down the scope here into more manageable parts and plug into some of those existing threads and topics where relevant. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @tadasant, if the question is whether I see all of this being part of the MCP standard—the answer is no. I also think some aspects can be addressed by providing a sample implementation that service providers can choose to adopt or not, but it's still worth demonstrating.
I completely agree, which is why I believe this group is valuable. The goal is not to create our own RFC but rather to identify relevant ones, contribute our perspective, and collaborate as a group to tackle them.
I totally agree on this point. I think I should remove it from the proposal to avoid any confusion. My intent was more about sharing knowledge rather than defining specifications.
You're right—I’ll work on listing the relevant issues, discussions, and topics and map them within the scope so we have more actionable items. |
Beta Was this translation helpful? Give feedback.
-
|
I see DIDs entering the room. Or maybe UCANs https://github.com/ucan-wg
…On Thu, Mar 27, 2025 at 7:10 AM Fei ***@***.***> wrote:
Hi @fei-yuan <https://github.com/fei-yuan>! Thanks for your support—we
love seeing cloud providers be part of this!
AuthN/AuthZ is definitely something that requires an extensive
specification effort. Just yesterday, I was talking about how we, as MCP
providers, are currently building our own architectures without a
structured approach. This will never succeed and will be a nightmare for
end-users, given how complex it can be—especially with factors like
impersonation, server-to-server authentication, and more!
Let me know if you'd like writing access to the draft proposal to expand
on Auth use cases.
Yes, exactly - and I'd like us to move away from impersonation, to
delegation instead. Happy to add content to the draft proposal.
—
Reply to this email directly, view it on GitHub
<#220 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAN5V5UCREVRE3K4WHQ4A32WOI5PAVCNFSM6AAAAABZUOYIQGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENRTGY3DCMQ>
.
You are receiving this because you are subscribed to this thread.Message
ID:
<modelcontextprotocol/specification/repo-discussions/220/comments/12636612
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
I feel that a protocol like Macaron makes a lot of sense here. I used to think it was overly complicated for most use cases, but agentic ones are definitely well-suited for this kind of authorization. |
Beta Was this translation helpful? Give feedback.
-
|
Hey Toolbase creator here! Thank you for reaching out and proposing all this 🚀 Would definitely love to join this WG and collaborate (will give suggestions by EOD on the draft) My background with MCP / Toolbase:
I think this WG would be excellent with regards to figuring out how we should standardizing remote MCP servers. Although auth has already been specced out, there are also the intricacies of configuration management, encryption and other best practices we can def work or agree upon. Could definitely also ship out frameworks, transports, or anything! On the local MCP side, which i've seen my users requesting as well, determining what is secure and best practice would be huge. And the biggest thing, how do we potentially bridge the gap for local MCP to be accessed by remote MCP clients. Def lots of ideas we can or should scope potentially to focus on, but all this really makes sense |
Beta Was this translation helpful? Give feedback.
-
|
Hey @gching! Happy to have you on board! Looking forward to your suggestions. I'm currently working on collecting relevant issue #s and discussion #s to add to each scope. If you have any ideas, feel free to suggest them as well!
I find this idea really interesting, especially for large companies where some remote agents need to be accessible to all employees while still requiring access to their local machines. The Roots feature offers a glimpse of this, but it might not fully cover all the cases you have in mind. |
Beta Was this translation helpful? Give feedback.
-
|
Would love to be involved as well, I'm also interested in a separate working group (potentially? or we just setup a general wg for various items) around search and proxying. What are next steps here? |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your interest! The next step will be to schedule a meeting with everyone and kick off this initiative, provided that everyone agrees on the proposal. 💯 |
Beta Was this translation helpful? Give feedback.
-
|
Hey everyone! I’ve just updated the doc to better reflect which issues will be in the scope of this WG. Let me know what you think! |
Beta Was this translation helpful? Give feedback.
-
|
@Joffref great proposal and I would love to join the working group. I am a principal engineer at AWS working in the generative AI space and have worked on Amazon Bedrock for past couple years. Multi-tenancy definitely needs more discussion -- some of the standard multi-tenancy patterns like:
|
Beta Was this translation helpful? Give feedback.
-
|
Hey @000-000-000-000-000, thank you for your interest! I agree on multi-tenancy. From my perspective, points 1 and 2 are critical for the initial adoption of hosting MCP servers, as they are strict requirements in my view. I also agree on points 3 and 4— for those exposing APIs (such as SaaS), these two will strongly encourage adoption. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Joffref, thanks for initiating this working group! I'm working on deploying MCP servers in FaaS environments, where state persistence is particularly crucial. When using SSE, I encountered issues where session IDs weren't properly routed to the same function instance, causing state loss. I've experimented with a simple WebSocket implementation in Golang as an alternative approach. I'm excited to learn from everyone's experience here, especially from those who have dealt with MCP at scale. Will be following this discussion closely to understand the best practices and challenges in MCP hosting. Looking forward to learning from the group! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @OhYee, thank you for your interest in this group! I also agree that in some environments, SSE can be a pain, and we should consider alternative stateful transports. WebSocket is one of them, and I firmly believe it could be a valuable addition to the transport protocol available on MCP. |
Beta Was this translation helpful? Give feedback.
-
|
I am curious about the future of WebSocket & SSE. As far as I understood, both are already obsolete. |
Beta Was this translation helpful? Give feedback.
-
|
Right, SSE is now deprecated in favor of HTTP streaming. However, the way it works is very similar to SSE. I believe we could benefit from another transport that inherently maintains session ID knowledge within the transport itself, rather than relying on the client implementation for that. |
Beta Was this translation helpful? Give feedback.
-
I'm not sure whether WebSocket or Streamable HTTP would be the better choice, but I've found several WebSocket-based implementations that meet my needs. While I'm open to trying Streamable HTTP when standard implementations become available。 I find SSE to be an unusual technical choice. For scenarios requiring bidirectional communication, there's little reason to choose SSE over alternatives |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone (@punkpeye @mario-andreschak @McSpidey @fei-yuan @tadasant @gching @patwhite @000-000-000-000-000 @OhYee @robertDouglass and others following!), Thanks again for the great discussion and interest in the MCP Hosting WG! Let's get our kick-off meeting scheduled (aiming for ~60 minutes next week). ➡️ Please indicate your availability by reacting with the corresponding emoji to the poll down below by Friday, April 4th, 2025. Here’s the draft proposal doc based on our discussion, incorporating feedback, clarifying scope, and mapping to existing issues where possible: 📄 Updated Proposal: https://docs.google.com/document/d/10vK4VABLXVqlkT_1mKbzPJIf44NJp7UKYFj4yFJ_ALE/edit?tab=t.0#heading=h.y038o2yoqloo Please take a look before the meeting if you can. The goal for the kick-off is to do introductions, discuss/refine this proposal, agree on how we'll communicate, and outline next steps. A proposed agenda is available here, still open for suggestions: https://docs.google.com/document/d/1Q-tchk_aLLZyAyuPxNreentn3i_dNR5x2rfO0h_5jR0/edit?usp=sharing Communication Channels: Until we establish a clear approach for managing meeting invites, minutes, and announcements, we'll continue using this GitHub Discussion thread for broader asynchronous discussion. We can finalize the communication strategy in the meeting. Scheduling Poll: (React with the corresponding emoji to indicate your availability)
Looking forward to getting this group started! 🚀 |
Beta Was this translation helpful? Give feedback.
-
|
doodle.com?On 2. Apr 2025, at 01:49, Mathis Joffre ***@***.***> wrote:
Hi everyone ***@***.*** @mario-andreschak @McSpidey @fei-yuan @tadasant @gching @patwhite @000-000-000-000-000 @OhYee @robertDouglass and others following!),
Thanks again for the great discussion and interest in the MCP Hosting WG! Let's get our kick-off meeting scheduled (aiming for ~60 minutes next week).
➡️ Please indicate your availability by reacting with the corresponding emoji to the poll down below by Friday, April 4th, 2025.
Here’s the draft proposal doc based on our discussion, incorporating feedback, clarifying scope, and mapping to existing issues where possible:
📄 Updated Proposal: https://docs.google.com/document/d/10vK4VABLXVqlkT_1mKbzPJIf44NJp7UKYFj4yFJ_ALE/edit?tab=t.0#heading=h.y038o2yoqloo
Please take a look before the meeting if you can. The goal for the kick-off is to do introductions, discuss/refine this proposal, agree on how we'll communicate, and outline next steps. A proposed agenda is available here, still open for suggestions: https://docs.google.com/document/d/1Q-tchk_aLLZyAyuPxNreentn3i_dNR5x2rfO0h_5jR0/edit?usp=sharing
Communication Channels:
Until we establish a clear approach for managing meeting invites, minutes, and announcements, we'll continue using this GitHub Discussion thread for broader asynchronous discussion. We can finalize the communication strategy in the meeting.
Scheduling Poll:
(React with the corresponding emoji to indicate your availability)
Monday, April 7
😄 09:00 – 10:00 PDT (16:00 – 17:00 UTC)
👍 10:00 – 11:00 PDT (17:00 – 18:00 UTC)
Wednesday, April 9
🚀 09:00 – 10:00 PDT (16:00 – 17:00 UTC)
Thursday, April 10
🎉 09:00 – 10:00 PDT (16:00 – 17:00 UTC)
❤️ 10:00 – 11:00 PDT (17:00 – 18:00 UTC)
Friday, April 11
👀 09:00 – 10:00 PDT (16:00 – 17:00 UTC)
Looking forward to getting this group started! 🚀
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Hi @Joffref, thanks for setting all this up! I'm currently building a platform to deploy MCP servers similar to the aforementioned ones and would love to be of any help possible. I think standardizing websockets and packaging are crucial. I also read through the doc and can't wait to get started - thanks once again! |
Beta Was this translation helpful? Give feedback.
-
|
Hi @aksheyd! Thank you for joining the conversation! Happy to have you on board. Let’s discuss the WG priorities in our next meeting! |
Beta Was this translation helpful? Give feedback.
-
|
Excited to join tomorrow guys! For broader context - we're building a toolbox that provides tool discovery and selection for agents. |
Beta Was this translation helpful? Give feedback.
-
|
Great to see everybody on the call today! Here's my short LinkedIn post on
the topic, and an invitation to connect with me =)
https://www.linkedin.com/feed/update/urn:li:activity:7316136944923496448/
…On Wed, Apr 9, 2025 at 10:24 PM Achintya Ashok ***@***.***> wrote:
Excited to join tomorrow guys! For broader context - we're building a
toolbox that provides tool discovery and selection for agents.
—
Reply to this email directly, view it on GitHub
<#220 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAN5V4N43WLM677KZLXS232YV6X7AVCNFSM6AAAAABZUOYIQGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENZYGMZTENY>
.
You are receiving this because you were mentioned.Message ID:
<modelcontextprotocol/modelcontextprotocol/repo-discussions/220/comments/12783327
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
@Joffref I had to miss the working group meeting unfortunately. Any notes / action items from the call? |
Beta Was this translation helpful? Give feedback.
-
|
Hey @000-000-000-000-000! I posted a message below. |
Beta Was this translation helpful? Give feedback.
-
|
Hey all! Thank you all for coming today — this was definitely a great start for the initiative! Here's today's meeting notes Before our next session (in a week - same day, same time) please review the proposal. Feel free to leave comments directly on the document. For those who haven't join the discord yet, I'm moving the conversation here. You can find a link in the today's meeting notes. We’ll be setting up a shared calendar soon to help everyone stay in sync. Thanks again for a great first meeting! |
Beta Was this translation helpful? Give feedback.
-
|
If folks haven't seen this yet, there is a formal proposal to update the authorization specification for MCP, put together in collaboration with quite a few securit folks, captured in #284. Please add your feedback, since it would be relevant to remote MCP servers. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @localden! I’ve republished your message in the MCP Community Working Groups Discord. I’d also like to invite you to join — we’re building this Discord to bring together everyone working on MCP standardization. You’ll find people there who are eager to review and collaborate on specifications, including folks from AWS, GitHub, Snowflake, and more. The invite link is in the meeting agenda (we don't share it publicly here to avoid any confusion for newcomers). |
Beta Was this translation helpful? Give feedback.
-
|
Excellent, thanks @Joffref - joined that one too 😀 |
Beta Was this translation helpful? Give feedback.
-
|
Hey guys, sorry I missed the meeting, sounded great, I added some notes. I'm working on two spec changes already which might be relevant - the first I have a PR for review which is to support search instead of straight pagination on lists (#322) and the second is to support namespacing, both I think are relevant for the hosted discussion. Also, if anyone is interested, we just tagged out a VERY early alpha of a go horizontally scalable MCP server, ScaledMCP (https://github.com/Traego/scaled-mcp) which I think is also very relevant for this group, would love contributions or thoughts. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @patwhite! No worries about missing the first meeting — we’ll see each other next week, same day and time. |
Beta Was this translation helpful? Give feedback.
-
|
@Joffref thanks buddy, will join the discord! |
Beta Was this translation helpful? Give feedback.
-
|
Hi Everyone - one more PR that I think is relevant to this group, and which I'd love thoughts and comments on - specifcally around Namespacing. One of the major issues of MCP at scale is how to segregate tools and intelligently avoid naming collisions. This is a proposal to do a very light touch formalization of namespaces, with a couple of helper methods for things like listing namespaces, getting all tools in a namespaces, etc. |
Beta Was this translation helpful? Give feedback.
-
|
For MCPI I use the servers domain name for its namespace |
Beta Was this translation helpful? Give feedback.
-
|
so you're referring to the tool name itself, basically prefixing the tool with www.google.com/get_weather? Ya, I think this is definitely a different proposal, but we could do @www.google.com with a very small tweak to the spec |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, essentially I formed the equivalent of an FQDN based url for remote tool addresses |
Beta Was this translation helpful? Give feedback.
-
|
ya, I think there's a good argument to have a reserved first character the really separates namespaces from just the rest of the tool, but it's something to think about |
Beta Was this translation helpful? Give feedback.
-
|
@Joffref I missed the meeting as I was traveling last week, is there a next meeting? I will go through the thread and would love to connect back on this. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @fei-yuan! No worries about missing the first meeting — we’ll see each other later this week, same day and time. We’ve also set up an MCP Community Working Groups Discord — feel free to join! There are already a few folks from AWS in there. The invite link is in the meeting agenda (we're not sharing it publicly here to avoid confusion for newcomers): |
Beta Was this translation helpful? Give feedback.
-
|
We built ToolHive, for this exact reason. We wanted to make running MCP servers safe, secure and easy. We even added an auth layer for those who want to be a bit more strict with access control. |
Beta Was this translation helpful? Give feedback.
-
|
Hey everyone! We recently created a Google Group for the MCP Hosting WG: https://groups.google.com/g/mcp-hosting-wg. This group serves as a convenient way to share documents and meeting invites with each other. I've added the group to the recurring meeting that will take place every Thursday at 9 AM PDT — let me know if you received the invite after joining. We’ll continue using the same document for the agenda: https://docs.google.com/document/d/1Q-tchk_aLLZyAyuPxNreentn3i_dNR5x2rfO0h_5jR0/edit?usp=sharing. I’ll update it later today — the main topic will be the WG proposal: https://docs.google.com/document/d/10vK4VABLXVqlkT_1mKbzPJIf44NJp7UKYFj4yFJ_ALE/edit?tab=t.0#heading=h.y038o2yoqloo, so we can reach alignment. Feel free to add any topics you’d like to discuss as well. For reference, here are the meeting details to make sure everyone is up to date:
|
Beta Was this translation helpful? Give feedback.
-
|
Greetings! |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone, I'd like to share that Choreo recently introduced native support for MCP server hosting, extending all of our platform capabilities to MCP servers. Some highlights of what Choreo now offers for MCP servers:
Regarding server persistence and operational efficiency - currently, Choreo maintains MCP server state within container instances. While we're still working on implementing auto-scaling for MCP servers (not yet available), we've designed our deployment architecture to maximize individual server stability and reliability. Our approach focuses on ensuring consistent performance through robust health monitoring, automated restarts for failed instances, and comprehensive logging for troubleshooting. We're eager to contribute to the standardization efforts around transport protocols, multi-tenancy, packaging, and discovery. We are also learning along the way and looking forward to collaborating with everyone here to address the evolving challenges in MCP hosting! |
Beta Was this translation helpful? Give feedback.
-
|
Hi folks, Gutted to have missed the last meeting! We're a fellow YC company called OpenInt and we build an opensource integrations platform. We're interested in contributing to the infra around auth. We just released a research preview of what a safe local CLI for MCP should look like (Sandboxing + observability). The same principles can be extended for the cloud in Kubernetes. We're not interested in hosting servers, are sharing this as a research preview and we'd love to support the MCP ecosystem. If anyone has any feedback or would like to chat please drop me a line at amadeo [at] openint [dot] dev! Looking forward to joining the WG. |
Beta Was this translation helpful? Give feedback.
-
|
Hi guys! Not sure if this has been discussed here although I couldn't find a mention of it in the thread, but with respect to the impersonation vs. delegation question for authn and authz, it seems like some of this debate has been resolved although possibly not with respect to multi-tenancy patterns: https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization#1-introduction |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone As I see one of the major challenges around MCP is that it's a statefull protocol. Due to that, it requires a significant amount of effort and special handing to build an MCP solution that can horizontally scale, manage load balancing and maintain high availability and 0-downtime on upgrades etc. I already have some ideas on how to tackle some of these problems but I'd like to hear some more educated opinions and maybe to take an active part in shaping the future of the MCP protocol and designing and building solutions that can serve the entire community. Cheers! |
Beta Was this translation helpful? Give feedback.
-
|
@Joffref will love to know your perspective on scaling mcp servers horizantally |
Beta Was this translation helpful? Give feedback.
-
|
I did some load testing on an example MCP server, the results for STDIO weren't shocking, but I was surprised with how scalable StreamableHTTP was by default. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @dlahyani! Good point on state management — it’s definitely the biggest scaling pain point right now. You can enable session stickiness on your load balancer, but that’s not ideal if you want to roll out new versions of your MCP without downtime, since under high load, sessions can last anywhere from a couple of minutes to dozens of minutes (with no limit defined in the spec). I believe @patwhite has a lot of thoughts on that. I previously drafted the following document, which could use some revamping and should probably be opened as an SEP in the MCP repository. It proposes managing session lifecycles by defining a standard interface for storage providers (e.g., Redis, Cloudflare KV) to help MCP builders manage state across multiple MCP instances: https://github.com/modelcontextprotocol-community/working-groups/pull/34/files |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Pre-submission Checklist
🚀 Your Idea: Proposal for an MCP Hosting Working Group (WG)
TL;DR: Proposing an MCP Hosting Working Group (WG) to address growing challenges in scaling/managing MCP servers. Focus areas include transports, multi-tenancy, packaging, discovery, etc. Seeking feedback on the draft proposal (linked above) and interest in participating.
Hey everyone,
I'm Mathis from Blaxel, where we provide hosting solutions for MCP servers. As MCP adoption grows, we're seeing increasing challenges around deploying, scaling, and managing servers effectively across different environments. While the MCP community has made great strides for consumers and authors, the operational and hosting aspects need more focused attention.
🤝 To address this collaboratively, I'd like to propose forming an MCP Hosting Working Group (WG).
The goal is to bring together hosting providers, developers, operators, and other interested parties to tackle important hosting-specific topics. Based on recent discussions and needs, potential areas of focus could include:
📄 Draft Document for Discussion:
I've put together an initial draft proposal outlining this vision and scope in more detail. It's intended purely to spark discussion and gather feedback:
View the Draft Proposal Here
We believe that by collaborating with others in the ecosystem (like Glama, Smithery, ToolBase, InstantMCP, and the wider developer/user community), we can significantly improve the MCP hosting experience and ensure its continued success.
🤔 Your Feedback Needed:
Looking forward to hearing from you!
Scope
Beta Was this translation helpful? Give feedback.
All reactions