TL;DR: MCP adoption is hitting a real backlash among individual builders. A 75-test comparison found CLI-based agents run 10-32x cheaper on tokens than MCP-wrapped ones, with better reliability. Before you wrap your AI agent as an MCP tool (or build one from scratch), run it through a four-question framework: does the capability need persistent state, human approval, a browser session, or scheduled execution? If yes to any, MCP’s stateless tool-call model will fight you the whole way.
The Question Every Builder Hits Right Now
If you’re building on top of Claude Code, Codex, or any MCP-native coding agent, you’ve probably had this argument with yourself: should your product expose itself as an MCP tool the agent can call directly, or should it stay a standalone product the user visits separately?
The pressure to pick MCP is real. Claude Code alone has north of 46% developer market share, and MCP has gone from a 2024 Anthropic spec to default plumbing across OpenAI, Google, GitHub, and thousands of smaller tools. If your product isn’t callable from inside the agent workflow builders already live in, it can feel like you’re asking them to leave the house to use you.
We’ve been having this exact argument internally for weeks now, seriously enough that it’s sitting as an open, unresolved bet in our own strategy tracker instead of a settled decision. Honest state of it: we don’t have a clean answer yet, and neither does most of the industry.
The Backlash Nobody Mentions in the MCP Pitch Decks
Here’s what complicates the “just become an MCP tool” instinct: 2026 has also produced a documented backlash against MCP from the exact developers you’re trying to reach.
A comparative study running 75 tests between MCP-based and CLI-based agents found CLI won every efficiency metric: 10 to 32 times cheaper on tokens, with reliability near 100% versus roughly 72% for MCP. The reason is structural. MCP hosts load every tool’s name, description, and full JSON schema into context before a single question gets answered. Stack three or four MCP servers and you can burn 150,000 tokens on overhead alone. Perplexity went far enough to publicly pull MCP support from their own agent architecture, citing this same token overhead and reliability gap (source).
The nuance matters, though. This backlash comes almost entirely from individual developers optimizing personal token spend on coding tasks. Teams that need OAuth, audit trails, or multi-tenant access control get real value from that same MCP structure, overhead included. That distinction turned out to be the actual answer for us.
What We Actually Hit Trying to Answer This
CrossMind already has a capability that maps cleanly to a stateless tool call: signal-scan, our Reddit/HN prospect-search primitive. Give it a product URL, get back ranked leads. Single input, single output, no memory required between calls. Genuinely MCP-shaped.
Everything else in the product doesn’t fit that shape at all. Cloud browser identity (the session that stays logged into X or Reddit across runs) needs to persist between calls instead of getting re-established every time a tool gets invoked. The approval queue is the harder case: every social post, DM, or reply CrossMind drafts waits for a human decision before it goes out, and that needs a UI a person can actually sit with, not a JSON response an agent parses and discards. Scheduled tasks need a process that’s still alive tomorrow, whether or not anyone calls the tool again today.
Try to force those three into a stateless MCP interface and what you get isn’t a lighter version of the product. It’s a broken one, the same “chatbot with a nicer interface, not an agent” failure mode we wrote about when 16,000 MCP servers turned out to produce maybe 130 real agents.
A Four-Question Framework for Your Own Product
Before you decide, run whatever capability you’re considering through these:
- Does it need memory across calls? If the value depends on remembering what happened last time (a running conversation, an accumulating research file, an evolving strategy), a stateless tool call throws that away by design.
- Does a human need to review output before it’s real? Anything with an approval gate (content, outreach, financial actions) needs a persistent interface a person returns to, not a fire-and-forget response.
- Does it depend on a live session (browser, OAuth token, long-running connection)? Sessions that need to survive between invocations don’t compress into a single tool call without re-authentication overhead that defeats the purpose.
- Is the output a single, complete artifact, or an ongoing process? “Here are 10 leads for this URL” is a clean tool call. “Manage my outreach pipeline” is a product, not a function.
Zero yeses: build the MCP tool, it’s a legitimate distribution wedge into where builders already work. One or more yeses: you’re looking at a standalone product with an MCP-shaped edge, not an MCP tool with a product-shaped afterthought.
Where This Leaves Us
We’re not becoming “an MCP server” wholesale. We’re also not ignoring the distribution case for lowering the barrier for Claude Code and Codex builders. The signal-scan primitive is the closest fit for an MCP-callable slice: a real, narrow, stateless capability, not a repackaged whole product. The browser identity, approval workflow, and scheduling layers stay put, as a standalone system built for exactly the parts of growth execution a tool call can’t hold. If your product’s core value lives in memory, human review, or a live session, that’s the same test that should stop you from wrapping the whole thing in MCP just because the ecosystem is loud about it right now.
If you’re weighing this same call for your own product, here’s the fastest gut-check, the one CrossMind itself fails on three counts: try describing your core loop as a single input/output pair. If you can’t, you’re building a product with a tool-shaped edge, not a tool.
Curious what CrossMind’s actual growth execution loop looks like end to end? See what an AI cofounder actually does day to day, how it compares to general automation tools, and why Claude Code alone won’t get you users even with 46% developer share behind it.
Still working out where your own product falls on this test? CrossMind runs the standalone side of it every day: research, drafts, human-approved execution, scheduled follow-through, for founders who don’t have time to build both halves themselves. The output is a working growth loop, not a stitched-together tool call. See it work on your own product.