i built maybe don't ai's mcp gateway——but to me the interesting technology isn't about the registry or flattening of downstream MCP servers (honestly that was a reasonably easy problem to solve) it's about the behavior of the AI agents that are connecting to these servers and making very bad decisions.
And yes to teh comments about people making a million of these... so very very many of them.
qwertox · 6h ago
> Caution: The current release (0.6.0) is considered alpha / early beta. It is not production-ready and should only be used for local development, testing, or experimentation. Features, APIs, and behaviors are subject to change without notice. Do not deploy in production environments without thorough security review, validation and additional security mechanisms. Many of the features required for secure, large-scale, or multi-tenant production deployments are still on the project roadmap - which is itself evolving.
IBM posting as if it were a solo open-source developer.
Not sure which of these tools is currently the best but they are clearly needed.
I am testing MetaMCP to expose internal MCP servers to the cloud version of Claude, enabling me to use Home Assistant and some other internal services in verbal conversations with Claude app on the phone.
I think 3rd party MCP server use is available in other AI assistants as well but Claude is the only one who allows using them in Europe.
I can only wish that this would become a standard approach with any AI assistants, including the built in phone assistants like Siri, but Apple is so so far behind and always trying to squeeze every bit of money wherever they can, I doubt they will ever do that.
This approach enables better integrations with local services specific to different regions, and I would somewhat compare this to RSS feeds which were popular 15 years ago. Would be nice if most e-commerce sites would provide their own MCP servers for managing carts, placing and tracking orders, etc. I don't want to see a world where single monopoly grabs this market and makes things shit again (like it happened with social media), especially for those who live outside of USA.
tuananh · 9h ago
I built hyper-mcp[1] as side project with each MCP as a WASM plugin.
The idea is each plugin runs in their own wasm vm with limited network/file system access. Plugins are written in any language, as long as they can compile to WASM and publish to OCI registry (signed & verified with sigstore)
Recently, Microsoft released their own version of hyper-mcp named Wassete[2]
Ideally, I want to make it like a gateway with more security & governance features in this layer.
Cool. I want to add dynamic client registration but haven't got around to do it yet.
pmig · 5h ago
Feel free to just include our gateway in your docker compose file.
fullstackwife · 8h ago
For many years we were fine with running DLLs, Java .class deps, npm modules, brew packages etc. why do you think we need so much isolation for left-pad class mcp tools?
pmig · 8h ago
These kind of gateways showcase that larger organizations will equip their employees with tools the same way employees are currently granted access to specific SaaS applications.
One of the bigger challenges we are currently observing is missing authorization for MCP servers.
We actually also just released a mcp-gateway[1] initially focusing on adding OAuth authorization to streamable HTTP MCP servers.
These words and that brand name don't go together here
blitzar · 9h ago
IBM pivoting to Ai, must be getting close to the top now.
fhd2 · 9h ago
Not sure I'd call that a pivot, they've been at it for many years and even at the forefront every now and then, e.g. IBM Watson. At least it seems like that from my non-specialist, outside perspective.
N_Lens · 7h ago
Actually already peaked.
Xantier · 9h ago
I find the context forge quite nice from IBM. I used a few approaches they've implemented within my Ctxpack context management solution as well.
I think the agentic use cases aside, the client side of MCPs are still lacking quite a bit and would need to mature to be able to catch up to the spec. I feel a lot of use cases exist outside of fully automated agentic approaches, since we can't really rely on LLMs yet to produce at a human level.
The underserved cases rely a lot on prompt and resource management at the moment. Being able to iterate and share those across teams to provide easy starting points to delegate tasks is something I feel would be workable for the current iteration of AI assisted work, outside of pure software engineering.
Hopefully other clients join VS Code Copilot to allow more varied approaches than just simple tool calls here. I think Copilot's approach on prompt and resource management isn't quite the best approach either though. It is still early days for MCPs in general so i think we'll see a lot of experiments in this space.
theshrike79 · 6h ago
So from what I gather this would be useful at a company level.
Everyone installs this gateway as their only "MCP", then at a central location we can add different MCP tools and everyone automatically gains access to them.
willahmad · 6h ago
I have built similar gateway but as a desktop application which runs locally and gives you a lot of control over enabled MCP tools and allows you to have a separate profiles for different combinations of MCP servers and credentials (e.g. profile with production API keys, sandbox keys and etc,.).
Ah nice an AI generated MCP gateway. I can't wait to see how many different agent/tool protocols we'll run through this year, and how many gateways. I just spin up oauth2proxy to handle authentication with istio gateway. Maybe I should be deploying piles of unknown code instead?
pmig · 5h ago
oauth2proxy actually doesn't work for MCP servers due to missing dynamic client registration..
GloriousMEEPT · 5h ago
You're right, we're not strictly implementing things according to the spec/oauth 2.1
42lux · 7h ago
Whats hilarious about this whole AI hype is that probably a million people are building the exact same software at the moment.
kenm47 · 10m ago
but mine is different and prettier because standards-xkcd.jpfeg
turblety · 7h ago
Isn't that beautiful. True competition. Shouldn't that be how the world works, businesses too? Lots of people, trying their best to build things, and some will share ideas, some with have their own unique points.
Or do we just want CorporateSoftTM to build and own everything in just one big single commercial platform?
I would love it if loads more businesses could start up.
42lux · 6h ago
No, dozens of companies burning money to reinvent the same thing, and the best product rarely wins anyway. You get locked into inferior systems just because they had better timing or marketing.
The romantic startup vision sounds nice, but most of those businesses would just fail after wasting capital and talent that could've been used better elsewhere. It's messy and inefficient.
>> Or do we just want CorporateSoftTM to build and own everything in just one big single commercial platform?
It's gonna get acquired anyways... what do you think the endgame of 99% of startups is? Building a company?
turblety · 6h ago
Maybe romantic, that's fair. But I think a world with lots of different choices and options is far better, than one with a single few efficient/optimal solutions.
Burning money to reinvent things is fine with me if it trains people up, pays people a salary, creates some original ideas, leads to more choice in the market.
42lux · 6h ago
But that's the whole point it never does lead to more choice in the market. Maybe for the year of the hype cycle after that it gets consolidated real quick.
turblety · 6h ago
We could say the same before AI, but I don't think it's true. Ignoring AI for a moment, if I look at databases as an example, there is lots of choice and competition out there:
MySQL, MariaDB, PostgreSQL, TimescaleDB, CockroachDB, YugabyteDB, Teradata, Snowflake, TiDB, SQLite, DuckDB, and more probably.
I think it's led to great choice and a great sharing of ideas. Theres also been a lot of failures too, that's true, but I'm sure some of those failures have led to a few unique features across those products too.
So now with AI, for me it's the same process, just accelerated. Yes, there is lots of junk coming out there, but I think there's lots of good too.
42lux · 6h ago
The situation differs when people work within established domains, where the foundational ideas have already been explored. atm everyone does exactly the same some with more salt some with more pepper. Just look back a few months how many of the RAG implementations survived?
theshrike79 · 6h ago
As long as everyone builds out in the open so people can share ideas, I think it's going to be a net positive.
thrance · 6h ago
More like a severe lack of communication and visiblity leading to vastly inefficient work duplication.
turblety · 6h ago
I don't think an efficient marketplace is really a world anyone wants to live in. No one would have a job, purpose, creativity, anything really. What's the purpose if everything is efficent.
danielbln · 6h ago
Considering the amount of new JS frameworks that came out even before the AI hype, I'm not sure things are super different now.
blitzar · 6h ago
vibe coding the exact same software at the moment
thecopy · 10h ago
Many Gateways popping up now, im also doing my own gateway (https://mcp-boss.com/) but im starting to worry its hard to compete with Docker, Microsoft, now IBM...
ares623 · 10h ago
You should pivot to building an MCP for all the MCP gateways
sublimefire · 7h ago
mcp is not the future IMO, agent2agent is, e.g. a2aproject/A2A
The problem with MCP is that it cannot reliably scale, so some abstraction is helpful, i.e. separate “agent” with its own instructions and a predefined set of tools.
jumploops · 10h ago
Does anyone use MCP within their product, or is the MCP ecosystem entirely focused on enabling new workflows within an existing chat/agent framework (a la Cursor or Claude code)?
Assuming the latter, are there any viable non-developer MCP clients?
blitzar · 6h ago
Yes, MCPs are just APIs but with a few extra steps and I hope it (or something like it) persists for a long time into the future. If all you want from an Ai assistant is content they scrapped a year ago then you dont need these things, otherwise you need a way to get live data or to take real time actions.
API's, even simple JSON data requests from websites and services were becoming increasing blocked behind cloudflare or hidden as a paid feature, MPC has revived (some of) the open data standards of the internet.
jascha_eng · 6h ago
We've deployed a few internal MCP servers (e.g. to access our slack messages, salesforce cases and other internal information)
MCP allows to both:
- Mount these into your chatbot of choice
- Use these in any automation (custom chatbot or other LLM flow) if your framework supports MCP
Tbf I am still under the impression that for the later use case you would rather use the (HTTP) API directly because MCP doesn't allow you to customize the tool descriptions and if you truly want to make your automation perform well you need to iterate on those in my experience.
I don’t really get it — designing a truly universal description language for all possible service endpoint types and protocols is a hard (arguably impossible) problem.
Writing a client capable of parsing and using that description isn’t much easier.
> designing a truly universal description language for all possible service endpoint types and protocols is a hard (arguably impossible) problem
Fair enough, but when restricting yourself to the problem of tool calling, giving the AI the ability to call APIs in a simplified way, rather than inventing a new communication protocol like MCP, is, in a lot of cases, better.
manojlds · 8h ago
Claude.ai and Claude Desktop are the main non developer MCP clients.
ChatGPT has limited MCP support as of now (read only use cases with deep research) but the expectation is that full MCP support might be dropping soon.
pmig · 7h ago
ChatGPT launching MCP support would dramatically improve adoption, but MCP server installation must become way easier to find non coding use case adoption.
Xantier · 9h ago
I've done a bit of research around trying to find the best, simple clients that don't need an engineering degree to set up but haven't really stumbled upon a good one yet. Claude desktop app advertises that they support all features (they don't), all the others with closer to full spec compliance are related to software development (VS Code and Continue etc.).
dalemhurley · 8h ago
MCP is one of the most powerful ways for app-to-app communication. Instead of having to hardcode against an API, the LLM can just request the latest API spec and request what it needs. As a developer you could completely skip the LLM.
And yes to teh comments about people making a million of these... so very very many of them.
IBM posting as if it were a solo open-source developer.
Not sure which of these tools is currently the best but they are clearly needed.
I am testing MetaMCP to expose internal MCP servers to the cloud version of Claude, enabling me to use Home Assistant and some other internal services in verbal conversations with Claude app on the phone.
I think 3rd party MCP server use is available in other AI assistants as well but Claude is the only one who allows using them in Europe.
I can only wish that this would become a standard approach with any AI assistants, including the built in phone assistants like Siri, but Apple is so so far behind and always trying to squeeze every bit of money wherever they can, I doubt they will ever do that.
This approach enables better integrations with local services specific to different regions, and I would somewhat compare this to RSS feeds which were popular 15 years ago. Would be nice if most e-commerce sites would provide their own MCP servers for managing carts, placing and tracking orders, etc. I don't want to see a world where single monopoly grabs this market and makes things shit again (like it happened with social media), especially for those who live outside of USA.
The idea is each plugin runs in their own wasm vm with limited network/file system access. Plugins are written in any language, as long as they can compile to WASM and publish to OCI registry (signed & verified with sigstore)
Recently, Microsoft released their own version of hyper-mcp named Wassete[2]
Ideally, I want to make it like a gateway with more security & governance features in this layer.
[1]: https://github.com/tuananh/hyper-mcp [2]: https://github.com/microsoft/wassette
[1]: https://github.com/hyprmcp/mcp-gateway
One of the bigger challenges we are currently observing is missing authorization for MCP servers.
We actually also just released a mcp-gateway[1] initially focusing on adding OAuth authorization to streamable HTTP MCP servers.
[1]: https://github.com/hyprmcp/mcp-gateway
I think the agentic use cases aside, the client side of MCPs are still lacking quite a bit and would need to mature to be able to catch up to the spec. I feel a lot of use cases exist outside of fully automated agentic approaches, since we can't really rely on LLMs yet to produce at a human level.
The underserved cases rely a lot on prompt and resource management at the moment. Being able to iterate and share those across teams to provide easy starting points to delegate tasks is something I feel would be workable for the current iteration of AI assisted work, outside of pure software engineering.
Hopefully other clients join VS Code Copilot to allow more varied approaches than just simple tool calls here. I think Copilot's approach on prompt and resource management isn't quite the best approach either though. It is still early days for MCPs in general so i think we'll see a lot of experiments in this space.
Everyone installs this gateway as their only "MCP", then at a central location we can add different MCP tools and everyone automatically gains access to them.
give it a try here: https://getaiko.app/downloads
Or do we just want CorporateSoftTM to build and own everything in just one big single commercial platform?
I would love it if loads more businesses could start up.
The romantic startup vision sounds nice, but most of those businesses would just fail after wasting capital and talent that could've been used better elsewhere. It's messy and inefficient.
>> Or do we just want CorporateSoftTM to build and own everything in just one big single commercial platform?
It's gonna get acquired anyways... what do you think the endgame of 99% of startups is? Building a company?
Burning money to reinvent things is fine with me if it trains people up, pays people a salary, creates some original ideas, leads to more choice in the market.
MySQL, MariaDB, PostgreSQL, TimescaleDB, CockroachDB, YugabyteDB, Teradata, Snowflake, TiDB, SQLite, DuckDB, and more probably.
I think it's led to great choice and a great sharing of ideas. Theres also been a lot of failures too, that's true, but I'm sure some of those failures have led to a few unique features across those products too.
So now with AI, for me it's the same process, just accelerated. Yes, there is lots of junk coming out there, but I think there's lots of good too.
The problem with MCP is that it cannot reliably scale, so some abstraction is helpful, i.e. separate “agent” with its own instructions and a predefined set of tools.
Assuming the latter, are there any viable non-developer MCP clients?
API's, even simple JSON data requests from websites and services were becoming increasing blocked behind cloudflare or hidden as a paid feature, MPC has revived (some of) the open data standards of the internet.
MCP allows to both: - Mount these into your chatbot of choice - Use these in any automation (custom chatbot or other LLM flow) if your framework supports MCP
Tbf I am still under the impression that for the later use case you would rather use the (HTTP) API directly because MCP doesn't allow you to customize the tool descriptions and if you truly want to make your automation perform well you need to iterate on those in my experience.
Writing a client capable of parsing and using that description isn’t much easier.
Unsurprisingly, it appears there’s no real spec: https://www.utcp.io/about/RFC
Fair enough, but when restricting yourself to the problem of tool calling, giving the AI the ability to call APIs in a simplified way, rather than inventing a new communication protocol like MCP, is, in a lot of cases, better.
ChatGPT has limited MCP support as of now (read only use cases with deep research) but the expectation is that full MCP support might be dropping soon.
MCP, is just a really good M2M documentation.