web-applets VS specification

That's specifically what I'm working on at [Unternet](https://unternet.co/), based on observing the same issue while working at Adept. It seems absurd that in the future we'll have developers building full GUI apps that users never see, because they're being used by GPU-crunching vision models, which then in turn create their own interfaces for end-users.

Instead we need apps that have a human interface for users, and a machine interface for models. I've been building [web applets](https://github.com/unternet-co/web-applets/) as an lightweight protocol on top of the web to achieve this. It's in early stages, but I'm inviting the first projects to start building with it & accepting contributions.

For those interested, I've been working on something related to this, Web Applets – which is a spec for creating AI-enabled components that can receive actions & respond with state:

https://github.com/unternet-co/web-applets/

No. Any file that runs MCP Server is fine anywhere. I am intending a workspace separate from the rails app. The MCP server should be run in a separate process from the rails app. At least until the streamable http transport is ready.

https://github.com/modelcontextprotocol/specification/pull/2...

Another aspect worth noting is that, to date, the protocol requires a persistent connection between client and server, so this can be a drawback for auto-scalable architectures that adapt to demand, as well as moving in the opposite direction in a world that is striving to become stateless.

The MCP protocol is evolving with proposals like the new Streamable HTTP transport that supports fully stateless servers without requiring long-lived connections. We're following these developments closely and evaluating how they might benefit the Supabase MCP experience.

I assume they're (for now at least) targeting the old HTTP+SSE version of MCP, and not the new Streaming HTTP version? https://github.com/modelcontextprotocol/specification/pull/2...

Really looking forward to integrating with these models.

The next version of Model Context Protocol will have native audio support (https://github.com/modelcontextprotocol/specification/pull/9...), which will open up plenty of opportunities for interop.

Yup. Though it's a JSON API and not an XML API like SOAP. As for how it differs form the old OpenAPI/Swaggar... shrug... not much... its got a lot less flexibility to it and it has specific tooling for agentic tool use.

https://github.com/modelcontextprotocol/specification/blob/m...

Hey Taylor! One of the creators of emcee here.

So... short answer... there isn't a great way right now. Currently emcee is communicating over stdio – and although MCP technically supports SSE, it isn't super friendly to remote workflows.

You can see it's definitely on the roadmap for MCP here, however: https://github.com/modelcontextprotocol/specification/discus...

Curious to hear how you were thinking of using emcee remotely? Feel free to email me at [email protected] too.

We've been keeping a close on this topic: https://github.com/modelcontextprotocol/specification/discus...

The options being considered to do this are: