Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A critical look at MCP

raz.sh

Post reply on HN
Print view View original

91–100 of 348 posts

Re: A critical look at MCP

#91

Post by keithwhor »

keithwhor wrote: post #90

On MCP's Streamable HTTP launch I posted a issue asking if we should just simplify everything for remote MCP servers to just be HTTP requests. https://github.com/modelcontextprotocol/modelcontextprotocol... MCP as a spec is really promising; a universal way to connect LLMs to tools. But in practice you hit a lot of edge cases really quickly. To name a few; auth, streaming of tool responses, custom instructions per to…

Quick follow up:

I anticipate alignment issues as well. Anthropic is building MCP to make the Anthropic experience great. But Anthropic's traffic is fractional compared to ChatGPT - 20M monthly vs 400M weekly. Gemini claims 350M monthly. The incentive structure is all out of whack; how long are OpenAI and Google going to let an Anthropic team (or even a committee?) drive an integration spec?

Consumers have barely interacted with these things yet. They did once, with ChatGPT Plugins, and it failed. It doesn't entirely make sense to me that OpenAI is okay to do this again but let another company lead the charge and define the limitations of the end user experience (because that what the spec ultimately does, dictates how prompts and function responses are transported), when the issue wasn't the engineering effort (ChatGPT's integration model was objectively more elegant) but a consumer experience issue.

The optimistic take on this is the community is strong and motivated enough to solve these problems as an independent group, and the traction is certainly there. I am interested to see how it all plays out!

Re: A critical look at MCP

#92

Post by _raz »

keithwhor wrote: post #90

On MCP's Streamable HTTP launch I posted a issue asking if we should just simplify everything for remote MCP servers to just be HTTP requests. https://github.com/modelcontextprotocol/modelcontextprotocol... MCP as a spec is really promising; a universal way to connect LLMs to tools. But in practice you hit a lot of edge cases really quickly. To name a few; auth, streaming of tool responses, custom instructions per to…

Once I published the blog post, I ended up doing a similar thing the other day. https://github.com/modelcontextprotocol/modelcontextprotocol...

From reading your issue, I'm not holding my breath.

It all kind of seems too important to fuck up

Re: A critical look at MCP

#93

Post by lelanthran »

triyambakam wrote: post #30
neuroelectron wrote: post #7

MCP is the moat to keep small players outside of the AI market. Not only does implementing it require a team, it is a tarpit of sabotage, where logging and state are almost impossible to track.

Have you tried it though? There are sdks where you can set up logging and MCP server or client in a few lines. Pydantic AI and Logfire as one example

SDKs aren't a spec.

A spec is what I use to write an SDK.

Re: A critical look at MCP

#95

Post by wunderwuzzi23 »

hirsin wrote: post #13

In the same way that crypto folks speedran "why we have finance regulations and standards", LLM folks are now speedrunning "how to build software paradigms". The concept they're trying to accomplish (expose possibly remote functions to a caller in an interrogable manner) has plenty of existing examples in DLLs, gRPC, SOAP, IDL, dCOM, etc, but they don't seem to have learned from any of them, let alone be aware that t…

Your comment reminds me that when I first wrote about MCP it reminded me of COM/DCOM and how this was a bit of a nightmare, and we ended up with the infamous "DLL Hell"...

Let's see how MCP will go.

https://embracethered.com/blog/posts/2025/model-context-prot...

Re: A critical look at MCP

#96

Post by _raz »

dend wrote: post #89

Just to add one piece of clarification - the comment around authorization is a bit out-of-date. We've worked closely with Anthropic and the broader security community to update that part of MCP and implement a proper separation between resource server (RS) and authorization server (AS) when it comes to roles. You can see this spec in draft[1] (it will be there until a new protocol version is ratified). [1]: https://m…

Idk, I'm kind of agnostic and ended up throwing it in there.

Regurgitating the OAuth draft don't seem that usefull imho, and why am I forced into it if I'm using http. Seems like there are plenty of usecases where un-attended thing would like to interact over http, where we usually use other things aside from OAuth.

It all probably could have been replaced by

- The Client shall implement OAuth2 - The Server may implement OAuth2

Re: A critical look at MCP

#97

Post by keithwhor »

_raz wrote: post #92
keithwhor wrote: post #90

On MCP's Streamable HTTP launch I posted a issue asking if we should just simplify everything for remote MCP servers to just be HTTP requests. https://github.com/modelcontextprotocol/modelcontextprotocol... MCP as a spec is really promising; a universal way to connect LLMs to tools. But in practice you hit a lot of edge cases really quickly. To name a few; auth, streaming of tool responses, custom instructions per to…

Once I published the blog post, I ended up doing a similar thing the other day. https://github.com/modelcontextprotocol/modelcontextprotocol... From reading your issue, I'm not holding my breath. It all kind of seems too important to fuck up

In the grand scheme of things I think we are still very early. MCP might be the thing which is why I'd rather try and contribute if I can; it does have a grassroots movement I haven't seen in a while. But the wonderful thing about the market is that incentives, e.g. good customer experiences that people pay for, will probably win. This means that MCP, if it remains the focal point for this sort of work, will become a lot better regardless of whether or not early pokes and prods by folks like us are successful or not. :)

Re: A critical look at MCP

#98

Post by traviscline »

Thanks for this, I’ve been feeling similarly.

I’m working on some Go programs/tools with the explicit goal of describing existing servers in a language neutral manner to try to get some sanity into the mix.

I was reenergized to pick this back up because Google is working on a version so I want to get these tools ready.

Open to ideas and input, have been noodling on it for a bit now, lots not in form to share but figured I’d share early:

https://github.com/tmc/mcp

Re: A critical look at MCP

#99

Post by baxtr »

hirsin wrote: post #13

In the same way that crypto folks speedran "why we have finance regulations and standards", LLM folks are now speedrunning "how to build software paradigms". The concept they're trying to accomplish (expose possibly remote functions to a caller in an interrogable manner) has plenty of existing examples in DLLs, gRPC, SOAP, IDL, dCOM, etc, but they don't seem to have learned from any of them, let alone be aware that t…

To this date I have not found a good explanation what an MCP is.

What is it in old dev language?

Re: A critical look at MCP

#100

Post by sroussey »

neuroelectron wrote: post #29
hirsin wrote: post #20

Earlier quoted context omitted.

Indeed! But seemingly only for the actual object representation - it's a start, and I wonder if JSON is uniquely suited to LLMs because it's so text-first.

I think JSON is preferred because it adds more complexity.

I think it works because json is verbose and reinforces what everything is in each record.
Post reply on HN