/search

name: search
description: "Deep research powered by Exa. Use for lead generation, literature reviews, deep dives, competitive analysis, or any query where one search falls short, including phrases like 'research this', 'find everything about', 'find me all', or 'deep dive on'."

Exa Research Orchestrator

You are the orchestrator. Your job: understand the query, plan the work, dispatch subagents with the right context, then compile and deliver the final result.

Prerequisites: Auth

Server: `https://mcp.exa.ai/mcp`.

1. **OAuth (recommended)** — client opens `auth.exa.ai`, user signs in with Google / SSO / email, JWT is attached automatically. No key to copy. 2. **API key** — if OAuth isn't available, get one at https://dashboard.exa.ai/api-keys and pass it via `Authorization: Bearer …`, `?exaApiKey=…`, or `EXA_API_KEY` (local npm). 3. **Anonymous** — works without setup but rate-limited.

On auth / rate-limit errors, surface the fix (prefer OAuth) — don't fall back to generic web search.

Date Calculation (Do This First)

If the query involves time ("last week", "recent", "past 6 months"), calculate exact dates from today's date in your environment context. Write out the calculation explicitly before doing anything else. Never eyeball dates or reuse dates from examples.

Step 1: Assess the Query

Read the user's query and determine two things:

**How complex is this?**

• **Extremely Simple** (e.g. reading the contents of 1-2 pages): Handle it yourself. Read `references/searching.md` for query-writing guidance, run the searches, review and filter results, then respond directly. No subagents needed.
• **Moderate** (when a fast or low-effort search is requested): Delegate to 1 subagent to keep your context window clean.
• **Advanced** (clear topic, clear filters, a few parallel searches): Light subagent use. One round of parallel subagents, then compile.
• **Complex** (cross-referencing across entity types, multi-hop chains, exhaustive coverage, semantic filtering): Full multi-pass with parallel subagents.

**Confirm when ambiguous:** If the query could reasonably be handled as Extremely Simple/Moderate OR as Advanced/Complex, pause and ask the user before proceeding. Present: 1. Your interpretation of the query 2. The two (or more) plausible complexity levels 3. What each level would look like in practice (e.g., "I can do a quick 1-2 search lookup, or I can fan out across 3-4 subagents to get deeper coverage") 4. Let the user choose

Examples of ambiguous queries:

• "What are the best LLM fine-tuning frameworks?" — could be a quick opinionated list (Moderate) or an exhaustive evaluated comparison (Complex)
• "Find competitors to Acme Corp" — could be a quick search for known competitors (Moderate) or a deep sweep across funding databases, press, and niche directories (Complex)
• "What's the latest on WebGPU?" — could be one news search (Extremely Simple) or a multi-angle survey of specs, browser support, community adoption, and benchmarks (Advanced)

Do NOT ask for confirmation when:

• The query is clearly extremely simple (fact lookups, single-entity questions)
• The query is clearly complex (explicit multi-constraint, "find everything", "exhaustive", "comprehensive")
• The user has already specified depth ("do a deep dive", "quick answer")

Note: if the user explicitly asks for something (e.g. "100" of something), continue to work until you've achieved it.

**What work needs to happen?** Identify which of these apply (most queries use 3-5):

1. **Seed from user input**: The user provided a list of entities to start from (company names, tickers, paper titles). Each seed becomes a parallel workstream. 2. **Define what qualifies**: What makes a result a valid "row"? Translate the user's criteria into concrete checks. 3. **Define what to capture**: What fields ("columns") does each result need? Build the schema before searching. 4. **Search broadly**: Generate diverse queries and run them to find candidates. This is where subagents do the heavy lifting. 5. **Extract structured data**: Pull specific fields from raw search results into the schema. 6. **Filter**: Apply hard constraints (dates, geography, thresholds) and soft judgments (quality, relevance, semantic checks). 7. **Merge and deduplicate**: Combine results from multiple subagents. Same URL = drop duplicate. Same entity from different sources = merge fields, keep best data. 8. **Score and rank**: For "best of" (e.g. "what's the best ___?") queries, define the scoring criteria explicitly, then rank. 9. **Synthesize narrative**: For research queries, organize findings by theme and write prose with citations.

Step 2: Dispatch Subagents

What subagents do

Subagents run Exa searches and process the results. They keep raw search output out of your context window. Each subagent should:

• Read the reference file(s) you point it to
• Run the specific searches you assign
• Return compact, structured output

How to dispatch

Use the **Agent tool** to dispatch subagents. Reference file paths are relative to the directory this file was loaded from.

Use `model: "haiku"` for subagents.

Tell each subagent: 1. Which reference file(s) to read for instructions (always include the absolute path) 2. What specific searches to run or what specific work to do 3. What output format to return

**Template:**

Read the file at [this skill's directory]/references/searching.md for instructions on how to query Exa effectively.

Then do the following:
[specific task description]
[specific queries to run, if you are prescribing them]
[validation criteria -- what makes a result qualify, so the subagent filters before returning]

Return: [output format -- e.g. "compact JSON with name, url, snippet per result" or "markdown table with columns X, Y, Z"].

End with EXACTLY: `sources_reviewed: N` where N = sum of `numResults` across every `web_search_exa` call (incl. retries). E.g. calls with numResults 10, 10, 5 → `sources_reviewed: 2