MCP Is Dead: Why a Quandri Engineer Prefers Skills and CLIs

A post on the Quandri engineering blog argues that the Model Context Protocol, the standard that connects large language models to external tools, has become the wrong default for most developer workflows. Author Chloe Kim, a senior software engineer at the company, sums up the case in three points: MCP eats context, has low reliability, and overlaps with tools developers already have.

The article follows a widely shared essay, "MCP is dead. Long live the CLI", and reports measurements taken on Quandri's own stack. In an update, the author notes that Claude Code has since shipped Tool Search with Deferred Loading, which loads MCP tool schemas on demand and cuts context usage by more than 85% — largely addressing the first problem for users on current versions, though the performance, debugging and architectural arguments still stand.

77 tool definitions, about 21,000 tokens

MCP servers connect assistants to services such as GitHub, Linear, Notion and Slack. Since its launch in late 2024, the protocol has been described as the "USB-C of the AI ecosystem". The cost shows up in the context window: with four servers connected, tool definitions alone consumed 10.5% of Claude's 200K context window, and would take 16.5% of GPT-4o's 128K window. The team counted 77 tools and roughly 84,300 characters — about 21,000 tokens. Linear alone accounted for 42 definitions and more than 12,800 tokens, loaded even if a user only ever calls two of them.

Reliability and a 65x token gap

The post lists operational problems: initialization failures and repeated re-authentication, slower responses from a server round-trip on every call, crashes that kill tools mid-session, and permissions that are hard to inspect. The author of the original essay benchmarked a Jira MCP server against the same service's REST API and found it three times slower per call, and 9.4 times slower on the first call including initialization. For a single Linear issue lookup, the MCP path consumed roughly 65 times more tokens than the CLI route.

What to use instead

The recommended order is CLI first, then API, then documentation: language models have already been trained on man pages and forum answers, and commands are composable with pipes, grep and jq. Where a repeatable workflow is needed, the "skills" pattern loads instructions only when invoked, instead of carrying dozens of schemas at all times.

MCP is not written off entirely. It still makes sense where a service has no CLI, for non-developer users who do not work in a terminal, and for real-time bidirectional communication. For databases the answer depends on context: local or personal databases suit skills plus a CLI, while production and shared team databases favour MCP, whose servers can enforce read-only modes and keep credentials out of the prompt.

At Quandri the three approaches are used side by side. The author reports that replacing MCP servers with skills wrapping existing CLIs freed about 21,000 tokens of context and removed initialization failures from daily work. Tool definition sizes were measured by extracting each tool's JSON schema from loaded servers, with tokens estimated at roughly four characters per token.