Comment by anon84873628
2 months ago
Ah, so the "I haven't needed it so it must be useless" argument.
There is huge value in having vendors standardize and simplifying their APIs instead of having agent users fix each one individually.
2 months ago
Ah, so the "I haven't needed it so it must be useless" argument.
There is huge value in having vendors standardize and simplifying their APIs instead of having agent users fix each one individually.
Possible legit alternative:
Have the agents write code to use APIs? Code based tool calling has literally become a first party way to do tool calling.
We have a bunch of code accessible endpoints and tools with years of authentication handling etc built in.
https://www.anthropic.com/engineering/advanced-tool-use#:~:t...
Feels like this obviates the need for MCP if this is becoming common.
That solution will not work as well when the interfaces have not been standardized in a way that makes it so easy to import them into a script as a library.
Coding against every subtly different REST API is as annoying with agents as it is for humans. And it is good to force vendors to define which parts of the interface are actually important and clean them up. Or provide higher level tasks. Why would we ask every client to repeat that work?
There are also plenty of environments where having agents dynamically write and execute scripts is neither prudent nor efficient. Local MCP servers strike a governance balance in that scenario, and remote ones eliminate the need entirely.
It's not particularly hard for current models to wire up a http client based on the docs and every major company has well documented APIs for how to do so either with their SDKs or curl.
I don't know that I really agree its as annoying for agents since they don't have the concept of annoyance and can trundle along infinitely fine.
While I appreciate the standardization I've often felt MCPs are a poor solution to a real problem that coincided with a need for good marketing and a desire to own mindspace here from Anthropic.
I've written a lot of agents now and when I've used MCP it has only made them more complicated for not an apparent benefit.
MCP's value lies in the social alignment of people agreeing to use it, it's technical merits seem dubious to me while its community merits seem high.
I can accept the latter and use it because of that while thinking there were other paths we probably should have chosen that make better use of 35 years of existing standards.
I don’t agree on the first part. What sort of llm can’t understand a swagger spec? Why do you think it can’t understand this but can understand mcp?
On runtime problems yes maybe we need standardisation.
7 replies →
I thought the whole point of AI was that we wouldn't have to do these things anymore. If we're replacing engineering practice with different yet still basically the same engineering practice, then AI doesn't buy us much. If AI lives up to their marketing hype, then we shouldn't need MCP.
Hm. Well maybe you are mistaken and that dichotomy is false.
Then what's the point of AI?
1 reply →
> There is huge value in having vendors standardize and simplifying their APIs
Yes, and it's called OpenAPI.
My product is "API first". Every UI task has an underlying endpoint which is defined in the OpenAPI spec so we can generate multiple language SDK. The documentation for each endpoint and request/response property is decent enough. Higher level patterns are described elsewhere though.
90% of the endpoints are useless to an AI agent, and within the most important ones only 70% of the fields are relevant. The whole spec would consume a huge fraction of context tokens.
So at a minimum I need a new manifest with a highly pared down index.
I'm not claiming that we're not in this classic XKCD situation, but the point of the cartoon is that that just how it be... https://xkcd.com/927/
Maybe OpenAPI will be able to subsume MCP and those manifests can be generated from the same spec just like the SDKs themselves.