6 ms·

The thing that a lot of people miss with MCP is that it's the right fit for enterprise software. LLMs, being universal translators, are the ideal glue between m

The thing that a lot of people miss with MCP is that it's the right fit for enterprise software. LLMs, being universal translators, are the ideal glue between many disconnected systems that are extremely hard to connect without some fuzzy layer in between. And so that's why you see so much of the B2B SaaS world rolling out MCP servers, and internally at these companies, they're talking about how to re-jigger their APIs and restrictions for those APIs given different usage patterns. Yes, the protocol is not necessarily "enterprise ready" by various definitions, but as the author points out, this is not terribly important, and the history of standards shows us that even messy and "bad" things get widespread adoption because they hit the right notes at the right time for the right people.

Flemlo 1y ago
We have rest and openapi. That allows already for self discovery etc. Everyone who will offer mcp offers a good API anyway.
- hirsin 1y ago
  We don't need SDKs, they publish API docs. We don't need packages or functions, we can just write the code ourselves, every time it's needed. We don't need compilers, the computer understands assembly already. It's a mismatch of use - MCP isn't about telling the LLM about the APIs. It's also about encapsulating and simplifying them so the LLM isn't manually figuring them out every single time from scratch.
  - yeahbruh 1y ago
    [dead]
  - 9dev 1y ago
    OpenAPI specs provide everything the LLM needs to understand an API. And if it can be simplified for the LLM while retaining functionality, why not simplify the API altogether, instead of implementing yet another entry point into the application? Just so nobody has to sit down for longer than the duration of a TikTok and design their API properly?
- 8note 1y ago
  the value is being able to extend the internal website mcp, so it can grab the data i need. i can script across a billion systems that i would never go through the work of getting auth/setting up all the service calls and workflows for. the mcp doesnt need any new permissions, its just what ive got website access to
- eddythompson80 1y ago
  > That allows already for self discovery etc. The problem is usually not with listing the APIs. Almost all services have OpenAPI specs, and you can (often too) complain about lack of documentation. Orchestrating these APIs is the annoying "fuzzy" challenge. Imagine you have a VM service, and you provide a set of APIs. Someone comes asking "How do I create a copy of a VM we have in the US region to EU region but with half the CPU/RAM?" You might point to your OpenAPI spec and say you can: var s1 = takeSnapshot(vm1); var s2 = copySnapshot(s1, 'EU'); var vm2 = createVmFromSnapShopt(s2, sizeOverride). Ok... but is there a makeACopyOfVmWithHalfCPUAndHalfMemoryInEurope(vm1) API? I don't want to copy that code. In 3 months it'll break because `vm1` is of a type that can't be snapshoted and you'll tell me that I should check `vm1.snapshotable`, or that the new size is invalid in the new region because I should be calling `isSizeAvailable()` If this were an MCP, then it would either orchestrate these APIs "correctly" for me checking as corner cases as possible as (presumably from examples it saw on github). When it misses, it's "oh well, even AI couldn't get it. We can all blame AI everybody" As oppose to when a Human misses and someone is like "how amateurish is the implementation that you're not checking if the vm is `snapshotable` or not?
Animats 1y ago
It's a great money maker. Each data request involves a paid trip through an LLM. It's not like the endpoints negotiate a schema they can use to make cheap queries in future.
Karrot_Kream 1y ago
MCP is just RPC over a long-lived connection, most cases being a Websocket. IMO RPC is easier to setup because: 1. There's less bikeshedding for the authors about whether modifying a field in a user object should be a PUT or a POST replacing the original user object. I've spent a non-trivial amount of time bikeshedding over REST verbs. 2. LLMs don't need to understand the REST semantics of the API. It can just look at available RPC methods and make the RPC call it thinks will work. I think that's really it.
- HarHarVeryFunny 1y ago
  MPC is more than just a standard way to access remote functionality - it also provides discoverability so the client (LLM) can ask the server what functionality it offers, and understand how to use it.
  - phillipcarter 1y ago
    Right, our MCP server we’ve productionized supports this. It’s really fantastic when it works well. Lotta work to do to make it work well more often though!
  - Karrot_Kream 1y ago
    Sure but there are established alternatives for that also. The internet supports looking up DNS records (A, MX, SRV, TXT, etc), the web offers /.well-known as a place to store things like API endpoint specs, etc. The main difference with MCP is that the discoverability comes with the stream-oriented communication semantics.
    - anon7000 1y ago
      Well, you’re basically saying that different domains have different solutions to this problem. There isn’t a universally accepted way to do client discovery, and what exists are very specific to those domains.
      - achierius 1y ago
broost3r 1y ago
completely agree. huge enterprises are full of engineers who want to do amazing things from 9-5 and then sign off and forget about work until the next day. what kind of business wouldn't want to make sure they're getting the most out of their employees during business hours?
deleted 1y ago
[deleted]

Flemlo 1y ago

We have rest and openapi. That allows already for self discovery etc. Everyone who will offer mcp offers a good API anyway.

hirsin 1y ago
We don't need SDKs, they publish API docs. We don't need packages or functions, we can just write the code ourselves, every time it's needed. We don't need compilers, the computer understands assembly already. It's a mismatch of use - MCP isn't about telling the LLM about the APIs. It's also about encapsulating and simplifying them so the LLM isn't manually figuring them out every single time from scratch.
- yeahbruh 1y ago
  [dead]
- 9dev 1y ago
  OpenAPI specs provide everything the LLM needs to understand an API. And if it can be simplified for the LLM while retaining functionality, why not simplify the API altogether, instead of implementing yet another entry point into the application? Just so nobody has to sit down for longer than the duration of a TikTok and design their API properly?
8note 1y ago
the value is being able to extend the internal website mcp, so it can grab the data i need. i can script across a billion systems that i would never go through the work of getting auth/setting up all the service calls and workflows for. the mcp doesnt need any new permissions, its just what ive got website access to
eddythompson80 1y ago
> That allows already for self discovery etc. The problem is usually not with listing the APIs. Almost all services have OpenAPI specs, and you can (often too) complain about lack of documentation. Orchestrating these APIs is the annoying "fuzzy" challenge. Imagine you have a VM service, and you provide a set of APIs. Someone comes asking "How do I create a copy of a VM we have in the US region to EU region but with half the CPU/RAM?" You might point to your OpenAPI spec and say you can: var s1 = takeSnapshot(vm1); var s2 = copySnapshot(s1, 'EU'); var vm2 = createVmFromSnapShopt(s2, sizeOverride). Ok... but is there a makeACopyOfVmWithHalfCPUAndHalfMemoryInEurope(vm1) API? I don't want to copy that code. In 3 months it'll break because `vm1` is of a type that can't be snapshoted and you'll tell me that I should check `vm1.snapshotable`, or that the new size is invalid in the new region because I should be calling `isSizeAvailable()` If this were an MCP, then it would either orchestrate these APIs "correctly" for me checking as corner cases as possible as (presumably from examples it saw on github). When it misses, it's "oh well, even AI couldn't get it. We can all blame AI everybody" As oppose to when a Human misses and someone is like "how amateurish is the implementation that you're not checking if the vm is `snapshotable` or not?

Animats 1y ago

It's a great money maker. Each data request involves a paid trip through an LLM. It's not like the endpoints negotiate a schema they can use to make cheap queries in future.

Karrot_Kream 1y ago

MCP is just RPC over a long-lived connection, most cases being a Websocket. IMO RPC is easier to setup because: 1. There's less bikeshedding for the authors about whether modifying a field in a user object should be a PUT or a POST replacing the original user object. I've spent a non-trivial amount of time bikeshedding over REST verbs. 2. LLMs don't need to understand the REST semantics of the API. It can just look at available RPC methods and make the RPC call it thinks will work. I think that's really it.

HarHarVeryFunny 1y ago
MPC is more than just a standard way to access remote functionality - it also provides discoverability so the client (LLM) can ask the server what functionality it offers, and understand how to use it.
- phillipcarter 1y ago
  Right, our MCP server we’ve productionized supports this. It’s really fantastic when it works well. Lotta work to do to make it work well more often though!
- Karrot_Kream 1y ago
  Sure but there are established alternatives for that also. The internet supports looking up DNS records (A, MX, SRV, TXT, etc), the web offers /.well-known as a place to store things like API endpoint specs, etc. The main difference with MCP is that the discoverability comes with the stream-oriented communication semantics.
  - anon7000 1y ago
    Well, you’re basically saying that different domains have different solutions to this problem. There isn’t a universally accepted way to do client discovery, and what exists are very specific to those domains.
    - achierius 1y ago

broost3r 1y ago

completely agree. huge enterprises are full of engineers who want to do amazing things from 9-5 and then sign off and forget about work until the next day. what kind of business wouldn't want to make sure they're getting the most out of their employees during business hours?

deleted 1y ago

[deleted]