what were the MCPs that you've last compared?

what were the attributes that you've compared?

what made you decide between one or another?

Comments URL: https://news.ycombinator.com/item?id=49665535

Points: 1

# Comments: 0

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.

You may know me because of my Open-Source work like awesome-mcp-servers, FastMCP (node.js), ViteMCP, mcp-proxy, mcp-remote, and a few other projects in the MCP ecosystem, including Glama.

I was lucky enough to be present when MCP was first announced. That let me to contribute to the foundations of this new protocol and everything that has evolved around it. It also let me to be at the center of a lot of feedback, and by far the biggest complaint about the MCP ecosystem has been the inconsistent quality. Quality here means a lot of things, but server JSON definition is a big part of it. Bad tool definitions mean that tools are not selected when they should be, they are when they shouldn't, they are improperly invoked, etc.

TDQS is an open-source specification (https://github.com/glama-ai/tool-definition-quality-score) for evaluating the quality of the MCP server definitions. It's not a complete solution to the quality problem, but it is a research based rubric that increases clarity over what tools are available, what are their behaviors/purpose, and when/how they are supposed to be used.

TDQS is what Glama uses to score 15,000+ Open-Source and remote MCPs. And https://tdqs.dev is a free website to promote the spec and increase the adoption through better documentation and easy to use playground/CLI/API/SDKs.

Would love your feedback and participation in improving the quality of the MCP ecosystem.

Comments URL: https://news.ycombinator.com/item?id=49553343

Points: 8

# Comments: 1

  ┌─────────────────────────────┬────────┬───────────┐
  │ 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%     │
  └─────────────────────────────┴────────┴───────────┘

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.

Comments URL: https://news.ycombinator.com/item?id=48943532

Points: 1

# Comments: 0

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

Turns out GitHub quietly made the endpoint that fetches stargazers return an empty response.

https://github.blog/changelog/2026-06-30-upcoming-access-restrictions-to-public-api-endpoints-and-ui-views/

No email or any other warning was shared with developers.

Because we were overriding stargazers every time we fetch them, this resulted in wiping all the data that we have collected over the years. In our case, this data was used to customize user experience when browsing MCP server catalog – GitHub served as the source of truth of their 'favorite servers' – a completely legitimate use case to building a community around GitHub's public data. Many more use cases like this exist.

In GitHub's own words, they are doing this to prevent "spam", but this is really just GitHub increasingly gatekeeping their data and community. Sadly, the platform that was built for open-source is no longer open.

Comments URL: https://news.ycombinator.com/item?id=48920407

Points: 10

# Comments: 5

I am the author of FastMCP node.js framework – which is the most popular MCP framework in JavaScript ecosystem. However, "fastmcp" name clashes with another framework in Python ecosystem. Therefore, I have been trying to rename my project to vitemcp.

I own vitemcp.com, github.com/vitemcp, x.com/vitemcp, etc. _and_ I also own npmjs.com/vite-mcp

I have been trying to rename "vite-mcp" to "vitemcp" for over a month, but hit dead ends through every channel. Support refused the request on the grounds of 'security'

I would greatly appreciate anyone who could assist with the matter.

Comments URL: https://news.ycombinator.com/item?id=48858400

Points: 3

# Comments: 0

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.

Thank you Abdullah

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.

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

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?

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?

The service is mentioned in a few random Reddit threads as cost effective option, but I cannot find any discussions about accuracy of data.

How would one even go about verifying it?

For context, I am paying at the moment a few thousand/per month to another provider for IP data. I am not really using this data for anything other than have enough data to troubleshoot customer support/fraud. This service is promising unlimited IP data for USD 16/month, which sounds too good to be true, but there are many positive reviews across the Internet, so I am trying to evaluate if it is worth adopting.

Comments URL: https://news.ycombinator.com/item?id=47430475

Points: 1

# Comments: 10

Additionally, it was very important for me that the URL can capture the configuration of the MCP server. This allows me to save URLs to various MCPs that I am troubleshooting. Because the entire configuration is persisted in the URL, you can bookmark links to pre-configured MCP instances, eg

https://glama.ai/mcp/inspector?servers=%5B%7B%22id%22%3A%22t...

In order to ensure that the MCP inspector is fully spec compliant, I also shipped an MCP test server which implements every MCP feature. The latter is useful on its own in case you are building an MCP client and need something to test against https://mcp-test.glama.ai/mcp

Finally, MCP Inspector is fully integrated in our MCP server (https://glama.ai/mcp/servers) and MCP connector (https://glama.ai/mcp/connectors) directories. At a click of a button, you can test any open-source/remote MCP.

If you are building anything MCP related, would love your feedback. What's missing that would make this your go-to tool?

Comments URL: https://news.ycombinator.com/item?id=47408742

Points: 2

# Comments: 0