41–50 of 58 posts
give it a try here: https://getaiko.app/downloads
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?
I was really hoping this would take off. https://github.com/universal-tool-calling-protocol
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
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 m…
Interesting we also just released our mcp gateway project under the name Hypr MCP[1]. [1]: https://github.com/hyprmcp/mcp-gateway
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?
Earlier quoted context omitted.
Interesting we also just released our mcp gateway project under the name Hypr MCP[1]. [1]: https://github.com/hyprmcp/mcp-gateway
Cool. I want to add dynamic client registration but haven't got around to do it yet.
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?
oauth2proxy actually doesn't work for MCP servers due to missing dynamic client registration..
Earlier quoted context omitted.
I was really hoping this would take off. https://github.com/universal-tool-calling-protocol
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. 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.
Whats hilarious about this whole AI hype is that probably a million people are building the exact same software at the moment.