Claude Code MCP Result Persistence & Plugin bin Executables — Q2 Features Tested

Published April 14, 2026 · 14 min read

Why These Two Features Matter More Than the Headline Updates

Every Claude Code release note contains a dozen bullets. The April 2026 changelog is no exception — most of it is bug fixes for resume, plan mode, terminal, and Windows. The two items that actually change what you can build are easy to miss: MCP result persistence and plugin bin executables. They each solve a specific friction that limited what plugin authors could ship until now.

If you have ever watched Claude Code truncate a Postgres schema dump halfway through and then hallucinate the rest of the tables, you know why the 500K character persistence override matters. If you have ever told a user "first install ripgrep, then install this plugin" — and watched them give up on step one — you know why plugin bin matters.

MCP Result Persistence: The 500K Override, Explained

Before April, MCP tool responses were truncated at Claude Code's default context-safety limit. For small responses this was fine. For anything that returned structured data at scale — database schemas, directory trees, multi-file diffs, long log tails — the truncation landed mid-record and Claude Code either asked the tool to run again with filters, or filled in the gaps from its training set. The second failure mode is worse because the agent doesn't flag that it guessed.

The new annotation lets an MCP tool opt a specific response into higher persistence:

{
  "content": [
    { "type": "text", "text": "<full schema dump, 380K chars>" }
  ],
  "_meta": {
    "anthropic/maxResultSizeChars": 500000
  }
}

Three things to know about using it:

• It is per-response, not per-tool. The same tool can return a persistent large result for one query and a normal truncated result for the next. Set the annotation only when the full payload actually matters.
• 500K is a cap, not a default. Lower values are valid and cheaper — a 50K cap on a log-streaming tool still meaningfully expands what Claude Code sees.
• Cost scales linearly. 500K characters is roughly 125K tokens of input context. On Opus 4.6 pricing that is real money per call. Use the cap for the responses that need it, not as a default.

The concrete case I tested: an MCP server that wraps pg_dump --schema-only on a 240-table production database. Pre-update, Claude Code saw the first ~40 tables and hallucinated foreign-key relationships for the rest. Post-update, with the annotation set to 500000, it saw the full schema and produced correct migration SQL on first attempt. The latency difference was about 3 seconds. The correctness difference was binary.

Plugin bin Executables: What Changed and What You Can Ship

Until this release, a Claude Code plugin could ship skills, commands, and agents — but any external CLI the plugin wanted to call had to be pre-installed by the user. That worked for ubiquitous tools (git, curl) but broke for anything niche. Plugin authors routinely shipped install scripts with README warnings, and a meaningful fraction of plugin failures traced back to users skipping or half-completing those steps.

Plugins can now include a bin/ directory. Executables or shell scripts placed there become available on PATH while the plugin is active. Structure:

my-plugin/
├── plugin.json
├── skills/
│   └── deploy-preview.md
├── commands/
│   └── preview.md
└── bin/
    ├── preview-linux-x64
    ├── preview-darwin-arm64
    └── preview.sh

A skill or slash command can now reference preview directly, and it resolves to the plugin-bundled binary. Cross-platform ships are the author's responsibility — the plugin manifest can declare platform-specific binaries, but there is no universal-binary magic. Most real plugins will either ship a shell script that wraps an existing system tool, or three binaries matched to linux-x64, darwin-arm64, and win-x64.

There is one safety caveat. As of the same release, inline shell execution in skills and slash commands is disabled. You cannot put $(...) or backtick-expansion inside a skill markdown file and have it run. The supported patterns are:

• Ship an executable in bin/ and have the skill reference it by name
• Invoke bash from inside an agent turn, where the agent explicitly chose to run the command
• Use an MCP server that wraps the shell behavior and presents it as a typed tool

This is the right tradeoff. Inline shell in skills was the attack surface that made supply-chain compromises of plugins feel plausible. Moving command execution through either agent-driven bash or plugin bin means a user can inspect what a plugin ships before loading it.

What to Migrate, and in What Order

If you maintain a Claude Code plugin or a private skill library, the migration order that caused me the least breakage:

1. Audit skills for inline shell. Any skill using $(...) or backticks will silently no-op post-update. Rewrite each one to either call a plugin bin executable or use agent-driven bash.
2. Move frequently-called CLIs into plugin bin. If your plugin README says "install jq, yq, and rg", ship shell wrappers that gracefully fall back to system-installed versions but bundle a minimal vendored copy.
3. Add MCP result persistence to schema and log tools. Any MCP tool that returns structured dumps over ~10K characters will benefit. Start at 100K and raise only if you see truncation.
4. Test /reload-plugins in-session. Confirm your plugin's skills reload without restart. If they don't, check your plugin.json manifest — the reload path only picks up skills declared there.

How This Compares to Cursor, Codex, and Windsurf

MCP result persistence is a differentiator right now. Cursor supports MCP but truncates tool responses at a fixed limit with no per-response override. OpenAI Codex's April update added Realtime V2 background agent streaming and tighter MCP tool typing, but no equivalent persistence annotation. Windsurf runs MCP on the shared Anthropic protocol but does not surface the _meta annotation to tool responses in its current release.

Plugin bin is a harder comparison. Cursor's extension model bundles VSIX-packaged extensions and inherits the VS Code extension host, so it has had executable plugins for years — just not through the same MCP-plus-skills lens Claude Code uses. Codex plugins are closer to the Claude Code model, and are likely to add an equivalent bin mechanism in the next release based on changelog trajectory.

The practical upshot: if you are writing plugins that pass large structured payloads between MCP and the agent, Claude Code is currently the only runtime where the full payload reliably lands in context. If you are writing plugins that bundle CLI tooling, Claude Code and Cursor are now roughly at parity, but with different packaging conventions.

Related Reading on OATH

• Best Claude Code Skills in 2026 — 349 Agent Skills Ranked by GitHub Stars
• Claude Code Agent Teams — The Multi-Agent Workflow Guide
• Claude Code Memory for Large Codebases — CLAUDE.md and Subagents Explained
• Claude Code Extensions Guide