[brazukadev]

> MCPs are interpreters of those function calls.

No, tool calls are just one of many MCP parts. People thinking MCP = SOAP or DCOM or JSON-RPC or OpenAPI didn't stop 20 minutes to read and understand MCP.

Tool calls is 20% of MCP, at maximum. And a good amount of it is dynamically generating the tool list exposed to LLMs. But lots of people here think MCP === give the model 50 tools to choose from

[simonw]

"Tool calls is 20% of MCP, at maximum"

What else is there? I know about resources and prompts but I've seen almost no evidence of people actually using them, as far as I can tell tools are 90% of the usage of MCP, if not more.

[brazukadev]

It is funny most people discussing here does not understand MCP at all. Besides tools, MCP has resources, prompts, sampling, elicitation, roots and each one of them is useful when creating apps connected to LLMs. MCP is not only about MCP Servers, the host/client part is as important as the servers/tools. For example, nowadays most LLM clients are chatbots, but an MCP client could be a chess game or a project management app.

> I know about resources and prompts but I've seen almost no evidence of people actually using them

these are features that MCP clients should implement and unfortunately, most of them still don't. The same for elicitation and sampling. Prompts, for example, are mostly useful when you use sampling, then you can create an agent from an MCP server.

[tptacek]

What can I do with MCP that I can't do with the function calling interface in the OpenAI Responses API? Besides, obviously, grafting function calls into agents I didn't write; we all understand that's the value prop of MCP. But you're suggesting it's more than that. Fill in the blanks for us.

[didibus]

The MCP can expose a list of tools, but also a list of prompt templates, a list of resources, it can ask the client to run something through the LLM (called sampling), and it can provide rules for when to follow up with questions.

But you can do all that yourself if you're building your own agent and directly calling a model. But if you want to be able to provide behavior to any agent, that's where MCP comes in.

[brazukadev]

The LLM can only use MCP tools, but the Client you use the model can access resources, prompts, elicitation and sampling, which are tools to help with querying the model. So one MCP server that implements some or all these features can act as an agent for the LLM dispatching tasks IF the client is also an MCP host/client.

[ming030890]

But most of these can really be just a tool.

For example, A resource can be just a getter tool, like getFile.

[brazukadev]

MCP is a protocol, a proposal on standardizing how to do things so we can reuse tools. Whatever thing you want to do with MCP you can do without MCP, that is obvious. But when lots of people agree to write and consume using the same protocol there is a big productivity rise.

[didibus]

Resources could be a tool like list resources, but exposing them as resources means in the client you can show the user the list of resources, and the client can choose to include their descriptions in the context without the model choosing to do so for example.

[tptacek]

Right. My understanding of these APIs and model capabilities is imperfect, but at the level I interact with them at, there are only two things: prompts (more broadly: context chunks) and tool calls. I don't see how MCP could meaningfully expand that; it seems like anything I could do with MCP, I could do with context chunks and tool calls --- perhaps better, because I'd have finer-grained control of both security and of context management.