punkpeye

Every day awesome-mcp-servers receives 10-20 PRs that are for remote MCP servers. If you are not familiar, awesome-mcp-servers is only for open-source servers. However, this number is only increasing and I feel bad about just closing them. So I am starting awesome-remote-mcp-servers just for remote servers.

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.

Just ran some quick numbers. In our index of 62,726 Open-Source servers, ~18,000 have been pushed to in the last 30 days.

  ┌─────────────────────────────┬────────┬───────────┐
  │ 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.

Finally.

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.

I just saw it in agy and started using it without asking any questions. I did not notice any major difference.

This did not get enough attention.

Does anyone know what was the precise date when this change was rolled out?

This data was available via API endpoints, not something that needed scraping.

Incredible model quality to price ratio

Now this is brilliant.

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.

Just to close the (public) loop, the issue was that we were using wrong API endpoint: ipinfo.io/lite instead of api.ipinfo.io/lite.

Thank you Abdullah

Did a quick dive to explore viability of migrating to ipinfo. My idea was: use lite version for enriching everything and then use pay-as-you-go for enriching authenticated user sessions.

I couldn't get /lite/ to work. In a sample of IPs I've tried with, multiple are returning 404. Your website for the same IPs is returning information. Looks like these are just not included in the lite dataset?

Turns out there is no pay-as-you-go tier. Subscription is the only option. Not a deal breaker, but dissapointing setup.

I tried using the /lite/ endpoint to get country data, but it is giving 404 errors for valid IPs.

{ "status": 404, "error": { "title": "Wrong ip", "message": "Please provide a valid IP address" } }

> On the matter of advertised locations not matching actual location, I highly recommend reading this: https://ipinfo.io/blog/vpn-location-mismatch-report

Good read

Do you happen to know if anyone is compiling all of this data about VPNs into one place? It would be super interesting to know which VPNs are providing genuine services vs masquerading the locations. Maybe even an SEO for you.

> I highly recommend that you work with current day's data.

Just to clarify: You are suggesting that we don't pro-actively enrich every IP address, store IPs, and only enrich them when troubleshooting something?

So many of my open questions answered in one answer. Thank you.

A follow up based on new information - if 'geofeed' identifies something with wrong geo location, and your method detects different geolocation, what do I see as the consumer consuming your API? I am assuming the inferred data, but that also feels counter-intuitive (since the data does not align with what ASN/ISP are reporting).

How often does your active measurement data disagree with geofeed data?

How do you handle mobile/cellular IPs

> Do you really need large scale IP address enrichment of all the IP addresses that visit your website? If yes, then for the first layer use our free data that provides ASN and country information.

If I am troubleshooting a support case that is days/weeks/months old, wouldn't this mean that enriching this information at a later date may give me different data than what it was associated with at the time the requests were made? My understanding was that IPs get re-assigned.

How frequently do IP-to-location mappings change in practice?

Do you offer historical IP data snapshots?

What are some things you've automated using Axe?

Cool project!

Looks like this a known issue with embedding JSON.

I found a dozen of related issues in the context of Next.js:

* https://github.com/vercel/next.js/issues/40143

* https://github.com/vercel/next.js/discussions/39377

* https://github.com/vercel/next.js/discussions/66896

* https://stackoverflow.com/questions/75672103/how-can-i-block...

Crazy that this isn't addressed as it affects every website.

Despite what the status page says, their website is returning 502 and some of the static assets are returning 404s