Hacker News Reader

Comment by jspahrsummers | Hacker News Reader

We definitely hope this will solve the NxM problem.

On tools specifically, we went back and forth about whether the other primitives of MCP ultimately just reduce to tool use, but ultimately concluded that separate concepts of "prompts" and "resources" are extremely useful to express different _intentions_ for server functionality. They all have a part to play!

View on HN

I think this where the real question is for me. When I read about MCP, the topmost question in my mind is "Why isn't this just tool calling?" I had difficulty finding an answer to this. Below, you have someone else asking "Why not just use GraphQL?" And so on.

It would probably be helpful for many of your readers if you had a focused document that addressed specifically that motivating question, together with illustrated examples. What does MCP provide, and what does it intend to solve, that a tool calling interface or RPC protocol can't?

You can find more information on some design questions like these in https://spec.modelcontextprotocol.io/specification, which is a much more "implementors" focused guide than the user documentation at https://modelcontextprotocol.io

Seems more accurate to state this reshapes the NxM problem rather than solving it.

Yeah even I don't understand how it exactly solves the NXM problem (which translates to having M different prompts for N different llms. corerct me if I'm wrong please)

N (LLM clients/vendors) x M (tools/tool suppliers).

The N×M problem may simply be moved rather than solved:

  - Instead of N×M direct integrations
  - We now have N MCP client implementations
  - M MCP server implementations

This feels similar to SOAP but might be more of a lower level protocol similar to HTTP itself. Hard to tell with the implementation examples being pretty subjective programs in python.

Reply on news.ycombinator.com