▲ | pmig a day ago | |||||||
That's a good point, we really think that the future of MCP servers are remote servers, as running "random" software that has little to no boundaries, no verification or similar shouldn't be a thing. Is there a specific reason, you prefer stio servers over http servers? Which servers are you using? Thanks for the mcpb hint, we will look into it. | ||||||||
▲ | thamer a day ago | parent | next [-] | |||||||
> Is there a specific reason, you prefer stio servers over http servers? Yes: the main reason is that I control which applications are configured with the command/args/environment to run the MCP server, instead of exposing a service on my localhost that any process on my computer can connect to (or worse, on my network if it listens on all interfaces). I mostly run MCP servers that I've written, but otherwise most of the third party ones I use are related to software development and AI providers (e.g. context7, Replicate, ElevenLabs…). The last two costs me money when their tools are invoked, so I'm not about to expose them on a port given that auth doesn't happen at the protocol level. | ||||||||
▲ | robertlagrant a day ago | parent | prev [-] | |||||||
> as running "random" software that has little to no boundaries, no verification or similar shouldn't be a thing Would you class all locally running software this way, and all remotely running software the inverse? | ||||||||
|