punkpeye
Joined 4 years ago
Joined 4 years ago
There are over 1,000+ PRs on awesome-mcp-servers that are going to be closed and redirected to awesome-remote-mcp-servers. If you have a remote MCP server, now is a good time to submit.
┌─────────────────────────────┬────────┬───────────┐
│ Pushed in last 7 days │ 6,101 │ 9.9% │
├─────────────────────────────┼────────┼───────────┤
│ Pushed in last 30 days │ 18,707 │ 30.2% │
├─────────────────────────────┼────────┼───────────┤
│ Pushed in last 90 days │ 30,393 │ 49.1% │
├─────────────────────────────┼────────┼───────────┤
│ Pushed in last 365 days │ 54,327 │ 87.8% │
└─────────────────────────────┴────────┴───────────┘
So about ~30% are actively maintained. That's a pretty big portion of the community.However, the new protocol is wire-incompatible in both directions. This means that many of the servers/clients will need to be refactored (not enough to just update the SDK). It will take time and it will be messy (despite SSE deprecation, there are still many servers and clients that are SSE-only). Honestly, a legitimate opportunity for MCP gateways (ours included) to become more valuable by becoming an interoperability layer between protocol incompatible servers/clients.
I am running an MCP server gateway/registry (some of you may know Glama).
I cannot tell you what portion of our issues/bugs were due to the need to persist server state.
This change will allow us to offer a lot easier way for people to use Open-Source MCP servers.
Does anyone know what was the precise date when this change was rolled out?
I run an AI gateway (Glama), and we had to delist all third-party providers because some of them are obviously lying about their quantization.
Being able to vet providers would be a major improvement to our ability to offer a more diverse set of providers.