one legitimate explanation I have heard is that when a Tesla gets in an accident, even with minor damage, they have to replace the Battery, because they are not able to accurately assess the damage to battery and the risk of not changing it. This balloons the insurance cost.
This seems like a real public policy problem; a custodian in a Ford Escort should not incur an extra $20k in repair liability after a fender bender simply because the other car happened to be a wealthy lawyer's Tesla. At some point the owner of the glass car has to take responsibility for the risk of having it on the road.
It is indeed quite baffline why MCP is taking off, but facts are facts. I would love to be enlightened how MCP is better than an OpenAPI Spec of an existing Server.
My theory is that a lot of the buzz around MCP is actually buzz around the fact that LLM tool usage works pretty well now.
OpenAI plugins flopped back in 2023 because the LLMs at the time weren't reliable enough for tool usage to be anything more than interesting-but-flawed.
I'm still having relatively disastrous results compared to just sending pre curated context (i.e. calling tools deterministically upfront) to the model.
Doesn't cover all the use cases, but for information retrieval stuff, the difference is pretty light and day. Not to mention the deterministic context management approach is quite a bit cheaper in terms of tokens.
I thinks a lot is timing and also that it's a pretty low bar to write your first mcp server:
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("Basic Math Server")
@mcp.tool()
def multiply(a: int, b: int) -> int:
return a * b
mcp.run()
If you have a large MCP server with many tools the amount of text sent to the LLM can be significant too. I've found that Claude works great with an OpenAPI spec if you provide it with a way to look up details for individual paths and a custom message that explains the basics. For instance https://github.com/runekaagaard/mcp-redmine
The difficult part is figuring out what kind of abstractions we need MCP servers / clients to support. The transport layer is really not important, so until that is settled, just use the Python / TypeScript SDK.
How exactly those messages get transported is not really relevant for implementing an mcp server, and easy to switch, as long as there is some standard.
You’re ignoring the power of network effects - “shitty but widely adopted” makes “better but just starting adoption harder” to grow. Think about how long it takes to create a new HTTP standard - we’ve had 3 HTTP standards in the past 30 years, the first 19 of which so no major changes. HTTP/2 kind of saw no adoption in practice and HTTP/3 is still a mixed bag. In fact, most of the servers pretend HTTP/1 with layers in front converting the protocols.
Underestimate network effects and ossification at your own peril.
I mean isn't this the point of a lot of, if not most successful software? Abstracting away the complexity making it feel easy, where most users of the software have no clue what kind of technical debt they are adopting?
Just think of something like microsoft word/excel for most of its existence. Seems easy to the end user, but attempting to move away from it was complex, the format had binary objects that were hard to unwind, and interactions that were huge security risks.
yeah, but it doesn’t need to be that way. It can be simple and makes it easier adoptable, why over engineering and reinventing the wheel of at least 2 decades experience and better practices.
This is one of the few places I think it's obvious why MCP provides value - an OpenAPI document is static and does no lifting for the LLM, forcing the LLM to handle all of the call construction and correctness on its own. MCP servers reduce LLM load by providing abstractions over concepts, with basically the same benefits we get by not having to write assembly by hand.
In a literal sense it's easier, safer, faster, etc for an LLM to remember "use server Foo to do X" than "I read a document that talks about calling api z with token q to get data b, and I can combine three or four api calls using this http library to...."
I'm not saying MCP is perfect, but it's better than OpenAPI for LLMs for a few reasons.
* MCP tools can be described simply and without a lot of text. OpenAPI specs are often huge. This is important because the more context you provide an LLM the more expensive it is to run, and the larger model you need to use to be effective. If you provide a lot of tools then using OpenAPI specs could take up way too much for context, while the same tools for MCP will use much less.
* LLMs aren't actually making the calls, it's the engine driving it. What happens when an LLM wants to make a call is it responds directly with a block of text that the engine catches and uses to run the command. This allows LLMs to work like they're used to: figuring out text to output. This has a lot of benefits: less tokens to output than a big JSON blob is going to be cheaper.
* OpenAPI specs are static, but MCP allows for more dynamic tool usage. This can mean that different clients can get different specs, or that tools can be added after the client has connected (possibly in response to something the client sent). OpenAPI specs aren't nearly that flexible.
This isn't to say there aren't problems. I think the transport layer can use some work, as OP sent, but if you play around in their repo you can see websocket examples so I wouldn't be surprised if that was coming. Also the idea that "interns" are the ones making the libraries is an absolute joke, as the FastMCP implementation (which was turned into the official spec) is pretty solid. The mixture of hyperbole with some reasonable points really ruins this article.
If you look at the actual raw output of tools/list call you may find it surprisingly similar to the OpenAPI spec for the same interface. In fact they are trivially convertible to each other.
Personally I find OpenAPI spec being more practical since it includes not just endpoints with params, but also outputs and authentication.
Know all that from my own experience plugging dozens of APIs to both MCP/Claude and ChatGPT.
> OpenAPI specs are static, but MCP allows for more dynamic tool usage.
This is repeated everywhere, but I don’t get it. OpenAPI specs are served from an HTTP endpoint, there’s nothing stopping you from serving a dynamically rendered spec depending on the client or the rest of the world?
What does it mean that "different clients can get different specs"? Different in what dimension? I could imagine this makes creating repeatable and reliable workflows problematic.
Using MCP you can send "notifications" to the server, and the server can send back notifications including the availability of new tools.
So this isn't the same as saying "this user agent gets X, this gets Y". It's more like "this client requested access to X set of tools, so we sent back a notification with the list of those additional tools".
This is why I do think websockets make more sense in a lot of ways here, as there's a lot more two way communication here than you'd expect in a typically API. This communication also is very session based, which is another thing that doesn't make sense for most OpenAPI specs which assume a more REST-like stateless setup.
USD Stablecoins could be driving real demand for USD, no?
"The total transaction volume for USD-pegged stablecoins in 2024 was approximately $27.6 trillion, based on industry reports from CEX.IO and other sources."
No. Stablecoins only exist because fiat <-> crypto trading is a massive pain. Nobody wants to own stablecoins, they want easier transactions. And if the USD becomes less popular, people will switch to, for example, EUR stablecoins - there's nothing special about the dollar here.
On top of that, transaction volume is meaningless. Those $27.6T could be $27.6T held in escrow being traded once, or $1 held in escrow being traded 26.6 trillion times. You can't derive USD demand from transaction volume.
RE: Nobody wants to own stablecoins, they want easier transactions.
Agree but that does not mean anything. Stablecoins seem to be solving a problem, and there is not evidence of any traction by any currency other than USD.
So this phenomenon definitely runs counter to the conventional intellectual wisdom that USD is in decline.
Tax evasion could certainly be a use case until govt's sort out the implications. But the lasting use case I think is - fast and cheap transfer of money, anywhere.
Only if the other major world currencies take active (and successful) steps against stablecoins being backed by them.
If they don't, stablecoins would presumably make it even easier to convert holdings into stablecoins backed by another currency (as there is no new account to be opened etc.) as soon as the sentiment on a given world currency shifts.
According to your argument and the article of this post, there should already be prominent stablecoins backed by other currencies. Yet there is not such thing AFAIK. Reason is simple. USD is the common denominator for people the world over. Almost everyone know what a dollar is, and that is reflected in the dominance of USDT and USDC. And since this is a relatively recent phenomenon, it goes counter to the narrative of the decline of the US Dollar.
> USD is the common denominator for people the world over.
Yes, currently. This article is about a hypothetical in which this stops being the case. My argument is that stablecoins would not stop such a trend, and could possibly accelerate it.
I understand the hypothetical trend being mentioned, and I would even agree with it in absence of stablecoins. See, today, if China & Russia want to trade, they may trade in Ruble or Yuan. Ruble or Yuan don't have to be universally accepted for them to trade. But if I am transacting in stablecoin, I don't want to use anything that is not universally accepted from the get-go. Otherwise, I might as well use Ruble or Yuan. So, even if in theory the stablecoin could be backed by any currency, I am not going to use just any stablecoin, only the one most widely accepted.
In other words, I think Stablecoin is winner-take-all, and USD has already won.
> I am not going to use just any stablecoin, only the one most widely accepted.
But why?
Due to the existence of decentralized exchanges, all stablecoins are effectively equally widely accepted. Some blockchains even make it fully transparent by handling foreign exchange in the background for every payment where it's required, and for the ones that don't, most common wallets provide a "swap" feature directly in their UI.
Given that, why would people not hold the one that preserves their purchasing power best and that they have most trust in?
I am sure this is worth every dime, but my workflow is so used to Cursor now (cursor rules, model choice, tab complete, to be specific), that I can't be bothered to try this out.
If you're using Cursor with Claude it's gonna be pretty much the same thing. Personally I use Claude Code because I hate the Cursor interface but if you like it I don't think you're missing much.
On a practical level though, this would be the last thing I would use for log collection. I understand that when there is a spike, something has to be dropped. What should this something be?
I don't see the point of being "fair" about what is dropped.
I would use fairness as a last resort, after trying other things:
Drop lower priority logs: If your log messages have levels (debug, info, warning, error), prioritize higher-severity events, discarding the verbose/debug ones first.
Contextual grouping: Treat a sequence of logs as parts of an activity. For a successful activity, maybe record only the start and end events (or key state changes) and leave out repetitive in-between logs.
Aggregation and summarization: Instead of storing every log line during a spike, aggregate similar or redundant messages into a summarized entry. This not only reduces volume but also highlights trends.
The article addressed this. In fact, you don't typically want to throw away all of the low priority logs ... you just want to limit them to a budget. And you want to limit the total number of log lines collected to a super budget.
You should drop or consolidate some entries if you can, but then the important entries that remain can still be too many and require random culling because anything is better than choking.
Fair reservoir sampling can be made unfair in controlled ways (e.g. by increasing the probability of retaining an entry if its content is particularly interesting); it competes with less principled biased random (or less than random) selection algorithms as a technique of last resort.
Also, there is an MCP Server to bypass Xcode from Cursor: https://github.com/cameroncooke/XcodeBuildMCP
reply