tbh, that companies tried to make something proprietary of this concept is probably why its adoption has been weak and why we have "MCP vs CLI/Skills/etc" debates in the first place. In contrast, CLI tools only require a general a bash shell (potentially in a sandbox environment), which is very standardised.
If I recall correctly, the ‘official’ Python one is a fork of FastMCP v1 (which then removed the attribution, arguably in violation of the original software’s license)
There is a whole history with this, and i think its not appropriate or fair to malign the mcp python-sdk.
My read of what happened is that the author spiked an an initial the implementation of 'fastmcp' on Nov 30 2025, 5 days later, the author relicensed it to MIT, and donated it to the python sdk (10 days after anthropic announced MCP):
It was incorporated on Dec 21 2024, and hardened through the efforts of one of the python-sdk maintainers.
The author seemingly abandoned the github project shortly after donating it to the python-sdk and marked it as unmaintained, and it remained so for several months (there are roughly zero commits between jan-april):
Many contributors to the python sdk continued to iterate on the mcp server implementation using the name fastmcp ( since it had been donated to the project ) resulting in growing interest:
Then around April 2025, the author likely noticing the growing interest and stickyness of the name, decided to write a new version and start using the name fastmcp again.
This resulted in a lot of confusion by users, which persists to this day. I only looked into this last year, because i was one of those users who was suddenly confused regarding the provenance of what i was actually using vs what i thought i was using; and as i looked into it i was suddenly seeing lots of questionable reddit comments pop up in subreddits i was reading, all evangelizing fastmcp 2.0 and using language that was contributing to the confusion.
The author's interest in monetizing the fastmcp github repo is understandable, and he and others have clearly put alot of effort into iterating in his SaaS onramp, but the confusion arises simply because the author wanted to capitalize on the success of mcp and on the popularity of the fastmcp name, the initial growth and popularity of which was primarily driven by the effort and support of contributors to the mcp python sdk .
K8s gives you orchestration of Docker containers. I don’t think it handles the container boundary any more than Docker does.
I don’t think it should be assumed to give network isolation, unless you’re also using extensions and something like Cilium for that purpose. I don’t think it’s the right primitive for agent sandboxes, or other kinds of agent infra.
(Obviously, you could still run a custom runtime inside k8s pods, or something like GCP’s k8s gVisor magic.)
Apple can do those things because they control the hardware device, which has physical distribution, and they lock down the ecosystem. There is no third party app store, and you can't get the Photos app to save to Google Drive.
With Claude Code, just export an env variable or use a MITM proxy + some middleware to forward requests to OpenAI instead. It's impossible to have lock in. Also, coding agent CLIs are a commodity.
Change is fraught with chaos. I don't think exuberant trends are indicators of whether we'll still care about secure and high quality software in the long term. My bet is that we will.
tbh, that companies tried to make something proprietary of this concept is probably why its adoption has been weak and why we have "MCP vs CLI/Skills/etc" debates in the first place. In contrast, CLI tools only require a general a bash shell (potentially in a sandbox environment), which is very standardised.
reply