Comment by maxwellg

Comment by maxwellg a day ago

4 replies

I can't wait for first-party remote MCP servers to become more common. Right now we're taking a strange detour of everyone trying to proxy everyone else's APIs and do manual API Key juggling because platforms aren't running their own MCP servers and clients don't support the latest OAuth changes.

In a year from now, Github will run a single public Github MCP server that you will connect to via OAuth - you won't need to install it locally or faff around with tokens or environment variables at all.

niel 16 hours ago

> In a year from now

You can get a taste of this already.

While they still call it a prototype/beta, Sentry's MCP server [0] is a model for others to follow when it comes to convenience and usefulness.

Remote-first with OAuth. The biggest hurdle to using it as-is at the moment, is that most clients don't natively support OAuth yet, so often you'll rely on a local proxy server, like mcp-remote [1], to handle auth. Clients will catch up.

[0] https://mcp.sentry.dev/

[1] https://github.com/geelen/mcp-remote

joshstrange 14 hours ago

I agree that we will probably move to first-party remote MCP servers in the near future which puts a lot of registries/etc in limbo.

That said, I think there might be a market for MCP servers that do more than the first-party client, it will really depend on what first-party support looks like. Did they implement all of their existing API in MCP or just a few parts?

However, my experience with MCP servers so far (and it’s super early days, I know), has taught me that in a lot of cases it’s better/easier to write your own MCP server/tools. A lot of MCP servers out there are sloppy and/or hard to run/debug. Since most tools are a thin layer over existing API/SDK calls it’s not hard to write (or LLM generate) the needed code which has the added bonus of giving you full control.

Even when an MCP server works 100% and is easy to run, it doesn’t always map 1:1 with the API and so I’ve run into “Yes, you can retrieve data object X but you can’t filter by Y because they didn’t implement that filter in the tool call”.

meander_water a day ago

This is kind of what smithery does already. You can choose to install a local server, or connect to a remotely hosted server on smithery after authenticating through your GitHub OAuth.

rvz 12 hours ago

> I can't wait for first-party remote MCP servers to become more common

> In a year from now, Github will run a single public Github MCP server that you will connect to via OAuth - you won't need to install it locally or faff around with tokens or environment variables at all.

That sounds horrific. GitHub is known for their unreliability and centralizing everything to GitHub which isn't a good idea.

Combining two bad standards (MCP and OAuth) doesn't make remote MCP servers secure either.