5 ms·

MCP was a really shitty attempt at building a plugin framework that was vague enough to lure people into and then allow other companies to build plugin platform

MCP was a really shitty attempt at building a plugin framework that was vague enough to lure people into and then allow other companies to build plugin platforms to take care of the MCP non-sense. "What is MCP, what does it bring to the table? Who knows. What does it do? The LLM stuff! Pay us $10 a month thanks!" LLM's have function / tool calling built into them. No major models have any direct knowledge of MCP. Not only do you not need MCP, but you should actively avoid using it. Stick with tried and proven API standards that are actually observable and secure and let your models/agents directly interact with those API endpoints.

cyanydeez 11mo ago
probably easier to just tell people: You want MCP? Add a "description" field to your rest API that describes how to call it. That's all it's doing. Just plain ole context pollution. World could be better served by continuing to build out the APIs that exist.
- tacticus 11mo ago
  > Add a "description" field to your rest API that describes how to call it. Isn't that swagger\grpc etc?
- jes5199 11mo ago
  yesss, and OpenAI tried this first when they were going to do a “GPT store”. But REST APIs tend to be complicated because they’re supporting apps. MCP, when it works, is very simple functions in practice it seems like command line tools work better than either of those approaches
  - CuriouslyC 11mo ago
    Command line tools are my preference just because they're also very useful to humans. I think providing agents function libraries and letting them compose in a repl works about as well but is higher friction due env management.
- mycall 11mo ago
  Also, keep your api small as all the tool call, DTOs and user messages (e.g. workflow recipes) add up to big context windows and accuracy confusion, at least in the latest models. I hope that gets resolved.
- pests 11mo ago
  Sometimes the actions you want to perform does not map cleanly into one or two API calls, or would be too messy to assume correct parsing. Maybe your UI is fine POSTing to /users and PUTing to /groups or whatever but giving the LLM a direct CreateUserAndAddToGroup action simplifies the task and keeps context cleaner.
  - cstrahan 11mo ago
    This is very true. But why stop there? Imagine a future where we have an evolved version of MCP -- call it MCP++. In MCP++, instead of having to implement a finite list of specialized variants like CreateUserAndAddToGroup, imagine MCP++ has a way to to feed the desired logic (create user, then add that user to $GROUP) directly to the endpoint. So there would be something like a POST /exec endpoint. And then the /exec endpoint can run the code (maybe it's WASM for something)... Wait a minute! We already have this. It's called programming. You could have the LLM write code, so that any pipelining (like your example), aggregation, filtering, or other transformation happens in that code, and the LLM only needs to spend the output tokens to write the code, and the only input tokens consumed is the final result. I definitely am not the first person to suggest this: https://www.anthropic.com/engineering/code-execution-with-mcp https://www.anthropic.com/engineering/code-execution-with-mc... https://blog.cloudflare.com/code-mode/ https://blog.cloudflare.com/code-mode/ ... but I can say that, as soon as I read about MCP, my first thought was "why?" MCP is wasteful. If you want LLMs to interact with your software/service, write a library, let the scrapers scrape that code so that future LLM revisions have the library "baked into it" (so you no longer need to spam the context with MCP tool descriptions), and let the LLM write code, which it already "knows" how to do. What if your library is too new, or has a revision, though? That's already a solved problem -- you do what you'd do in any other case where you want the LLM to write code for you: point it at the docs / codebase.
- EagnaIonat 11mo ago
  > Just plain ole context pollution. It would normally be a second context window to figure out what tool / agent to run. My only quibble with MCP is in the usual AI bandwagon people are implementing for FOMO than business value. My experience is likely anecdotal though.
- blitzar 11mo ago
  > World could be better served by continuing to build out the APIs that exist. before LLM's and MCP the world was depreciating or locking down APIs
voidhorse 11mo ago
Yeah there's no there there when it comes to MCP. It's crazy to me that the world bought into the idea when the "spec" literally boils down to "have your server give the LLM some json". Just illustrates how powerful it is to attach names to things, especially in a hypestorm in which everyone is already frothing at the mouth and reason is hard to come by. Give people some word they can utter to help them sound like they're on the "bleeding edge" and they'll buy into it even if it's totally pointless.
- tptacek 11mo ago
  "Have your XYZ give the LLM some JSON" is pretty close to how all tool calling works with or without MCP.
  - mycall 11mo ago
    Markdown is for output too.
  - what-the-grump 11mo ago
    What next you are going to tell me rest and async are implemented in code?! And not just willed into existence by the compiler!
- anon84873628 11mo ago
  It gave everyone a reason to think about the usability of the interfaces they were exposing. Many endpoints have tons of fields irrelevant to 95% of external users. Now those are gone. Or they implemented higher level abstractions for the actual tasks instead of making developers compose a bunch of little pieces. And it has a standardized manifest. Execs, PMs, and customers having that word to utter as part of the AI hype train created the opportunity for that industry-wide cleanup to happen. Calling it pointless is very naive. It's actually kind of extraordinary.
  - voidhorse 11mo ago
    Thanks for offering another perspective on it. I can buy into this partially. At the same time, I'm skeptical that this won't just become yet another dead protocol once the hype abates, at which point all of the perceived benefits were for naught.
paulddraper 11mo ago
> No major models have any direct knowledge of MCP. Claude and ChatGPT both support MCP, as does the OpenAI Agents SDK. (If you mean the LLM itself, it is "known" at least as much as any other protocol. For whatever that means.)
- whoknowsidont 11mo ago
  >it is "known" at least as much as any other protocol. No. It is not. Please understand what the LLM's are doing. Claude nor ChatGPT nor any major model knows what MCP is. They know how to function & tool call. They have zero trained data on MCP. That is a factual statement, not an opinion.
  - choilive 11mo ago
    That is an easily falsifiable statement. If I ask ChatGPT or Claude what MCP is Model Context Protocol comes up, and furthermore it can clearly explain what MCP does. That seems unlikely to be a coincidental hallucination.
    - whoknowsidont 11mo ago
      Training data =/= web search Both ChatGPT and Claude will perform web searches when you ask them a question, which the fact that you got this confused is ironically topical. But you're still misunderstanding the principle point because at some point these models will undoubtedly have access to that data and be trained on it. But they didn't need to be, because LLM function & tool calling is already trained on these models and MCP does not augment this functionality in any way.
      - sumeno 11mo ago
        Claude gives me a lengthy explanation of MCP with web search disabled
        whoknowsidont 11mo ago
didibus 11mo ago
> MCP was a really shitty attempt at building a plugin framework Can you go more in depth? The protocol is relatively simple, what about it you feel is "shitty" as a plugin framework?
- paulddraper 11mo ago
  The hate for MCP here is absurd. It's JSON-RPC, with some descriptors. And some comments about OAuth 2. The value is in the consensus. You can make a tool that agents can connect to with no apriori knowledge.
  - whoknowsidont 11mo ago
    >It's JSON-RPC, with some descriptors. That's not even true. It defines the lifecycle of tool calling. JSON-RPC with some descriptors would have been fine and amazing.
    - frumplestlatz 11mo ago
      I’m struggling to understand where you’re coming from. Your hate for MCP seems grossly outsized relative to what it actually is.
    - paulddraper 11mo ago
      This comment is unhinged. https://modelcontextprotocol.info/docs/concepts/transports/ https://modelcontextprotocol.info/docs/concepts/transports/
      - whoknowsidont 11mo ago
        You linked to one part of the spec and just wanted to ignore everything else? That's fine, but then you wouldn't be obeying the standard and wouldn't be an "MCP." So, are you agreeing with me? Respectfully I think I've engaged with you before and you just seem generally confused about nuanced concepts.
jcelerier 11mo ago
> LLM's have function / tool calling built into them. No major models have any direct knowledge of MCP. but the major user interfaces for operating LLMs do and that's what matters > Not only do you not need MCP, but you should actively avoid using it. > Stick with tried and proven API standards that are actually observable and secure and let your models/agents directly interact with those API endpoints. so what's the proven and standard API I can use to interact with ableton live? blender? unity3d? photoshop?
- whoknowsidont 11mo ago
  [flagged]
  - nilslice 11mo ago
    What do all of the links below have in common? Do you know of another way you can control all of those applications via LLMs? Computer use? https://github.com/ahujasid/ableton-mcp https://github.com/ahujasid/ableton-mcp https://github.com/ahujasid/blender-mcp https://github.com/ahujasid/blender-mcp https://github.com/CoplayDev/unity-mcp https://github.com/CoplayDev/unity-mcp https://github.com/mikechambers/adb-mcp https://github.com/mikechambers/adb-mcp
    - growt 11mo ago
      The mcp part is not essential for the actual controlling of the applications. You could “rip out” the mcp functionality and replace it with something else. The only reason why the authors chose mcp is most likely that it was the first and therefore most common plugin interface for llm tools.
      - Zetaphor 11mo ago
        Isn't that the point they are making? MCP is useful because everyone is using it, not because it has a technical advantage over rolling your own solution. It won mindshare because of marketing and a large company pushing it. I've actually taken to both approaches recently, using the mcp-client package to give me an interface to a wide array of prebuilt tools in my non-LLM application. I could have written or sourced 10 different connectors, or I can write one client interface and any tool I plug in shares the same standard interface as all the others.
timClicks 11mo ago
MCP is an example of "worse is better". Everyone knows that it's not very good, but it gets the job done.
block_dagger 11mo ago
Perhaps you haven't used many MCP server, but those that I have used (GitHub, Atlassian, Glean, BuildKite, Figma, Google Workspace, etc) work very well. They teach an LLM how to do exactly what you're saying - "use the API standards...your models/agents directly interact with those API endpoints." Most MCP severs don't sit in between the LLM and the API endpoints, they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would. I find it works quite well and seems far better than manually maintaining rules or pointing at docs and installing CLI tools (like "gh" for GitHub) or using curl to interact with APIs from a terminal within a chat session.
- whoknowsidont 11mo ago
  >, they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would. No. MCP does not do this. Function & tool calling is built into the LLM. MCP is not augmenting this ability in ANY way.
- cstrahan 11mo ago
  > but those that I have used (GitHub, [...]) > Most MCP severs don't sit in between the LLM and the API endpoints [...] Your first example certainly isn't an example of that: https://github.com/github/github-mcp-server https://github.com/github/github-mcp-server I suppose someone could try to abuse MCP by stuffing information about REST API endpoints into a the prompt/descriptions in a small MCP "skeleton" service, but I don't know of any. Can you provide examples? > they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would. I suspect you might have some deep misunderstandings about MCP.
pjmlp 11mo ago
Fully agree, however we need to reach our KPIs and OKRs regarding AI adoption.

cyanydeez 11mo ago

probably easier to just tell people: You want MCP? Add a "description" field to your rest API that describes how to call it. That's all it's doing. Just plain ole context pollution. World could be better served by continuing to build out the APIs that exist.

tacticus 11mo ago
> Add a "description" field to your rest API that describes how to call it. Isn't that swagger\grpc etc?
jes5199 11mo ago
yesss, and OpenAI tried this first when they were going to do a “GPT store”. But REST APIs tend to be complicated because they’re supporting apps. MCP, when it works, is very simple functions in practice it seems like command line tools work better than either of those approaches
- CuriouslyC 11mo ago
  Command line tools are my preference just because they're also very useful to humans. I think providing agents function libraries and letting them compose in a repl works about as well but is higher friction due env management.
mycall 11mo ago
Also, keep your api small as all the tool call, DTOs and user messages (e.g. workflow recipes) add up to big context windows and accuracy confusion, at least in the latest models. I hope that gets resolved.
pests 11mo ago
Sometimes the actions you want to perform does not map cleanly into one or two API calls, or would be too messy to assume correct parsing. Maybe your UI is fine POSTing to /users and PUTing to /groups or whatever but giving the LLM a direct CreateUserAndAddToGroup action simplifies the task and keeps context cleaner.
- cstrahan 11mo ago
  This is very true. But why stop there? Imagine a future where we have an evolved version of MCP -- call it MCP++. In MCP++, instead of having to implement a finite list of specialized variants like CreateUserAndAddToGroup, imagine MCP++ has a way to to feed the desired logic (create user, then add that user to $GROUP) directly to the endpoint. So there would be something like a POST /exec endpoint. And then the /exec endpoint can run the code (maybe it's WASM for something)... Wait a minute! We already have this. It's called programming. You could have the LLM write code, so that any pipelining (like your example), aggregation, filtering, or other transformation happens in that code, and the LLM only needs to spend the output tokens to write the code, and the only input tokens consumed is the final result. I definitely am not the first person to suggest this: https://www.anthropic.com/engineering/code-execution-with-mcp https://www.anthropic.com/engineering/code-execution-with-mc... https://blog.cloudflare.com/code-mode/ https://blog.cloudflare.com/code-mode/ ... but I can say that, as soon as I read about MCP, my first thought was "why?" MCP is wasteful. If you want LLMs to interact with your software/service, write a library, let the scrapers scrape that code so that future LLM revisions have the library "baked into it" (so you no longer need to spam the context with MCP tool descriptions), and let the LLM write code, which it already "knows" how to do. What if your library is too new, or has a revision, though? That's already a solved problem -- you do what you'd do in any other case where you want the LLM to write code for you: point it at the docs / codebase.
EagnaIonat 11mo ago
> Just plain ole context pollution. It would normally be a second context window to figure out what tool / agent to run. My only quibble with MCP is in the usual AI bandwagon people are implementing for FOMO than business value. My experience is likely anecdotal though.
blitzar 11mo ago
> World could be better served by continuing to build out the APIs that exist. before LLM's and MCP the world was depreciating or locking down APIs

voidhorse 11mo ago

Yeah there's no there there when it comes to MCP. It's crazy to me that the world bought into the idea when the "spec" literally boils down to "have your server give the LLM some json". Just illustrates how powerful it is to attach names to things, especially in a hypestorm in which everyone is already frothing at the mouth and reason is hard to come by. Give people some word they can utter to help them sound like they're on the "bleeding edge" and they'll buy into it even if it's totally pointless.

tptacek 11mo ago
"Have your XYZ give the LLM some JSON" is pretty close to how all tool calling works with or without MCP.
- mycall 11mo ago
  Markdown is for output too.
- what-the-grump 11mo ago
  What next you are going to tell me rest and async are implemented in code?! And not just willed into existence by the compiler!
anon84873628 11mo ago
It gave everyone a reason to think about the usability of the interfaces they were exposing. Many endpoints have tons of fields irrelevant to 95% of external users. Now those are gone. Or they implemented higher level abstractions for the actual tasks instead of making developers compose a bunch of little pieces. And it has a standardized manifest. Execs, PMs, and customers having that word to utter as part of the AI hype train created the opportunity for that industry-wide cleanup to happen. Calling it pointless is very naive. It's actually kind of extraordinary.
- voidhorse 11mo ago
  Thanks for offering another perspective on it. I can buy into this partially. At the same time, I'm skeptical that this won't just become yet another dead protocol once the hype abates, at which point all of the perceived benefits were for naught.

paulddraper 11mo ago

> No major models have any direct knowledge of MCP. Claude and ChatGPT both support MCP, as does the OpenAI Agents SDK. (If you mean the LLM itself, it is "known" at least as much as any other protocol. For whatever that means.)

whoknowsidont 11mo ago
>it is "known" at least as much as any other protocol. No. It is not. Please understand what the LLM's are doing. Claude nor ChatGPT nor any major model knows what MCP is. They know how to function & tool call. They have zero trained data on MCP. That is a factual statement, not an opinion.
- choilive 11mo ago
  That is an easily falsifiable statement. If I ask ChatGPT or Claude what MCP is Model Context Protocol comes up, and furthermore it can clearly explain what MCP does. That seems unlikely to be a coincidental hallucination.
  - whoknowsidont 11mo ago
    Training data =/= web search Both ChatGPT and Claude will perform web searches when you ask them a question, which the fact that you got this confused is ironically topical. But you're still misunderstanding the principle point because at some point these models will undoubtedly have access to that data and be trained on it. But they didn't need to be, because LLM function & tool calling is already trained on these models and MCP does not augment this functionality in any way.
    - sumeno 11mo ago
      Claude gives me a lengthy explanation of MCP with web search disabled
      - whoknowsidont 11mo ago

didibus 11mo ago

> MCP was a really shitty attempt at building a plugin framework Can you go more in depth? The protocol is relatively simple, what about it you feel is "shitty" as a plugin framework?

paulddraper 11mo ago
The hate for MCP here is absurd. It's JSON-RPC, with some descriptors. And some comments about OAuth 2. The value is in the consensus. You can make a tool that agents can connect to with no apriori knowledge.
- whoknowsidont 11mo ago
  >It's JSON-RPC, with some descriptors. That's not even true. It defines the lifecycle of tool calling. JSON-RPC with some descriptors would have been fine and amazing.
  - frumplestlatz 11mo ago
    I’m struggling to understand where you’re coming from. Your hate for MCP seems grossly outsized relative to what it actually is.
  - paulddraper 11mo ago
    This comment is unhinged. https://modelcontextprotocol.info/docs/concepts/transports/ https://modelcontextprotocol.info/docs/concepts/transports/
    - whoknowsidont 11mo ago
      You linked to one part of the spec and just wanted to ignore everything else? That's fine, but then you wouldn't be obeying the standard and wouldn't be an "MCP." So, are you agreeing with me? Respectfully I think I've engaged with you before and you just seem generally confused about nuanced concepts.

jcelerier 11mo ago

> LLM's have function / tool calling built into them. No major models have any direct knowledge of MCP. but the major user interfaces for operating LLMs do and that's what matters > Not only do you not need MCP, but you should actively avoid using it. > Stick with tried and proven API standards that are actually observable and secure and let your models/agents directly interact with those API endpoints. so what's the proven and standard API I can use to interact with ableton live? blender? unity3d? photoshop?

whoknowsidont 11mo ago
[flagged]
- nilslice 11mo ago
  What do all of the links below have in common? Do you know of another way you can control all of those applications via LLMs? Computer use? https://github.com/ahujasid/ableton-mcp https://github.com/ahujasid/ableton-mcp https://github.com/ahujasid/blender-mcp https://github.com/ahujasid/blender-mcp https://github.com/CoplayDev/unity-mcp https://github.com/CoplayDev/unity-mcp https://github.com/mikechambers/adb-mcp https://github.com/mikechambers/adb-mcp
  - growt 11mo ago
    The mcp part is not essential for the actual controlling of the applications. You could “rip out” the mcp functionality and replace it with something else. The only reason why the authors chose mcp is most likely that it was the first and therefore most common plugin interface for llm tools.
    - Zetaphor 11mo ago
      Isn't that the point they are making? MCP is useful because everyone is using it, not because it has a technical advantage over rolling your own solution. It won mindshare because of marketing and a large company pushing it. I've actually taken to both approaches recently, using the mcp-client package to give me an interface to a wide array of prebuilt tools in my non-LLM application. I could have written or sourced 10 different connectors, or I can write one client interface and any tool I plug in shares the same standard interface as all the others.

timClicks 11mo ago

MCP is an example of "worse is better". Everyone knows that it's not very good, but it gets the job done.

block_dagger 11mo ago

Perhaps you haven't used many MCP server, but those that I have used (GitHub, Atlassian, Glean, BuildKite, Figma, Google Workspace, etc) work very well. They teach an LLM how to do exactly what you're saying - "use the API standards...your models/agents directly interact with those API endpoints." Most MCP severs don't sit in between the LLM and the API endpoints, they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would. I find it works quite well and seems far better than manually maintaining rules or pointing at docs and installing CLI tools (like "gh" for GitHub) or using curl to interact with APIs from a terminal within a chat session.

whoknowsidont 11mo ago
>, they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would. No. MCP does not do this. Function & tool calling is built into the LLM. MCP is not augmenting this ability in ANY way.
cstrahan 11mo ago
> but those that I have used (GitHub, [...]) > Most MCP severs don't sit in between the LLM and the API endpoints [...] Your first example certainly isn't an example of that: https://github.com/github/github-mcp-server https://github.com/github/github-mcp-server I suppose someone could try to abuse MCP by stuffing information about REST API endpoints into a the prompt/descriptions in a small MCP "skeleton" service, but I don't know of any. Can you provide examples? > they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would. I suspect you might have some deep misunderstandings about MCP.

pjmlp 11mo ago

Fully agree, however we need to reach our KPIs and OKRs regarding AI adoption.