Skip to main content

AutoSearch as an MCP Server

AutoSearch ships a standard Model Context Protocol stdio server that exposes the v2 tool-supplier toolkit — list_skills, list_channels, run_clarify, select_channels_tool, run_channel, delegate_subtask, plus citation_create / citation_add / citation_export, doctor, and helper tools such as health — to any MCP client. The host agent calls these tools and synthesizes the final answer itself; AutoSearch does not return a pre-baked report. Because the protocol is client-agnostic, the same server binary plugs into Claude Code, Cursor, Zed, Continue, and any other MCP-speaking surface without recompilation. This page shows the config format for each supported client plus a one-minute verification routine.

Prerequisites

  • AutoSearch installed and on PATH (either pipx install autosearch or uv pip install -e . in a dev checkout). After install, the command autosearch-mcp should resolve.
  • At least one LLM provider key in your environment: ANTHROPIC_API_KEY, OPENAI_API_KEY, or GOOGLE_API_KEY. You can also rely on a logged-in claude CLI on PATH as the provider.
Verify locally before wiring up a client:
If the command is not found, your MCP client won’t be able to launch it either — fix PATH first (for pipx installs, pipx ensurepath usually does it).

Claude Code

Use Claude Code’s MCP command to add AutoSearch:
Claude Code stores local/user scoped MCP config in ~/.claude.json, and shared project config in <project>/.mcp.json. If the claude CLI is not available and you want project-bound config, run:
That writes <project>/.mcp.json. You can also point the CLI at a specific config for one invocation:
AutoSearch additionally ships a Claude Code slash command at commands/autosearch.md; drop it into ~/.claude/commands/ to get /autosearch <topic>.

Cursor

Cursor reads ~/.cursor/mcp.json. Same schema:
After saving the file, restart Cursor. Open the MCP panel — autosearch should appear with the v2 tools listed (list_skills, list_channels, run_channel, the citation helpers, etc.). Prompting the agent with something like “list autosearch skills, then run_channel on arxiv to survey vector database options” drives the v2 flow.

Using OpenAI or Gemini instead of Anthropic

Swap the env block for the provider you want to drive the pipeline:

Zed

Zed stores MCP servers under context_servers in ~/.config/zed/settings.json:

Continue

Continue uses ~/.continue/config.json:

The v2 MCP tools

The host agent drives a tool-supplier flow: discover skills, optionally clarify the user’s intent, pick channels, run them, and synthesize the answer. The 10 required v2 tools are the names in _REQUIRED_MCP_TOOLS; health is a helper, not a required install-contract tool. Beyond these, the server registers helpers like consolidate_research, list_modes, citation hardening (citation_merge), context controls (context_retention_policy), and several loop / planning helpers. The deprecated research tool is opt-in: it is only registered when AUTOSEARCH_LEGACY_RESEARCH=1 is set, and new integrations should not depend on it. run_channel schema:

Verifying the integration

Any MCP client supports a tools/list handshake before tools/call. If your client shows a GUI, seeing the v2 tool names (list_skills, list_channels, run_channel, …) in the panel is proof enough. For a scripted check without a GUI client, run this against any locally installed autosearch-mcp: Run it with the same Python interpreter that has AutoSearch installed (for a pipx install autosearch setup, that’s pipx run --spec autosearch python or inside the pipx venv — the snippet imports mcp which lives alongside autosearch-mcp, not in your system Python).
The same handshake lands under tests/e2b/matrix.yaml::F004_S4_mcp_stdio in CI, so if local Python says “OK” your client config is guaranteed to work at the protocol layer — the only variable left is the client’s own config file path and schema (covered in the sections above).

Troubleshooting

Where to go next