Your agent needs to search and read the web. Exa ships a hosted MCP server at mcp.exa.ai and a full REST API at api.exa.ai, and unlike most tools in this series, the MCP path here does not lock you out of headless execution. Exa MCP accepts a static API key in a header. That removes the usual "MCP cannot run without a browser" blocker and replaces it with a subtler one: capability coverage and per-user key isolation. Here's how to pick.
These are two access layers over the same index, maintained by the same team, with very different surface areas. The distinction that matters is not protocol; it is how much of Exa's platform each one lets your agent reach.
Exa MCP is an open-source, Exa-maintained server available as a hosted endpoint at https://mcp.exa.ai/mcp and as an npm package for local execution. It speaks Streamable HTTP and installs into Cursor, VS Code, Claude Code, Codex, and most other MCP clients with a single URL.
Authentication is unusually flexible for a hosted MCP server. Exa introduced a free unauthenticated tier in February 2026, rate-limited to 3 QPS and 150 calls per day; past that you attach your own key via an x-api-key header, and OAuth sign-in is supported for usage-based tools. Official documentation lives on the Exa MCP reference page, with the product overview at exa.ai/mcp and source at the exa-labs/exa-mcp-server repository.
The Exa REST API is a multi-surface platform, not a single search endpoint. It covers /search (six search types from instant through deep-reasoning), /contents for extraction from known URLs, /answer for synthesized answers with citations, /agent/runs for long-running research and enrichment, /monitors for scheduled searches with webhook delivery, the Websets API for large-scale list building, and a team-management API for programmatic key issuance.
Authentication is a bearer credential: pass the key as x-api-key or as Authorization: Bearer. There is no per-end-user OAuth grant model on the API surface. Start with the Exa Search API guide and the full /search reference.
Four dimensions decide this for a production agent: what the tools can do, which credential model you inherit, what you own operationally, and where each path wins.
The MCP server covers the search-and-read loop well and deliberately stops there. Everything stateful, scheduled, or bulk lives on the API.
Three gaps are structural rather than temporary. Monitors are the clearest: if your agent needs to react to new funding announcements or competitor launches over time, that requires Exa Monitors with a webhook endpoint, and there is no MCP tool for it.
Websets are the second. Discovering and verifying thousands of entities is an asynchronous, multi-object workflow spanning searches, items, enrichments, and imports. The Websets API guide describes a surface the MCP server does not model at all.
The third is run control. agent_run executes the whole loop in a single call and returns when it finishes. The Agent API lets you create, poll, stream, cancel, and replay events on a run. For a background pipeline that needs to abort a run when a user closes a session, that difference is not cosmetic.
Exa MCP supports three authentication postures: anonymous free tier, static API key in an x-api-key header or exaApiKey query parameter, and browser OAuth sign-in for usage-based tools like agent_run. The REST API supports one: a bearer API key.
This inverts the usual MCP tradeoff. For Notion, Slack, and Salesforce, the hosted MCP forces an interactive OAuth flow and disqualifies background agents. Exa MCP does not. A nightly research pipeline can call mcp.exa.ai with a header and no browser in the loop.
Because Exa's credential is a team-scoped API key rather than a per-user delegated grant, there is no provider-side mechanism that makes one user's agent see only that user's entitlements. Whatever isolation you get, you build.
That has a specific production consequence. Exa's documented rate limits apply per key: 10 QPS on /search, 100 QPS on /contents, 10 QPS on /answer, and Agent concurrency at one fifth of your account QPS, which is two simultaneous runs on a default pay-as-you-go account. One shared key across forty customers means one shared QPS ceiling and one shared spend line. A single tenant running a Websets job starves everyone else. This is the same structural problem described in how tool calling auth changes when you move from single-tenant to multi-tenant.
On the MCP path, Exa maintains the server, the tool schemas, and the tool descriptions. That is real operational value: when Exa shipped agent_run into MCP in July 2026, clients picked it up without a redeploy. You still own key storage, per-tenant isolation, quota attribution, and revocation.
On the API path you own all of that plus request construction, retries, pagination for Websets, webhook signature verification for Monitors, and per-surface error handling. You gain explicit control over search type, content extraction limits, and freshness, which is what determines cost per call.
MCP tool schemas are unversioned and change when Exa updates the hosted server. Exa has already deprecated eight MCP tools, including get_code_context_exa, company_research_exa, and crawling_exa, keeping them available only for backwards compatibility.
The API surface moves too, and it moves in public. The Exa changelog records the /research endpoint retiring in April 2026 in favor of type: "deep-reasoning" on /search, the people category replacing linkedin, the publication category replacing research paper, and startCrawlDate and endCrawlDate becoming silent no-ops. Any prebuilt tool schema layer, Exa's or a third party's, lags these deprecations. Read the changelog before you trust a parameter.
Exa bills per request plus per content item returned, which means the same search costs different amounts depending on what you ask back. As of Exa's March 2026 pricing update, search with contents was 7 dollars per 1,000 requests with the first 10 results included, summaries 1 dollar per 1,000, and Deep Reasoning 15 dollars per 1,000. Agent runs price separately in compute units.
The design implication is direct: include_text with a high max_characters on 20 results is not a neutral choice. Cap extraction, prefer highlights over full text, and set num_results deliberately. The API exposes every one of these knobs. The default MCP tools expose two. This cost-control discipline matters even more when you consider that MCP can be significantly more expensive than CLI-based approaches at scale.
Use Exa MCP when:
Use the Exa API directly when:
Both paths hand your agent an Exa API key. Neither hands you a vault, a rotation path, or a revocation flow. That gap is where production agents break, and it is identical on either side of the MCP decision.
In a multi-tenant B2B agent, every customer brings their own Exa account and their own key. Fifty customers is fifty keys to store encrypted, isolate per tenant, and invalidate when a customer churns. The MCP path gives you a key in a header. The API path gives you a key in a header. Neither gives you the layer underneath. For a deeper look at this problem, see who holds the token: credential ownership across agent tool-calling patterns.
A single service key looks correct in a demo. In production, every search burns quota against one account, per-tenant rate limits become one shared ceiling, and the audit trail shows a service account instead of the person whose agent ran the query. When finance asks which customer generated 40 percent of last month's Exa spend, there is no answer in the logs.
Scalekit's Exa connectors resolve the correct per-user key server-side on every tool call, so search runs under the identity that authorized it and the credential never enters agent runtime or LLM context. The same connected-account model works whether you build against MCP or the REST API, which means the path decision does not change your auth infrastructure.
Scalekit ships Exa as two separate connectors, matching the two access layers. Both authenticate with an API key, so neither requires an OAuth redirect or an authorization link.
Pick exa when the agent needs the full platform. Pick examcp when the agent only searches and reads, and you want the tightest possible tool surface in context. The connector overview page for both sits at scalekit.com/connectors/exa.
Create the connection once per environment in AgentKit > Connections, then note the connection name. That string must match the connection_name you pass in code exactly; a mismatch here is the single most common integration error.
Register a connected account when your user pastes their Exa key into your settings page. Because Exa is an API-key connector, there is no redirect and the account is usable immediately.
The agent should not load a connector catalog. It should load the tools this user's connected account is authorized to call, which is a scoped and deterministic surface, not an exploration. Scalekit returns those tools already shaped as LangChain StructuredTool objects, so no schema reshaping is needed.
With the surface scoped, the loop is ordinary LangChain. The user's Exa key is resolved server-side on each execute_tool call and never appears in the model context. For more on how LangChain tool calling fits into a production agent architecture, see LangChain tool calling: how it works, where it stops, and how Scalekit completes it.
Tool names come from the connector's tool list, and exa_search alone carries 19 parameters covering category, domain filters, freshness, and extraction caps. If you are unsure which name to use, list the tools for the current user first rather than guessing.
When the agent only needs search and fetch, the examcp connector gives you a two-tool surface. That is the smallest useful Exa context footprint you can hand a model, and it is the right default for an assistant that reads the web and nothing else.
Retrieve the authorized surface, convert it to Anthropic's tool format, and run the loop in full.
Monitors, Websets sub-resources, and the Agent run lifecycle have no MCP tool and, in some cases, no prebuilt Scalekit tool either. The proxy call closes that gap: you get raw endpoint access while the user's key stays vaulted and the call stays attributed.
This is the practical answer to the capability gap. You do not have to choose between vaulted per-user credentials and the full Exa platform.
Two problems appear once your Exa agent stops being a single-connector demo: the tool surface grows, and nobody can reconstruct what the agent did. Both have infrastructure answers rather than prompting answers.
A standard MCP server exposes everything it has. Give a summarizer agent the full exa connector and it can also create Websets, which is a spend risk it never needed. Virtual MCP servers enforce least privilege at the tool level: you declare which connections and which tools the endpoint exposes, and the agent sees nothing else.
The token math matters too. A server with 40 tools at roughly 200 tokens each burns about 8,000 tokens before the agent does any work; scoping to 5 or 10 tools cuts that overhead by around 80 percent. The fix is not better prompting. It is surface reduction. This is also why understanding what an MCP gateway does matters before you ship a production agent.
You create the server once, not once per user. The response returns a static mcp_server_url you reuse for every session.
The endpoint is static; the identity is not. Before every agent run, confirm the user's connections are active, then mint a short-lived token bound to that user. Never reuse a token across sessions.
One server definition serves every user. No credential sharing between tenants, and no per-user server configuration to maintain.
Exa's own logs know one thing: a key made a request. They do not know which of your customers triggered it or which agent run it belonged to. Scalekit logs every tool call with the identity that authorized it, retained for 90 days and exportable to your SIEM. That is what turns "Exa spend doubled this month" into a query you can answer per tenant, and what lets you show an auditor which user's credential backed a given search. It is also how you catch a revoked key: the connection fails closed on the next call with a clear error, and the event is logged, instead of the agent quietly returning empty results. For an in-depth look at this problem, see agent tool observability: your agent is running, is it actually working?
If your Exa agent is interactive and its job is searching and reading, build on the MCP path. The tool surface is small, Exa maintains the schemas, and the API-key header means it still works headlessly when you need it to.
If your agent schedules recurring searches, builds lists at scale, controls Agent run lifecycles, or needs cost control over search type and extraction, build against the REST API. Those surfaces do not exist in the MCP server and are not going to.
Most production research agents end up using both. The credential layer underneath is identical either way, and that is the part that needs production-grade infrastructure rather than a key in an environment variable.
Working through per-user key isolation, Websets cost control, or Virtual MCP scoping for a multi-tenant research agent? Two ways to reach us.
Join the Scalekit Slack community to compare notes with other agent builders, or talk to an engineer if you want architecture help on a specific deployment.
Browse the Scalekit Exa connector: scalekit.com/connectors/exa
