Does Anthropic's Tool Search make sverklo obsolete?

No. Tool Search and sverklo solve different halves of the same bill. Tool Search lazy-loads MCP tool DEFINITIONS — the manifest the agent sees in its system prompt. Anthropic reports ~85% manifest-token reduction in Claude Code default-on as of Feb 2026. Sverklo's wedge is RETRIEVAL — replacing 7-12 noisy grep calls with one structured MCP call against a symbol graph. The 312-session field study measured grep at 41% of input-token spend; Tool Search doesn't touch that number. They stack: Tool Search shrinks sverklo's own manifest, sverklo shrinks the retrieval cascade. Both wins are real, both are additive.

How is Tool Search different from sverklo's SVERKLO_PROFILE?

Both reduce manifest tokens but operate at different layers. SVERKLO_PROFILE is server-side: sverklo advertises only the tools in the active profile (core/nav/lean/research/review/full). The host (Claude Code, Cursor, Windsurf, etc.) sees a smaller tools/list response. Tool Search is host-side: Claude Code keeps the full manifest server-side and pages in tool definitions on demand. SVERKLO_PROFILE works in every MCP host (Cursor, Windsurf, Zed, JetBrains don't have Tool Search yet); Tool Search is Claude-Code-only today. They're complementary — set SVERKLO_PROFILE=core for narrower advertisement, let Tool Search lazy-load whatever Claude Code does need.

What's the grep cascade and why does it cost so much?

Watch any Claude Code session on a 200+ file repo. The agent runs grep with a guess at the symbol name, gets 200 lines of noisy matches, runs two more greps with different flags to disambiguate, then maybe a fourth grep with a longer pattern. Each result is raw text dumped into context. A 312-session instrumented study measured this pattern at 41% of total input-token spend — by far the largest single cost line. Replacing the cascade with one structured MCP call (sverklo_lookup or sverklo_search) drops it to ~500 tokens. That's the retrieval bill Tool Search doesn't touch.

Do I need both Tool Search and sverklo?

If you're on Claude Code: yes, they're additive. Tool Search shrinks the manifest (server-side), sverklo shrinks retrieval (replaces grep). If you're on Cursor, Windsurf, Zed, or JetBrains: Tool Search isn't available, so SVERKLO_PROFILE=core is your manifest fix AND sverklo handles retrieval. Either way, sverklo doctor's MCP dispatch probe (initialize + tools/list + tools/call) confirms the wiring works in your specific host. The two systems were designed for different layers — there's no overlap in what they optimize.

Why does sverklo still ship SVERKLO_PROFILE if Tool Search exists?

Three reasons. (1) Most agents aren't Claude Code. Cursor (largest user base), Windsurf, Zed, JetBrains Junie, Antigravity — none have Tool Search yet. SVERKLO_PROFILE is the only manifest fix that works on them. (2) Tool Search has cold-start cost: the first time Claude Code wants a sverklo tool, it pages in the definition. A smaller server-advertised surface avoids that round trip. (3) Defense in depth: even on Claude Code, two reductions stack — sverklo advertises 6 tools (not 36), Tool Search lazy-loads from those 6. Belt-and-suspenders on token cost is the right posture for token-conscious deployments.

/* engineering · 2026-05-11 · context economics */

Anthropic's Tool Search Fixed the Manifest. It Didn't Fix the Grep Cascade.

2026-05-11 ~7 min read Companion: SVERKLO_PROFILE measured

Tool Search shipped GA in January 2026 and is now default-on in Claude Code. Anthropic reports it cuts MCP manifest tokens by ~85%. A predictable question follows: does sverklo's "stop Claude Code from burning tokens on grep" pitch still hold? Short answer: yes, because they're not the same bill. Tool Search shrinks the manifest. Sverklo replaces the grep loop. The 312-session field study we ran in May measured grep at 41% of total input-token spend — Tool Search doesn't touch that number. Long answer below.

Two different bills

Every Claude Code session that uses MCP pays tokens in at least two places:

Bill	What's in it	Typical cost (full sverklo)
Manifest	The `tools/list` response — every MCP tool's name, description, JSON schema, fed into the system prompt on session start	~8,016 tokens for 36 tools
Retrieval	Tool-call results streamed back into context — grep output, file contents, search hits	~14,200 tokens per "find a function" task (312-session study)

Tool Search optimizes the manifest bill. It moves the tool catalog server-side and pages in definitions on demand. ~85% reduction on the manifest, per Anthropic's published numbers. Default-on in Claude Code as of Feb 2026.

Sverklo optimizes the retrieval bill. The agent calls sverklo_search or sverklo_lookup against a pre-built symbol graph instead of running grep. One structured tool call replaces 7-12 grep cascades. The retrieval payload drops from ~14,200 tokens to ~500.

These are different lines on the receipt. Optimizing one doesn't optimize the other.

The 312-session study

Earlier this month we instrumented 312 Claude Code sessions on real engineering tasks — the same harness the bench uses, but with token-attribution turned on. Full writeup here. The breakdown by category of input-token spend:

Grep cascades — 41% of input tokens. The largest single line. Tool Search doesn't touch this.
Tool manifest — 6% of input tokens before Tool Search. Now ~1% with default-on Tool Search.
File contents read — 28% of input tokens. Sverklo's structured retrieval reduces this substantially because results come pre-scoped to symbols.
Conversation history + system prompt — 25%. Out of scope for both tools.

Tool Search default-on dropped manifest from 6% to ~1% on Claude Code sessions — real, measurable, exactly what Anthropic claimed. Grep cascades stayed at 41%. The bottom-line input-token spend dropped ~5% on a typical session from Tool Search alone. That's a real win and it stacks cleanly with sverklo's retrieval-side wins.

SVERKLO_PROFILE vs Tool Search

Worth being precise about manifest reduction because both systems do it, but at different layers:

System	Layer	Mechanism	Hosts
SVERKLO_PROFILE	Server-side	sverklo advertises fewer tools in `tools/list`	Every MCP host
Tool Search	Host-side	Claude Code lazy-loads tool definitions from full server catalog	Claude Code only (today)

Three things this matters for:

Most agents aren't Claude Code. Cursor (the largest installed base), Windsurf, Zed, JetBrains Junie, Antigravity — none have Tool Search yet. For users on those hosts, SVERKLO_PROFILE=core is the only manifest fix available. Sverklo defaults to that profile as of v0.20.9, so the win lands without configuration.

Cold-start cost. Tool Search's first request for a sverklo tool requires a round trip to page in the definition. On a session that starts with "find auth code", that's one extra round-trip latency before the agent actually retrieves. SVERKLO_PROFILE eliminates that by advertising only the tools likely to be used.

Defense in depth. Even on Claude Code with Tool Search, two reductions stack. Sverklo advertises 6 tools (not 36); Tool Search then lazy-loads from those 6. The combined manifest cost is lower than either system alone.

The verification problem (and how doctor solves it)

One real difficulty with both systems: how do you know they're working? Tool Search is transparent to user code. SVERKLO_PROFILE applies at tools/list time and isn't visible in any standard MCP tooling. A user could install sverklo, expect core profile, and have no way to confirm the host actually sees 6 tools and not 36.

That's the gap sverklo doctor fills. As of v0.20.15, the doctor probe sends the same three calls Claude Code makes on every fresh session — initialize → tools/list → tools/call sverklo_status — and reports the tool count it actually receives:

$ sverklo doctor
sverklo doctor — checking MCP setup
  ✓ .mcp.json (project root)     sverklo configured (profile: core)
  ✓ MCP handshake                responds correctly (protocol 2024-11-05)
  ✓ MCP tools/list               6 tools advertised (sverklo_status present)
  ✓ MCP tools/call               sverklo_status returned 1021 chars — dispatch round-trip works

All checks passed — MCP dispatch verified end-to-end.

If you see "6 tools advertised" the SVERKLO_PROFILE is in effect. If you see "36 tools advertised" with profile=core in .mcp.json, something's wrong — and doctor will say so. (v0.20.15 fixes a real bug where doctor's own probe ignored the .mcp.json env block — the headline v0.20.9 fix used to be silently undone in the headline diagnostic.)

What if Anthropic ships native code intel?

This is the right next question. Tool Search is one of several Anthropic patterns absorbing what used to be MCP-server territory — Code Execution with MCP (write Python to call tools), Skills (declarative behavior bundles), Tool Search (lazy manifest). The honest answer is: if Anthropic ships a built-in symbol graph for Claude Code, sverklo's wedge gets narrower for Claude Code specifically.

Three reasons we still think this works:

Multi-host is structural. Anthropic native features land in Claude Code first, the rest of the ecosystem second (or never). Cursor users, Windsurf users, Zed users, JetBrains users — they need a non-vendor solution. Sverklo's job there doesn't change.
Bench is the moat. Whatever Anthropic ships, the public 90-task benchmark measures both sverklo and the new alternative on the same tasks. We'd publish the head-to-head numbers honestly, including the slices where the built-in wins. That credibility compounds even when the underlying product changes.
Bi-temporal memory is uncontested. Tool Search is stateless. Code Execution is stateless. Skills are stateless. Sverklo's memory_remember / memory_recall with SHA-pinned validity is the one thing no other MCP server (or native host feature) currently offers. Deep dive on the architecture.

Bottom line

Tool Search is a real ship. Anthropic's 85% manifest reduction number lines up with our measurements. If you're on Claude Code, you should let it run — sverklo's manifest gets lazy-loaded automatically and you save ~5% of input tokens session-over-session for free.

But Tool Search and sverklo are not competitors. The retrieval cascade — grep loops, file reads, low-signal context dumps — is a separate bill, ~41% of input-token spend, and it's still the largest single cost line in a Claude Code session. Sverklo's wedge is on that bill. The numbers hold.

Try the stack

npm i -g sverklo@latest
cd your-project && sverklo init    # writes SVERKLO_PROFILE=core
sverklo doctor                       # verifies dispatch end-to-end
# Then restart your AI agent — sverklo + Tool Search compose automatically on Claude Code

github.com/sverklo/sverklo · Public 90-task bench · Security posture