3. with harness-level authz (the ability to allow / deny specific methods in the harness)
The only part that's actually new is #3, but it seems like it should be fairly easy to provide similar support for REST APIs. There might already be a Pi extension that allows you to allow / deny particular method / path patterns for particular sites. Regardless, there's always service-level authz with service accounts, at least for the more sophisticated APIs.
So ya, I don't see why we need a whole new set of standards and protocols just to have harness-level fine-grained API permissions. We could have just done it all with REST.
Honestly MCP is geared mainly for the non-technical folks who don't understand a thing about REST or OpenAPI (otherwise, of course folks can just ask models to search/parse/code/parse and get things done -- don't need to ask for an MCP endpoint at all). Models also do a lot better with tool calls than asking them to string together instrospection, web-search, curl, etc. (that's a lot of tokens) rather than having the endpoint expose a single URL that the model can take, auth, understand, and use.
I maintain https://endara.ai and you can very quickly introduce a ton of capabilities for Claude/Cursor/ChatGPT by configuring all the stuff you use in a single place (and slicing them with profiles if needed).
The user experience for a rest api and for mcp can be the same. For MCP, you have to give the mcp server url. For REST, you could provide a url to the openapi spec. The open API spec has everything you'd need - oauth url + all the endpoints and params.
Most chat products will just have a directory of connectors anyways - so for non technical folks they won't even here the term MCP or REST, they'll just "Install the Gmail plugin".
Yep. There's already a well-established system of `.well-known` URL paths to support things like API spec discover, auth discovery, etc. Why re-invent those wheels?
Because while an agent can indeed call a REST API directly using some other tool ( probably curl) what LLMs are good at is calling tools, and all MCP is doing is turning an API into a tool and standardizing authorization, which if you go the API route can be a nightmare as auth is not even mentioned in OpenAPI specs, usually, so the agent has to figure out how to do auth, and it will necessarily have access to your token and maybe even credentials, so it can easily leak it to attackers your agent happens to visit by just asking for it. I can’t believe anyone who has tried to give agents access to APIs in a sane manner hasn’t concluded that something on the lines of MCP is absolutely necessary.
I guarantee you any LLM will be perfectly capable of navigating HTTP auth [1] which has been around since 1999.
You could use `curl`, or you could bake an HTTP client tool into the agent harness which operates at a more abstract level. The agent would just have a tool that looks a lot like the Fetch API [2] and the harness could simply be configured to inject credentials using the various well-established patterns that have long existed, allow / deny certain methods, etc. The thing is, everything you can do with MCP could also simply be done with REST, so neither is inherently better than the other, I just don't like the proliferation of needless standards.
You can’t be seriously proposing HTTP auth (you probably mean basic auth??) as a solution!? Just hand your raw credentials to the LLM, what could go wrong?
Letting the harness inject the credentials implies not exposing them to the LLM.
Besides, the current state of MCP authentication almost always involves just hard coding secrets in .claude/settings.json so it's not like that's doing a great job keeping the creds away from the LLM anyway. All I'm saying is that MCP auth offers no advantage.
OpenAPI 3.0 has auth. You can turn OpenAPI specs into tool calls just as well, without giving your agents access to call curl and without leaking credentials.
The problem is often that OpenAPI schemas are often incomplete, since they used to be useful to humans even in an incomplete state.
MCP basically requires you to do the equivalent work of getting your OpenAPI schema complete. It’s just much easier to sell to your managers.
Kind of--I'm saying that RESTful APIs are just an abstract vocabulary to describe state transfer operations, whereas MCP describes a concrete set of such operations. REST sits on top of the HTTP protocol layer, MCP sits on top of REST (if we accept how the meaning of REST has been butchered, but you know what I mean.)
This is easy to see when you think in terms of a client: It is pretty much impossible to build an opinionated UI for any kind of RESTful API, while creating one for an MCP server is fairly self-explanatory: MCP servers offer a mandatory and complete runtime introspection endpoint (you can retrieve a listing of available tools/resources/prompts etc. along with their parameter and return type schemas). So that means clients have a way to exhaustively describe everything an MCP server is able to do with a vocabulary that carries over exactly to other servers - a tool is a tool everywhere.
See my point #2. There are already standards to describe APIs.
This is easy to see when you think in terms of a developer. The natural way to adapt an existing REST API into an MCP server while keeping the two synchronized is to simply write a basic translation tool that takes your OpenAPI spec and turns it into an MCP manifest, mapping each HTTP endpoint to an MCP method, and copying over all the request / response type signatures and descriptions for everything. Then, all of the sudden, it hits you: there is no need for this translation layer.
I think OpenAPI does all you mentioned in your comment too. Maybe MCP is more strict, in the sense that it requires natural-language descriptions, which are optional in OpenAPI, but I don’t see the distinction.
There are multiple products that turn OpenAPI schemas into front-ends nowadays.
When I say REST, I basically mean HTTP/JSON. I know. Shame on me.
But there's a pretty large body of RFCs that define what makes a good REST API. For instance POST should create things, PUT should re-define them, PATCH should incrementally update them, GET must be side-effect-free, etc. And there's a ton of standard HTTP headers. Pair it with OpenAPI and the whole thing is self-documenting. You can achieve the same effect with gRPC + reflection, or GraphQL + reflection, and there's plenty of mature tooling and interoperability for each system.
By comparison, MCP actually has relatively few conventions. LLMs are very familiar with REST and OpenAPI already. Just use that.
REST has issues if you limit yourself to think of the “resources” as your domain entities.
If you have a long running search, the resource is the search. Create a search. Fetch search results. Delete the search when you’re done.
Similarly, if you have a sufficiently complex command, the resource is the command itself. Maybe it requires async work, and you can later fetch the command results.
Anecdotally, this seems to be too big of a leap in mental model for beginners, mostly because all of the REST learning path does is teach you how to use it in CRUD domains.
The read-only QUERY method can send much bigger requests than GET.
For delayed answers, MCP offers no improvement, because remote MCP servers use an HTTP transport anyway, and local ones don't involve middleware you can't control. Besides, that's well-trodden ground. SSE, trailers, gRPC streaming, websockets, simple polling, etc. We don't need another protocol.
It's kinda hard to have a truly informed conversation about the scam industry since it's so secretive, but many of the scammers in Myanmar are actually incredibly big businesses that basically enslave people who otherwise wouldn't scam anybody. In those cases, the people who are actually making the choices are incredibly wealthy.
> Those 10 days certainly exist, in both calendar systems.
Not in the standard Gregorian calendar. Those dates only exist in the proleptic Gregorian calendar. The standard Gregorian calendar explicitly skips them. That's because you can't feasibly go back and change all the Julian dates that had been physically written down for centuries. That's why it's called the Gregorian "shift".
The one introduced by Gregory. I'm not sure if countries that reformed later cared enough to use a different name, but the Gregorian calendar is pretty well defined.
Most applications don't have to worry about it, but platforms do. The SQL standard requires accurate date representation for years 0000-9999. I was surprised to learn about the Gregorian shift while testing our database system. I also learned about "war time" in WW2 and the "battle of the clocks" in colonial India. A lot of history came out of debugging those tests.
For sure. I was thinking more of "normal" applications, as opposed to things like SQL databases. It looks like the SQL standard explicitly calls for the use of the Gregorian calendar for dates, so I think that answers the previous question of "Who else uses the proleptic Gregorian calendar other than programmers of datetime libraries?"
"normal applications", no. But there are more platforms besides databases, e.g. programming languages. Any platform that works with dates will have to deal with these weird quirks. And application that works with dates probably would not, although there's always leap seconds...
Considering it only diverges from the standard Gregorian for dates more than 400 years ago, it's not super relevant. Most people don't think about it. But it made a lot of sense to do the shift at the time. All recorded dates up to that point had been physically written down, so it would have been infeasible to migrate those all to the proleptic. If computers had been around, maybe things would have been different.
Fun fact: Greece was still using the old Julian calendar as of 1928, so it's entirely possible that you'll see dates on relatively recent Greek documents that are up to 14 days off from the calendar the rest of the world was using. Civil timekeeping is just a mess.
> The court also held that the third factor favored fair use as to the purchased library copies converted from print to digital because the purpose of the copying was to keep the books in its library but with more favorable storage and searchability properties. This purpose required copying, there was no surplus copying and the source copy was destroyed. With respect to the pirated copies, however, the court held that because “Anthropic lacked any entitlement to hold those copies” and retained them “even after deciding it would not make further copies from them for training,” this third factor weighed against Anthropic for that particular use.
Aaron Schwartz was re-publishing the journals, which is the core concern or copyright and indeed where the word "copyright" comes from. Anthropic could get in a lot more trouble if their models are caught reproducing copyrighted work from their training set wholesale.
I think the Aaron Schwartz case is incredibly vexing because he was obviously acting out of a sense of altruism without personal self-interest. I don't think he deserved the book getting thrown at him like that. But the whole copyright system, which people seem to think is simultaneously good and bad, kinda rests on not allowing those kinds of violations
I've linked this several times, but LLMs are capable of reproducing entire books. Researchers were able to extract books nearly verbatim: https://arxiv.org/abs/2601.02671
They're attitude is more "this is fair use" which, according to all precedent, is probably true in most cases (unless the models actually start regurgitating huge parts of the Copyrighted material without a license).
Of course, distillation is also fair use under Copyright law.
Copyright was never meant to be a moral framework. It was always a practical framework designed to incentivize publishing that would ultimately pass into the public domain. Everybody seems to want to attribute some sort of moral weight to it though; the idea that people are naturally entitled to certain rights over things they've published. That idea would be totally alien to the people who designed the Copyright system in the first place.
"This is fair use" is just their public defense, but obviously they have never given a thought about this when hoarding data, as shown by the modest 1.5B fine of Anthropic, which they can now write off as a normal business cost.
I am completely willing to accept that "this is fair use" for any company that publishes the LLM weights, i.e. the result of processing all the copyrighted work, because they have performed a public service with this.
But when the so-called "fair use" was a method to transform public data into private data that they guard and claim that any access to it would now be IP theft and which they use to obtain huge profits, that does not look like fair use to me.
Was it really "designed to incentivize" anything? Or was it introduced to protect a powerful, influential business model? Looking at how laws are passed now, I know which explanation I find more congruent.
> [the United States Congress shall have power] To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries.
Also, I'd be careful at taking the reasoning of political documents at face value. Many items in the Constitution are post-hoc, Lockeian/liberal justifications for a social order that was in fact largely copied over wholesale from English parliamentary monarchy, with surprisingly few tweaks.
I think we have to consider the origin of it as a concept, which predates the United States entirely and is quite a lot more damning. From the same Wikipedia page you linked:
"The first copyright privilege in England bears date 1518 and was issued to Richard Pynson, King's Printer, the successor to William Caxton. The privilege gives a monopoly for the term of two years. The date is 15 years later than that of the first privilege issued in France. Early copyright privileges were called "monopolies," particularly during the reign of Queen Elizabeth, who frequently gave grants of monopolies in articles of common use, such as salt, leather, coal, soap, cards, beer, and wine. The practice was continued until the Statute of Monopolies was enacted in 1623, ending most monopolies, with certain exceptions, such as patents; after 1623, grants of letters patent to publishers became common...
As the "menace" of printing spread, governments established centralized control mechanisms,[19] and in 1557 the English Crown thought to stem the flow of seditious and heretical books by chartering the Stationers' Company. The right to print was limited to the members of that guild, and thirty years later the Star Chamber was chartered to curtail the "greate enormities and abuses" of "dyvers contentyous and disorderlye persons professinge the arte or mystere of pryntinge or selling of books." The right to print was restricted to two universities and to the 21 existing printers in the city of London, which had 53 printing presses. The French crown also repressed printing, and printer Etienne Dolet was burned at the stake in 1546. As the English took control of type founding in 1637, printers fled to the Netherlands. Confrontation with authority made printers radical and rebellious, and 800 authors, printers and book dealers were incarcerated in the Bastille before it was stormed in 1789.[19]"
So, to summarize: the principle of copyright came from monarchic economic protectionism and censorship. I will freely admit I didn't know this piece of history before this thread - I simply predicted it, correctly, from first principles.
Certainly in Europe there is view that author has moral rights over their work. And the view has affected how international copyright framework operates.
> Copyright was never meant to be a moral framework. It was always a practical framework designed to incentivize publishing that would ultimately pass into the public domain.
A practical framework that model training breaks. Why publish a resource if it'll just get ingested by a model, and the model maker will get your customers/users instead of you? You're already seeing that with Google, which uses AI Overviews to cannibalize more and more traffic that would have once passed to a website.
What a soulless take.
Morality is determined socially and does not exist in a vacuum. Stealing the livlihood of artists and creators so that you can offer competing products is not an act of neutrality. It is a deeply immoral act akin to theft.
Stealing does not magically become "distillation" once you've stolen from enough people that it becomes difficult to match provenance.
The law may see this as no issue, as the law cares more about protecting power, but that does not mean it isnt immoral.
If most books never recoup the advance in sales, then isn't this a better deal for most authors? It sounds like a guaranteed floor which might be very low but is nonetheless higher than the alternative
1. a REST-like API
2. with a spec (OpenAPI, introspection, etc.)
3. with harness-level authz (the ability to allow / deny specific methods in the harness)
The only part that's actually new is #3, but it seems like it should be fairly easy to provide similar support for REST APIs. There might already be a Pi extension that allows you to allow / deny particular method / path patterns for particular sites. Regardless, there's always service-level authz with service accounts, at least for the more sophisticated APIs.
So ya, I don't see why we need a whole new set of standards and protocols just to have harness-level fine-grained API permissions. We could have just done it all with REST.
reply