8 ms·

I would bet that MCP is going to die. The main reason is that it adds another layer (and human) that can, and probably will, get out of sync with the real-worl

• rixed 4mo ago
  Soon, if you want the performance of your AI clients to improve (wrt. token count and understanding) you will start to customize the output of the MCP server for more synthetic data, different data types, more permissive inputs, etc. And since most your clients will be AI that might be your API that fall behind, and MCP that will be maintained. That's at least my experience with my current project: the traditional json, coding oriented API feels out of place, I maintain it out of habit. The real API is the MCP server, which is not designed like a traditional API would; understandability of the output for an LLM prevails instead of searchng for exhaustiveness, orthogonality etc.
  • pmontra 4mo ago
    Interesting points. A couple of questions. Do you have a frontend (React, Vue, anything) and if you do, does it interact with the server using the MCP server or the JSON API? Are all your clients AIs or do you expect that most of them will be AIs? The reason I'm asking those questions is that a customer of mine has a service with a JSON API, a Vue frontend and a score of customers using that JSON API. We know that the newest ones are using bots to code their clients (and they are using them wrong, by the mistakes they do.) I don't see a near future in which all those third party apps become LLMs that would benefit from a MCP server and we retire the API.
    • rixed 4mo ago
      I do have a front-end, but it interacts with the server with a specific, private API. It's using a more compact data encoding than JSON optimised for streaming the data that's needed for the front-end. But yes I agree with your point: for a simpler app with a more traditional web UI it's likely the API used by the front-end would largely overlap with the user-oriented API. Then indeed the REST API has to be maintained for as long as humans continue to use the front-end.
• mjmas 4mo ago
  But then there is the other side that companies are adding MCP servers to stuff that has never had a public API.
  • IggleSniggle 4mo ago
    They are building them because they can ask an AI to spin it up. They could have asked it to spin up the public API just as easily. The MCP choice is a fashion choice vs an openapi spec with similar documentation (or any number of other human+machine readable tooling). It might accidentally win or accidentally lose just because of the timing / network effects.
• js4ever 4mo ago
  Totally agree, MCP is the WAP equivalent of mobile internet access.
  • zwischenzug 4mo ago
    I'm old enough to get this reference! Spent years writing WAP... it was really great at the time.
    • rwoerz 4mo ago
      Those were the days of the dotcom era when finding the next restaurant with your Nokia + WAP was THE killer use case.
    • jmkni 4mo ago
      It blew my mind as a kid I was maybe 10/11 when the Nokia 3330 came out, and being able to use the internet while not in front of a computer just felt like magic
  • brookst 4mo ago
    Have you used MCP, at the protocol level? WAP was dumb and failed because it oversimplified the web, and phones evolved to be real computers. MCP is more sophisticated than typical APIs. It adds organization, policy, and code vs data (prompts) partitioning. IMO it’s more likely that non-LLM apps will start using MCP than it is for MCP to go the way of WAP.
• Groxx 4mo ago
  I have some hope that this'll all lead to a revival of semantic web / microformats / etc. Why write an API when you can just add some markup to your existing API, which already looks like stuff that it was trained on, and won't fall out of sync (because you use it too)?
  • iamacyborg 4mo ago
    I definitely see it going that way from a marketing perspective if you want what you send/produce to be machine readable and actually used in intermediated surfaces like email and web search.
  • troupo 4mo ago
    > I have some hope that this'll all lead to a revival of semantic web / microformats / etc Why would it? Do you see any agents or models use that? No, instead vibe coders at Anthropic vibe-designed a bespoke protocol that sidesteps and ignores the last 60 years of API development and integrations.
    • PaulHoule 4mo ago
      That was exactly my thought when I saw MCP: like we know so much about creating protocols but get a bunch of people together with no experience and that’s what you get. Reminds me a lot of Microsoft’s WS-disaster of the early 2000s except the latter was thought through a little better. To be fair a while back I did design an API for a general purpose model trainer which was absolutely atrocious for a few reasons, my own ignorance was a factor but the problem of accommodating everything from “model that can be trained in 30 seconds on a small machine” to “model that takes 30 days of training on a cluster” problematized it. It would have made so much more sense to build a standard for documenting ordinary API endpoints and CLIs.
      • flaburgan 4mo ago
        You mean a swagger?
• winrid 4mo ago
  I usually just generate the MCP server spec from existing openapi/swagger spec, maybe with a filter to omit certain endpoints and so on.
• Someone 4mo ago
  > AI should not be using a protocol or set of instructions that is different from what humans have access to (know and use). Should it? I think it can be very useful to constrain what your AI can do (e.g. read files but don’t delete them). MCP is a way to do that.
  • codebje 4mo ago
    Authorisation is a way to do that, too.
    • Someone 4mo ago
      Yes, but you often do not have much control over that. For example try giving a local LLM read access to specific folders in your email account
      • otabdeveloper4 4mo ago
        Theoretically you should be creating a "read email" CLI tool and letting agents interact with it in a chroot sandbox. LLMs are much more proficient with bash and --help than they are with bespoke API protocols. Treat LLMs like you would a junior programmer - keep things as generic and obvious as you can.
      • skydhash 4mo ago
        Easy. What a cron script (that runs as root) that populate a maildir that the agent (restricted user) has access to. The. you restrict network access to the internet, and have it send you its findings by mail (local mail server).
        • Someone 4mo ago
          That’s not an example of “Authorisation is a way to do that”, and, I think, not easier than writing a MCP server.
• _fizz_buzz_ 4mo ago
  [dead]
• sofixa 4mo ago
  > So the current situation is basically that I used Claude to write an MCP server on top of our API. And then I need to occasionally tell it update it match the public doc. > And my reaction is: really? It is not like our API docs are not public. Claude Code created our MCP server with zero instructions beyond what is publicly available. I just told it to read the docs from the net. My reaction to this is.. really? Presumably your API and API docs have a release process. Hopefully an automated one. Why isn't the "hey Claude, update the MCP server" step a part of it?
  • oldsecondhand 4mo ago
    That wouldn't solve the core issue: if Claude makes a mistake during the MCP generaration, it would poison further agentic use. It's adding another failure point to the process for no gain.
    • sofixa 4mo ago
      No, because as everything which is a part of a release process, you'd have tests.
• hnlmorg 4mo ago
  That’s only true for the frontier. The moment you start looking at enterprise consumers of AI you’ll see slow monoliths that make decisions by committee and those committees often don’t even understand the tech they’re passing ruling on. And you’ll also often see CISO-offices that are managed by checklists and yet more committees. Asking for MCP access is generally easier than asking for an API for several reasons: 1. MCP supports OAuth, so your access conform with numerous CIS (et al) compliance checklists (short lived secrets, MFA, user-specific credentials, user access managed by centralised directory services and thus can have business rules applied, etc) 2. MCP is something a business can make a cooperate decision on. And then you can refer to that decision each time you need an access to new service. Whereas API access isn’t. In some cases APIs are governed by LLDs, and then you have an extra layer of “fun” having to update documentation to describe, in detail, the technical specifications too. 3. MCP defines the interaction better. If you need to request access to an API then the inevitable question from the committee is “where is this code running from?” and so on and so forth. Whereas saying “MCP access for AI to assist the project team with development” is a lot easier conversation to have. In short: Enterprises are a very different beast to your average business.
  • PaulHoule 4mo ago
    Explains a lot.
  • tlogan 4mo ago
    Here is my vision: the future of AI is about truly understanding the real world. The world around us. Not everything in the real world will expose an MCP server so AI can interact with it. Eventually, AI will need to move beyond MCP and interact with the real world the same way humans do: by observing, interpreting, reasoning, and taking action in messy, imperfect environments. MCP tries to organize our messy word to make interaction part with the world easier in the near term, and it will help accelerate very early progress. But ultimately, MCP is a temporary bridge. Not the final destination. I give it max 3 to 6 years and it will just die.
    • hnlmorg 4mo ago
      The problem isn’t that AI cannot do this already. Because it can. The problem is cost. There are people complaining that MCP costs too many tokens. Parsing the same UIs that humans do would just be insane. And to be honest, I don’t think that’s the right goal of AI anyway. Most competent engineers prefer APIs to human interfaces. So why should machine-to-machine use that too?
• personjerry 4mo ago
  > temporary workaround I've heard this one before (Maybe it'll be the first time that a temporary workaround stays around longer than expected then)
• holoduke 4mo ago
  Funny thing is that Claude knows the api of Atlassian better than the mcp they provide. Mcp is limited it doesn't have all api calls described.
  • 2muchcoffeeman 4mo ago
    Is this not just a tooling problem?
    • Geezus_42 4mo ago
      As someone who supports Atlassian products; Atlassian is a tooling problem.
    • PaulHoule 4mo ago
      Yeah, having two tools when you only need one is a problem. Like one is always going to be full phat and the other will ride the back of the bus.
  • losvedir 4mo ago
    I haven't found this to be the case. I tried to make `acli` work, with CLAUDE.md fine saving the things Claude learns about how to use the API (eg which custom variables to include and so on), but in the end found the MCP to work better. I think I had trouble getting the CLI to update a certain custom field, which the MCP was able to do. Not to mention, I don't think `acli` even works with Confluence?
• ekianjo 4mo ago
  You can build a MCP server in minutes these days to connect to a REST API. The friction is close to zero.
• debarshri 4mo ago
  Totally agree with you.
• mrgaro 4mo ago
  MCP has a great advantage over agent using cli: MCP is much easier to secure so that it's hardwired that the agent can only call the pre-configured MCP server. We run our agents so that they don't have access to public internet, so they could not run any cli commands. It's all either built-in agent tools, or 3rd party mcp servers. The agents never have access to any credentials, which makes them much more safe to use than a claude code running in yolo mode with fetching random cli binaries from the web.
  • twoodfin 4mo ago
    I think that’s exactly right: MCP provides a capability security model for agents.
  • zingar 4mo ago
    Can you not just install/ restrict the available CLIs in the same way you do with MCPs? Or what else am I missing about why MCP is more secure than a CLI?
    • rubslopes 4mo ago
      MCP allows you to easily separate API requests from their access tokens, so that the LLM only has access to the requests part. Giving an LLM CLI access removes all boundaries, anything goes. EDIT: to add an example: I have a personal claw agent that I only use CLI, I don't care. But I'm also building an agent inside a company product, and there we use MCP all the way.
      • octoberfranklin 4mo ago
        You can easily do this with simple Unix `chmod x-rw` on a wrapper that makes HTTP requests, adding the access token as it does.
        • noplacelikehome 4mo ago
          The point is that you still need to expose a shell or a wrapper around exec to launch those commands. That is t appropriate when I want to lock the model down to working entirely from a sandboxed environment and expose some basic tools which are not “entire posix user space”. MCP servers are not dead, they’re just overused in contexts they don’t really make sense in.
• PunchyHamster 4mo ago
  > The main reason is that it adds another layer (and human) that can, and probably will, get out of sync with the real-world implementation, whether that implementation is an API, web, or a CLI. The menial task of updating the interfaces when the code changes is something AI should be really good at, so it's essentially little to no actual programmer time waste > So the current situation is basically that I used Claude to write an MCP server on top of our API. And then I need to occasionally tell it update it match the public doc. > And my reaction is: really? It is not like our API docs are not public. Claude Code created our MCP server with zero instructions beyond what is publicly available. I just told it to read the docs from the net. Updating MCP by AI is one time effort. Having AI re-create what MCP would do for every piece of code that uses a service is massively wasted effort in comparison It's not question of "model limitation" but of cost effectiveness.
• brookst 4mo ago
  MCP is a higher layer than your existing API. It’s like saying APIs are dead because you can just use HTTP. They’re not the same thing, though of course you can hand-roll the higher layer in the lower one. It’s just more work, less standard, less valuable. I don’t think models will ever prefer a low level API to a decorated index of API features and how to use them, same way developers will never prefer a list of HTTP endpoints and bespoke headers + query strings + POST bodies over a structured API.
  • IggleSniggle 4mo ago
    Right; isn't this already captured by an openapi spec with RBACs? Plus the benefit that your ai agent can keep using all the pre-AI tools that already interface with those specs. What is MCP bringing that an openapi spec doesn't?
    • ok_dad 4mo ago
      You can build an MCP client really really easy today with libraries and it integrates with inference calls very well. If you want to give a cloud agent access to another api, you need to bills a connector or give it shell access or some sort of sandbox with tools to access that stuff. That’s fine, but how do you then give it auth access? How do you ensure security boundaries? MCP builds those in and the shape (prompts, resources, tools, etc) are good for agentic work. It’s like asking why we needed browsers when we had BBSes; they serve a different but similar purpose and are build on different abstraction levels.
• Gomotono 4mo ago
  What we really should have is an aligned discovery protocol and a generic globally used sdk which handles negotiation. You have a client, the client uses the SDK, talks to endpoint x. Endpoint x tells it very efficient that they are now talking protobuf and rpc over quick or http15 and thats it. Why don't we have this? Right because of people. Its always people problem. MCP is now here, it might stay.
• hashmap 4mo ago
  MCP will definitely not die. It works, it makes things easier for non-technical people, and is extremely inefficient. You can build an entire industry around that.
• slashdave 4mo ago
  > get out of sync with the real-world implementation You are missing the point. When the API moves, the agent has to adapt. Are you rewriting its skills? MCP provides the instructions. When the API moves, MCP adapts. You need to do nothing. So, basically the exact opposite of what you are claiming
• random3 4mo ago
  +1 - MCP is a transient effect of current models’ limitations. But the “when” is relevant
• sunnybeetroot 4mo ago
  If you don’t know how to keep your openapi spec up to date then yes you’ll struggle with keeping an MCP up to date. At the end of the day, keeping APIs in sync with SDKs, documentation, MCPs is a solved problem through automation. It’s not hard.