Live data from Hacker News

MCP: An in-depth introduction

speakeasy.com

41–50 of 96 posts

Re: MCP: An in-depth introduction

#41
post #3

Earlier quoted context omitted.

This is a VFAQ https://hn.algolia.com/?q=what+is+mcp But to save you the click & read: it's OpenAPI for LLMs

OpenAPI for LLMs is such a good way to describe it!

Seems apt to me as well.

Before the whole "just use OpenAPI" crowd arrives, the point is that LLMs work better with curated context. An OpenAPI server not designed for that will quickly flood an LLM context window.

Re: MCP: An in-depth introduction

#43

> But even after a few hours of reading about what MCP is and working through an example , it can be confusing to follow exactly what is happening when and where. What does the LLM do? What does the MCP server do? What does the MCP client do? Where does data flow, and where are choices made? Yeah MCP is the worst documented technology I have ever encountered. I understand APIs for calling LLMs, I understand tool call…

I find the opposite after reading the spec. Did you read the spec? I mean the actual spec. not Python API documentation and such. :)

It’s just JSON RPC between a client, one or more servers. The AI agent interaction is not part of what the protocol is designed for except for re-prompting requests made by tools. It has to be AI agnostic.

For tool call workflow: (a) client requests the list of tools from the known servers, then it forwards those (possibly after translating to API calls like OpenAI toolcall API) to any AI agents it wants; when the AI then wants to call a tool (b) it returns a request that needs to be forwarded to the MCP server for handling; and (c) return the result back to the AI.

The spec is actually so simple no SDK is even necessary you could just write a script in anything with an HTTP client library.

Re: MCP: An in-depth introduction

#44

I have trouble understanding the level of criticism about MCPs. As I understand it, it's just a tool that allows an LLM to communicate with other tools. People often talk about web APIs, but we should also consider the integration of local tools. For me, the integration is mind-blowing. When I tried the Playwright MCP integration [0][1] a few months ago, I really felt that after giving computers the ability to speak…

> For me, the integration is mind-blowing. When I tried the Playwright MCP integration ... I still get goosebumps thinking about it.

Same. To see apps reverse engineered by LLMs with Ghidra [0] blew me away. It CTFed-out hard-coded access tokens and keys from .so's in seconds.

[0] https://github.com/LaurieWired/GhidraMCP

Re: MCP: An in-depth introduction

#45

> But even after a few hours of reading about what MCP is and working through an example , it can be confusing to follow exactly what is happening when and where. What does the LLM do? What does the MCP server do? What does the MCP client do? Where does data flow, and where are choices made? Yeah MCP is the worst documented technology I have ever encountered. I understand APIs for calling LLMs, I understand tool call…

MCP is a kitchen sink of anti-patterns. There's no way it's not forgotten in a year, just like Langchain will be

Since when in the history of computing has the former implied the latter?

Re: MCP: An in-depth introduction

#46
post #43

> But even after a few hours of reading about what MCP is and working through an example , it can be confusing to follow exactly what is happening when and where. What does the LLM do? What does the MCP server do? What does the MCP client do? Where does data flow, and where are choices made? Yeah MCP is the worst documented technology I have ever encountered. I understand APIs for calling LLMs, I understand tool call…

I find the opposite after reading the spec. Did you read the spec? I mean the actual spec. not Python API documentation and such. :) It’s just JSON RPC between a client, one or more servers. The AI agent interaction is not part of what the protocol is designed for except for re-prompting requests made by tools. It has to be AI agnostic. For tool call workflow: (a) client requests the list of tools from the known serv…

Oh, there's a spec! Something concrete, with definitions?! I'm starting to read now, and for the first time I understand something concrete, even if it's still somewhat verbose.

I've spent so much time clicking through pages and reading and not understanding, but without finding the spec. Thanks so much!

Re: MCP: An in-depth introduction

#47
It's a half-baked, rushed out, speculative attempt to capture developer mindshare and establish an ecosystem/moat early in a (perceived) market. It's a desperate "standard" muscled in by Amazon/Claude, similar to their overwrought "Smithy" IDL that basically nobody outside the Amazon SDK team chooses to use for API/Schema management. It will end up in that same niche in the long term, most likely... AWS/Amazon/Claude specific app integrations, buried underneath some other 3rd party framework that abstracts it away and makes the "spec" irrelevant.

Re: MCP: An in-depth introduction

#48
post #47

It's a half-baked, rushed out, speculative attempt to capture developer mindshare and establish an ecosystem/moat early in a (perceived) market. It's a desperate "standard" muscled in by Amazon/Claude, similar to their overwrought "Smithy" IDL that basically nobody outside the Amazon SDK team chooses to use for API/Schema management. It will end up in that same niche in the long term, most likely... AWS/Amazon/Claude…

Except that in just six months there are literally thousands of MCP servers out there in use.

Will it be supplanted? Perhaps. But it's not going to die a natural death.

Re: MCP: An in-depth introduction

#49
MCP is practically useful, but the total lack of security in its "design" for me just underlines the type of YOLO-driven development and lack of quality that's being marketed as productivity improvement in software engineering too often these days.

Re: MCP: An in-depth introduction

#50
post #47

It's a half-baked, rushed out, speculative attempt to capture developer mindshare and establish an ecosystem/moat early in a (perceived) market. It's a desperate "standard" muscled in by Amazon/Claude, similar to their overwrought "Smithy" IDL that basically nobody outside the Amazon SDK team chooses to use for API/Schema management. It will end up in that same niche in the long term, most likely... AWS/Amazon/Claude…

MCP and Smithy aren’t comparable. Smithy is an internal tool used by almost every single team (it is used far, far more widely than just the SDK teams) at Amazon to define APIs and generate API servers/clients. It was released publicly because “why not?”, but I assure you that Amazon doesn’t care if you use it or not.
Post reply on HN