We rebuilt Exa's research plugin once and shipped it to four hosts

If you only expose the MCP, every host still needs someone to shape the user experience around it. Commands, subagents, setup guidance, install packaging, and host-specific behavior do not maintain themselves.

To show what that looks like in practice, we built a clean-room Exa example from three inputs: Exa's public MCP, Exa's public docs, and the workflow shape of Exa's official Claude plugin.

What we built from Exa

The result is one maintained source project that generates native bundles for Claude Code, Cursor, Codex, and OpenCode from the same source tree.

• Deep research
• Company research
• People research
• Code research
• Source review
• News briefs

It also keeps the pieces that usually get flattened away when the story gets reduced to a thin “here are the tools” surface:

• specialist agents and subagents
• auth and setup guidance
• branding metadata, screenshots, and prompts
• a bundled Exa MCP connection rather than generic web-search fallback

Why this matters for Exa

Exa already has a workflow that people want. The distribution problem is everything around it. If the same operator-grade research experience can reach Claude Code, Cursor, Codex, and OpenCode without becoming four separate plugin products, the maintenance story gets materially better.

The value is not “we can connect to Exa.” The value is “we can keep one workflow layer, then compile the most native honest version of that experience for each host.”

What “live” means here

The Exa example is not just a build artifact. It has now been exercised through real host workflows:

• Claude Code app
• Cursor CLI
• Codex Desktop
• OpenCode CLI

That matters because it means the bundled Exa MCP is not merely listed in plugin metadata. It is actually callable through the generated workflows.

• Claude Code runs the Exa workflows in-app with the plugin-bundled MCP tools attached.
• Cursor picks up the same research playbooks and routes them through Exa-backed workflows instead of a generic web-search fallback.
• Codex Desktop can invoke the plugin directly and call Exa through the bundled plugin-scoped MCP connection.
• OpenCode keeps the research pack intact through its own native agent and command surfaces.

How much was automatic

A raw `init --from-mcp` or `autopilot` run already gets to a credible Exa-shaped starting point. `migrate` from a strong Claude-first plugin would likely get even closer.

What still took explicit shaping in this final example was the workflow taxonomy, the specialist-agent graph, the orchestrator prompts, and the public install and proof surfaces. That is the next product leverage for Pluxx: make the first pass recover more of that structure automatically.

What this says about Pluxx

Pluxx is not just a skill-pack copier and it is not a generic MCP wrapper. It is the layer that keeps one maintained plugin source project while compiling the best truthful native version of that experience for each host.

Install it

These installers build the public Exa example from source and install the native bundle directly into the host you already use:

curl -fsSL https://raw.githubusercontent.com/orchidautomation/pluxx/main/example/exa-plugin/release/install-claude-code.sh | bash

curl -fsSL https://raw.githubusercontent.com/orchidautomation/pluxx/main/example/exa-plugin/release/install-cursor.sh | bash

curl -fsSL https://raw.githubusercontent.com/orchidautomation/pluxx/main/example/exa-plugin/release/install-codex.sh | bash

curl -fsSL https://raw.githubusercontent.com/orchidautomation/pluxx/main/example/exa-plugin/release/install-opencode.sh | bash

If you want higher Exa limits, set `EXA_API_KEY` in your shell before you run the installer.

If you want the full proof trail, start with the repo proof note and the Exa source project.