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

So funny how no one picked up on this.

I was expecting this to be the first comment.

Indeed, there are more mature solutions. The primary reason I made Pipenet is because I needed something that can be embedded in Node.js client.

I am keeping one eye on how this is scaling.

At the moment there are 5 active tunnels and CPU is at 2%.

I would therefore expect that this can scale quite a bit before it becomes some sort of bottleneck.

Who knows though – maybe I am underestimating the demand. Didn't expect this to get to the front page of HN.

You might need to define 'fast'.

This should not add more latency than your average VPN, since the overhead of websocket is minimal and roundtrip time is about the same.

At the moment, this is running on a single-instance with no load-balancing. The intended use case was to enable streaming of MCP SSE traffic, which is very lightweight. I would expect this to be able to handle a lot of traffic just like that, but if people start using the public instance for other use cases, I will need to think of ways to scale it.

Just plain HTML/CSS.

I did this morning in a rush. Didn't expect anyone to compliment it. Thank you!

The current implementation is HTTP-focused as that was the primary use case. TCP tunneling is possible architecturally but not something I've had in mind. I suggest start by raising an issue on GitHub and adding thumbs up. If it receives enough attention, I will prioritize it. I am less familiar with what would supporting UDP entail, so cannot answer that right now.

That list is where my research started! Was surprised not to find a pure node.js solution that's easy to self-host and has CLI/SDK.

Added https://github.com/anderspitman/awesome-tunneling/pull/214

Fascinating

There appears to be a lot of confusion in the comments around what the MCP is and how it is different API.

I've done a deep dive here before.

Hope this clears it up: https://glama.ai/blog/2025-06-06-mcp-vs-api

Yes, the exact same conclusion I arrived to.

I did find writing about it therapeutical though.

The goal is to move past the thought lingering at the back of my head.

OpenRouter, Glama ( https://glama.ai/gateway/models/claude-sonnet-4-5-20250929 ), AWS Bedrock, all of them provide you access to all of the AI models via OpenAI compatible API.

switched to Dragonfly and can confirm that the throughput makes a noticeable difference to the user experience

so this gives a good reason between valkey and redis, but what about dragonfly? some benchmarks show crazy advantage over Redis (and I assume valkey too)