4 ms·

I'm also fascinated by this. People are scurrying to release MCP servers, and there's been a flurry of them put out - but it feels like we've skipped straight

I'm also fascinated by this. People are scurrying to release MCP servers, and there's been a flurry of them put out - but it feels like we've skipped straight to the advanced tooling, on top of a stack that might not have found it's footing (yet). I understand MCP, the problem it solves, and why it seems a good idea ... but outside of toy applications, are they proving to be useful?

noodletheworld 2y ago
> I understand MCP, the problem it solves, and why it seems a good idea I don't. Can you ELI5 why it's a good idea for me? I see what people are doing (1), and I see what the intent is (2), but no one seems to have an explanation of why it helps. The original MCP documentation has some vague hand waving about (3) about having prompts that would help ... with, something. ...but I don't see it in practice. ? Is this why people are asking "does this actually work?" ...because, its obviously not any better than the 'tool use' API that everyone was already using. It can't be. It doesn't do anything differently. I would bet that it actual makes agents less capable when you overload their context with unrelated tools that aren't relevant. Right? How can it possibly help? It sounds a lot like it rests on the assumption that adding tools is a zero-cost zero-impact +capability action only, but that can't be true. (1) - https://github.com/punkpeye/awesome-mcp-servers https://github.com/punkpeye/awesome-mcp-servers (2) - https://modelcontextprotocol.io/quickstart/server#what%E2%80%99s-happening-under-the-hood https://modelcontextprotocol.io/quickstart/server#what%E2%80... (3) - https://modelcontextprotocol.io/docs/concepts/prompts https://modelcontextprotocol.io/docs/concepts/prompts
- pocketarc 2y ago
  > ...because, its obviously not any better than the 'tool use' API that everyone was already using. It can't be. It doesn't do anything differently. Instead of you writing tool use code (which requires you to know how to write code, and to put in the effort), you spin up a server that provides that tool use code for the LLM. As an example, you could hook up an "email" MCP that connects to your email provider and provides a "get_unread" tool and a "send_email" tool, and then go nuts having a chat with your LLM saying "hey let's work through our unread emails, bring up the first and then come up with a draft response for it, for me to review before sending". Hook it up with the "linear" MCP, and tell the LLM to also raise tickets with all the relevant details in your project management tool. Of course you could write those tools yourself, and control all of the prompting, etc, but the point of MCP is so you don't have to write anything. That's the ELI5, I think. "pre-built tools for the tool use API".
- fragmede 2y ago
  > ...because, its obviously not any better than the 'tool use' API that everyone was already using I don't think that's true, but even if it's not, there's such a thing as being too early to market, and that a very similar product just launched later is a success when the original isn't. There are some differences; it's like how FTP is different from HTTP but also it isn't.
mogili 2y ago
Yes. I am using a mcp that provides Claude desktop file editing and terminal tools to work like Claude code but using my pro subscription instead of pay per use expensive API

noodletheworld 2y ago

> I understand MCP, the problem it solves, and why it seems a good idea I don't. Can you ELI5 why it's a good idea for me? I see what people are doing (1), and I see what the intent is (2), but no one seems to have an explanation of why it helps. The original MCP documentation has some vague hand waving about (3) about having prompts that would help ... with, something. ...but I don't see it in practice. ? Is this why people are asking "does this actually work?" ...because, its obviously not any better than the 'tool use' API that everyone was already using. It can't be. It doesn't do anything differently. I would bet that it actual makes agents less capable when you overload their context with unrelated tools that aren't relevant. Right? How can it possibly help? It sounds a lot like it rests on the assumption that adding tools is a zero-cost zero-impact +capability action only, but that can't be true. (1) - https://github.com/punkpeye/awesome-mcp-servers https://github.com/punkpeye/awesome-mcp-servers (2) - https://modelcontextprotocol.io/quickstart/server#what%E2%80%99s-happening-under-the-hood https://modelcontextprotocol.io/quickstart/server#what%E2%80... (3) - https://modelcontextprotocol.io/docs/concepts/prompts https://modelcontextprotocol.io/docs/concepts/prompts

pocketarc 2y ago
> ...because, its obviously not any better than the 'tool use' API that everyone was already using. It can't be. It doesn't do anything differently. Instead of you writing tool use code (which requires you to know how to write code, and to put in the effort), you spin up a server that provides that tool use code for the LLM. As an example, you could hook up an "email" MCP that connects to your email provider and provides a "get_unread" tool and a "send_email" tool, and then go nuts having a chat with your LLM saying "hey let's work through our unread emails, bring up the first and then come up with a draft response for it, for me to review before sending". Hook it up with the "linear" MCP, and tell the LLM to also raise tickets with all the relevant details in your project management tool. Of course you could write those tools yourself, and control all of the prompting, etc, but the point of MCP is so you don't have to write anything. That's the ELI5, I think. "pre-built tools for the tool use API".
fragmede 2y ago
> ...because, its obviously not any better than the 'tool use' API that everyone was already using I don't think that's true, but even if it's not, there's such a thing as being too early to market, and that a very similar product just launched later is a success when the original isn't. There are some differences; it's like how FTP is different from HTTP but also it isn't.

mogili 2y ago

Yes. I am using a mcp that provides Claude desktop file editing and terminal tools to work like Claude code but using my pro subscription instead of pay per use expensive API