{"slug": "mcp-is-dead", "title": "MCP Is Dead", "summary": "A backend engineer at Quandri has declared MCP \"dead\" after measuring that connecting four MCP servers consumes 10.5% of a model's context window on tool definitions alone, with Linear's server alone occupying over 12,800 tokens for 42 tools. The engineer found MCP was 3x slower per call than direct API usage and consumed roughly 65x more tokens to look up the same Linear issue, arguing that existing CLI tools and API calls are more efficient and reliable. The post recommends replacing MCP with \"Skills\" that embed CLI usage instructions, loading only the commands needed into context rather than carrying all tool definitions at all times.", "body_md": "Backend Engineer @ Quandri\n\n**TL;DR**: MCP eats context, has low reliability, and overlaps with existing CLI/API.\n\n💡\n\nReference: [MCP is dead. Long live the CLI](https://ejholmes.github.io/2026/02/28/mcp-is-dead-long-live-the-cli.html)\n\nAfter reading the above article, we ran the experiments on our actual stack. This document covers the original argument, additional research, and our measurements.\n\n📌\n\n**Update:** Since these measurements were taken, Claude Code has rolled out [Tool Search with Deferred Loading](https://code.claude.com/docs/en/mcp), which loads MCP tool schemas on-demand and reduces context usage by 85%+. The context bloat described in Problem 1 is largely addressed for users on current Claude Code versions. The performance, debugging, and architectural arguments below still apply.\n\nMCP (Model Context Protocol) connects LLMs to external tools (GitHub, Linear, Notion, Slack, etc.).\n\nSince its launch in late 2024, it's been called \"the USB-C of the AI ecosystem.\" But developers actually using it day-to-day are starting to think differently.\n\n**TL;DR**: MCP eats context, has low reliability, and overlaps with existing CLI/API.\n\nThe context window is the LLM's desk. When you connect MCP servers, **tool definitions alone** take up a significant chunk of that desk.\n\nRestaurant analogy:\n\nWe extracted and measured the actual tool definitions from the MCP servers connected in our environment. **With all 4 servers connected, 10.5% of the context window is consumed by tool definitions alone.**\n\nLinear alone accounts for over 12,800 tokens. That's 42 tool definitions always loaded, even if you only ever use `get_issue`\n\nand `save_issue`\n\n.\n\nPerformance is a known issue. The author of the original article benchmarked Jira MCP against its REST API directly and found **MCP was 3x slower per call, and 9.4x slower on first call including initialization**. This isn't Jira-specific, it's architectural: every MCP server adds a process layer between the LLM and the underlying API. The same overhead applies to the Linear, Notion, and Slack servers in our stack.\n\n**How many tokens does it cost to look up the same Linear issue?** MCP consumes ~65x more tokens than the CLI approach.\n\n```\n[ CLI approach: ~200 tokens ]\ncurl -s -H \"Authorization: Bearer $LINEAR_TOKEN\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"query\":\"{ issue(id: \\\"ISSUE-ID\\\") { title state { name } assignee { name } } }\"}' \\\n  https://api.linear.app/graphql\n\n-> Prompt (curl command): ~50 tokens\n-> Response: ~150 tokens\n\n[ MCP approach: ~12,957 tokens ]\n-> Tool definitions (always loaded): ~12,807 tokens (42 tools)\n-> Tool call + response: ~150 tokens\n```\n\n``\n\nProvide CLI -> API -> docs, in that order. LLMs already learned from man pages and StackOverflow.\n\nUsing existing CLI directly:\n\nIf MCP is \"spreading all menus on the table upfront\", Skills is \"**asking the librarian for only the book you need**\".\n\nThe key is embedding CLI usage instructions inside Skills. Combined with Alternative 1's CLI-first strategy, this is most efficient. For example, a Linear skill:\n\n```\n# Linear Issue Lookup Skill\n- Linear API: https://api.linear.app/graphql\n- Auth: Bearer Token ($LINEAR_TOKEN env var)\n- Get issue: curl -s -H \"Authorization: Bearer $LINEAR_TOKEN\" -H \"Content-Type: application/json\" -d '{\"query\":\"{ issue(id: \\\"ISSUE-ID\\\") { title state { name } assignee { name } } }\"}' https://api.linear.app/graphql\n- Search issues (GraphQL): adjust the query field for JQL-like filtering\n- Results are JSON, parse with jq\n```\n\n``\n\nThis way, the LLM only loads the above into context when the skill is invoked. No need to carry 42 tool definitions at all times. Just the CLI commands it needs.\n\nNot entirely. MCP is still valid when:\n\nShort answer: it depends.\n\nDBs are just query execution at the end of the day. LLMs already know SQL and MongoDB queries well. Put DB info and CLI usage in a skill, and it works fine without MCP. Just give it the schema and it writes the queries.\n\n```\n# Postgres Skill\n- Host: postgres://localhost:5432/myapp\n- Tables: users (id, name, email), orders (id, user_id, status)\n- CLI: psql -h localhost -d myapp -c \"SELECT * FROM users WHERE ...\"\n```\n\n``\n\nHowever, MCP has advantages for databases:\n\n`DROP TABLE`\n\n.\n\nBut for most developer workflows, MCP is over-engineering.\n\nThese days, every SaaS landing page has \"MCP supported\" in the feature list. Whether the MCP server is stable or how much context it eats doesn't matter - the goal is checking the \"we do MCP too\" box. Same pattern as \"AI-powered\" and \"blockchain-based\" marketing from years past. When users actually connect, they get dozens of tool definitions loaded, initialization failures, and mid-session crashes.\n\nAt Quandri we use all three approaches side by side, picking what fits each service:\n\n`gh`\n\n, `psql`\n\n, `aws`\n\n). Zero context cost, full flexibility, debugs straight in the terminal.We don't force one path. If a CLI already exists and authenticates locally, that's usually the lightest option. If a service has no CLI or we need uniform auth across the team, MCP earns its keep.\n\n**Teaching well matters more than connecting everything.**\n\nFor us, replacing MCP servers with Skills that wrap existing CLIs freed up ~21K tokens of context, removed init failures from our daily workflow, and kept debugging in the terminal where it belongs.\n\nLoad only the tools you need, only when you need them, with CLI instructions baked in. MCP might evolve to solve these problems, but right now, Skills win.****\n\n****\n\n**Measurement methodology**:", "url": "https://wpnews.pro/news/mcp-is-dead", "canonical_source": "https://www.quandri.io/engineering-blog/mcp-is-dead", "published_at": "2026-05-29 22:56:49+00:00", "updated_at": "2026-05-29 23:11:35.115620+00:00", "lang": "en", "topics": ["large-language-models", "ai-tools", "ai-agents", "ai-infrastructure"], "entities": ["MCP", "Claude Code", "Quandri", "GitHub", "Linear", "Notion", "Slack"], "alternates": {"html": "https://wpnews.pro/news/mcp-is-dead", "markdown": "https://wpnews.pro/news/mcp-is-dead.md", "text": "https://wpnews.pro/news/mcp-is-dead.txt", "jsonld": "https://wpnews.pro/news/mcp-is-dead.jsonld"}}