MCP is dead?
quandri.io
MCP is dead?
1–10 of 444 posts
Re: MCP is dead?
#2is this post old? MCP context poisoning was fixed like months ago
i personally was anti-MCP but they just work better in terms of tool search than a CLI, especially with the idea of tool nudging
Re: MCP is dead?
#3I've thought that skills and small scripts > MCP for quite a while now, tried out MCP in the early days (official ones, ones i made for scripts i already had), but they always end up using more tool calls/tokens than if i had just written a script + skill for claude.
Re: MCP is dead?
#4is this post old? MCP context poisoning was fixed like months ago i personally was anti-MCP but they just work better in terms of tool search than a CLI, especially with the idea of tool nudging
> Update: Since these measurements were taken, Claude Code has rolled out Tool Search with Deferred Loading, 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.
pretty much
Re: MCP is dead?
#5I'll kick myself for not remembering, but there was a fantastic article which suggested that MCP works at org level when unified, safe, access to internal utility APIs need to be given to non-technical staff who do use internal agent tools. Codify your workflow(s) via skills and share across instances, anything that needs context aware API access should be mcp...
Re: MCP is dead?
#6I've thought that skills and small scripts > MCP for quite a while now, tried out MCP in the early days (official ones, ones i made for scripts i already had), but they always end up using more tool calls/tokens than if i had just written a script + skill for claude.
MCP seems like what you'd do when you want to encapsulate and share a skill+script in a standard way.
Re: MCP is dead?
#7These AI slop articles about AI are getting especially boring to read.
> Problem 1: It Devours the Context Window
Don't harnesses support progressive discovery these days?
Claude (200K).... GPT-4o..........?
> every MCP server adds a process layer between the LLM and the underlying API
But a CLI doesn't?
------------------
> Measurement: Tool Definition Sizes
> MCP Server: Linear, Notion, Slack, Postgres
Oh, so these are the MCP servers that are examples of context bloat we're going to replace! Later in the article:
> At Quandri we use all three approaches side by side...
> MCP for services without a strong CLI (Slack, Linear, Notion)
Re: MCP is dead?
#8So what's this saying? Rather than trust the llm to query external tools via mcp you should handle the external queries yourself? Otherwise the llm wastes a bunch of queries?
Re: MCP is dead?
#9I'll kick myself for not remembering, but there was a fantastic article which suggested that MCP works at org level when unified, safe, access to internal utility APIs need to be given to non-technical staff who do use internal agent tools. Codify your workflow(s) via skills and share across instances, anything that needs context aware API access should be mcp...
Exactly right. Co’s like Runlayer are growing like wild exactly for this reason. Without a central control plane MCP is a minefield.
Re: MCP is dead?
#10I've thought that skills and small scripts > MCP for quite a while now, tried out MCP in the early days (official ones, ones i made for scripts i already had), but they always end up using more tool calls/tokens than if i had just written a script + skill for claude.
MCP seems like what you'd do when you want to encapsulate and share a skill+script in a standard way.
You can share a skill by copy pasting the text file to someone in slack.
Its not that hard.