MCP usage is at an all-time peak - 17M daily (!) downloads of the official SDKs.
We're using MCP for virtually all our SaaS and infra providers (CRM, ATS, banking and accounting, Notion, Linear, all dev tools and hosting platforms) it's become a hard requirement in our buy bechmark. No MCP = NOGO
The advantages are:
- baked-in auth: no need to configure anything, it just works with our employees accounts
- one click install with Codex Plugins and Claude Connectors
I don't know anything about you or where you're based.
but in Main Street US - guess what the dentists are using ? guess what the auto-shop is using, the auto-dealer ?
mostly desktop software running on on-premise hardware, with some using cloud version but just being a small population overall. most of the software has no APIs, & no web version.
it's not sexy, nor fun. actual FDEs are needed for those industries, if anything A.I will unlock so much lost productivity.
MCP context bloat is a solved problem since at least February. Both OpenAI and Anthropic support Client-side MCP tool search, which makes MCP context loading as efficient as the Skills one (progressive discovery).
Code mode is great but not needed anymore in 95% of use-cases.
I can turn off auto invocation of a skill. It uses zero tokens when in this mode. I can still invoke it by calling it by name. How can I do that with MCP servers?
What you're describing is a harness implementation detail not something specific to the MCP protocol or even how skills behave. Both of those are effectively providing the same level of information to the harness. Harnesses have traditionally (and still generally do) exposed enabled MCP servers and their actions ahead-of-time in the system prompt directly instead of doing progressive disclosure.
> you can actually invoke an MCP App by name in both Codex and Claude using the @ handle
Even when it is disabled? The point is to have the skill or mcp app to not use ANY tokens until I call it by name. I can do that with a skill. Can I do that with an mcp app?
And ironically skills also need a double layer of progressive discovery because having too many skills available can also bloat the context even if only the short description is included. So instead of including hundreds of skills in the initial context a search tool is provided...
I don't see a reason to support MCPs by default. Pi is so extensive and has such a rich plugin ecosystem that MCP support is just one "pi install npm:pi-mcp-adapter" away.
Or you may choose another plugin that works differently.
That's the whole point of extensible systems like Pi or Emacs, you don't need to pray that maintainers will have the same vision as you, you just pick one of the many alternatives instead. Or ask pi to write one for you.
it's not a question of model size, it's a question of your model API engineering. The initial problem was that the all tools schemas needed to be loaded in the model's initial system prompt, and changing the tools list in the middle of a session was busting the cache.
Any model can now overcome that with a Tool Search tool implementation
- CLI tools don't have standardized auth, nor do they have granular tool permissions. MCP does
- CLI tools need to access your secrets in your .env. With MCP the model never sees the secrets and refresh tokens.
- CLI tools don't have auditing and telemetry. MCP provides all this for free.
- CLI tools imply full bash access, a nightmare in terms of security and very costly if you have to spin up a machine for every request for billions of users.
I'm not especially a fan of MCP but it also offers:
- Standardized input and output schemas for each tool
- Standardized annotations that indicate how potentially dangerous each tool can be (e.g. read-only, idempotent, publishes data visible to third parties)
None of this is true. The point of "just CLI" is that LLMs are infinitely more trained on working CLI tools. There doesn't need to be real CLI tools behind the harness, as long as the interface is CLI-like.
All of the main agent CLI's provides a demonstration that it is possible because they're all callable as a CLI. Several of them, like Codex, Kimi CLI, Pi, OpenCode are open source and so you could obviously strip out the MCP host and client from them and turn them into a CLI. Doing so in a way that keeps auth outside the agents sandbox is trickier and you might end up with a proxy which partly defeats the point but at least still keeps the composability of a CLI.
> CLI tools need to access your secrets in your .env
They can access whichever secret store you want. There are dozens of projects offering valid solutions nowadays for the local tool call space, and they’re equally useful in this scenario.
> CLI tools don’t have auditing and telemetry
They’ve had it for much longer than MCP.
> A nightmare in terms of security
We know how to secure shells. Git over SSH is a hardened, public shell that works all the way up to GitHub scale. You just offer a limited toolset. No escape, unless there’s a vulnerability, which is just as likely with MCP.
> Very costly
It’s a rounding error in comparison to token costs.
I was at the event, and was impressed by the attendance, all the leaders from the major european listed companies were there.
Also interesting to note the number of partners they invited. Going from Microsoft, Accenture and EY to startups like alpic.ai or lingo.dev . Seems like they are ramping up their M&A game too
Some might argue that Adwords got so successful because ads competed like search results, on bid AND relevance, not just bid.
If your ads inventory is big enough, ads can actually be a better answer to your intent than organic content, because the companies behind the ads have a much stronger incentive to satisfy your need.
If AdWords or search consider both relevance and the fee collected, the end user will never be shown the most useful results consistently. If the goal was usefulness they would only pick results by relevance and take no fee at all, or take a flat fee that isn't based on a bidding system.
