exa-mcp-server: a hosted MCP endpoint for web search, fetching and Exa Agent runs
Exa MCP for web search and web crawling!
At a glance
- What is it?
- Exa's MCP server is a remote streamable-http endpoint that gives MCP clients two default tools and three opt-in ones. The interesting design choice is that tool selection happens in the URL, not in a local config file, and the repo itself is mostly packaging for clients that prefer plugins or skills.
- Who is it for?
- Adopt it if you want web search, markdown fetching or Exa Agent runs inside an MCP client without running a local server process, and if you are comfortable sending queries to a third-party endpoint. Do not adopt it if you need offline operation, a pinned local build, or per-tool access control that your client can express without editing the URL.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 26 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem it solves: giving a chat client a search tool it did not ship with
Most MCP clients arrive with a fixed tool set. If you want an agent to search the web, fetch a page as clean markdown, or run a multi-step research job, you either write your own MCP server or you point the client at someone else's. exa-mcp-server is the second option. It is a TypeScript repository whose primary artefact, judging by the README, is a hosted endpoint at https://mcp.exa.ai/mcp rather than a binary you build and run locally. The README's own framing is that it connects AI agents to Exa for web search, content fetching, and multi-step research. The intended user is someone configuring an MCP-capable client (Claude, Codex, Cursor, VS Code, Zed, Windsurf, LM Studio and others are listed) who wants search and fetch capability without maintaining server infrastructure. The repository also carries the agent-plugin and skills layout, so it doubles as a distribution package for clients that install plugins rather than raw MCP entries.
Two default tools, three opt-in ones, and a URL parameter that decides which
The tool surface is small and the split is deliberate. By default the endpoint exposes web_search_exa, described as searching the web for any topic and returning clean, ready-to-use content, and web_fetch_exa, which reads a webpage's full content as clean markdown from one or more URLs. Three more tools exist but are not on by default: agent_run, which runs an Exa Agent for multi-step research, list-building, enrichment and structured output; web_search_advanced_exa, which adds filters, domains, dates, highlights, summaries and subpage crawling; and the agent tool's authentication requirement. The mechanism for turning them on is unusual. You append a tools query parameter to the MCP URL, for example https://mcp.exa.ai/mcp?tools=web_search_advanced_exa. The README is explicit that this replaces the defaults, so a URL listing only web_search_advanced_exa leaves you without web_search_exa and web_fetch_exa. To keep everything you must enumerate it: https://mcp.exa.ai/mcp?tools=web_search_exa,web_fetch_exa,agent_run. This is a real design trade-off. It keeps configuration in one string that any client can hold, but it means the tool list is part of the connection identity, and two clients pointed at differently parameterised URLs are not talking to the same capability set. It also means tool enablement is invisible in the client UI for clients that only show the URL. Exa Agent additionally requires authentication, via OAuth or an API key from the Exa dashboard, so agent_run is not a drop-in addition even after you add it to the URL.
Installation is client-specific and mostly a one-liner
The README gives a standard mcpServers shape for clients that accept manual configuration: a JSON object with an exa entry, type set to streamable-http, and url set to https://mcp.exa.ai/mcp. For specific clients it provides commands. Claude installs from the plugin marketplace or with claude plugin install exa@claude-plugins-official. Codex and ChatGPT install with codex mcp add exa --url https://mcp.exa.ai/mcp. Cursor and VS Code have install badges that encode the same URL. The README also lists where each remaining client keeps its config: ~/.kiro/settings/mcp.json for Kiro, mcp.json for LM Studio, ~/.gemini/settings.json for Gemini CLI, opencode.json for OpenCode, ~/.codeium/windsurf/mcp_config.json for Windsurf, mcp_config.json for Google Antigravity, settings.json under context_servers for Zed, and a settings UI for Warp and v0. Grok Build is installed through /marketplace followed by /mcp to sign in. Two things are worth noting for anyone writing automation around this. First, the README's JSON example contains a trailing comma after the url value, which is invalid JSON in most parsers; copy the structure, not the literal text, if you are generating config programmatically. Second, the repository ships skills in skills/ with two entries, search and exa-agent, which load with Agent Plugin or Claude plugin installs and are invoked from the client's skill UI or as /skill-name. MCP-only setups get the tools without the skills, per the README.
Where the hosted-endpoint model becomes a limitation
Because the server is hosted, everything you send through it leaves your machine and reaches Exa's infrastructure. The README does not describe a self-hosting path, a local build target, or an offline mode, and no release artefacts were retrieved for this repository, so there is no versioned package to pin beyond the npm package name listed in the README's link row. That matters for three cases. First, regulated or air-gapped environments where outbound calls to a third-party search API are not permitted. Second, reproducibility: if the hosted endpoint changes its tool behaviour, your client picks up the change on the next connection, and nothing in the local repository pins it. Third, rate and cost governance. The README points to a dashboard for API keys but does not document quotas, pricing tiers, or what happens when a key is exhausted, so you cannot plan spend from the repository alone. There is a second, subtler failure mode in the URL-parameter scheme. A user who wants advanced search and forgets to re-list the defaults silently loses web_fetch_exa, and the symptom is a missing tool rather than an error. That is the kind of bug that surfaces mid-task, when an agent planned around a fetch step that is no longer available.
How it compares with running your own MCP server
The obvious alternative is a self-hosted MCP server that wraps a search API you already control, or a client-side fetch tool. The difference is not search quality, which this material does not let me assess, but operational shape. A self-hosted server gives you a process you can pin to a commit, log, rate-limit per user, and run inside your network. It also gives you the maintenance: dependency updates, transport compatibility as the MCP specification moves, and the work of exposing tools in the shapes clients expect. exa-mcp-server trades that away. You get a URL, client-specific install commands, and a tool list you can reshape by editing a query string. The repo's own structure reflects this: it is TypeScript, MIT licensed, and ships skills and agent-plugin metadata alongside the MCP configuration, which suggests the project's job is client integration rather than server runtime. If your requirement is a search tool that any colleague can add to their editor in one command, the hosted model wins. If your requirement is an auditable, network-contained tool with a fixed tool inventory, it does not.
Maintenance cost, licence and what the repository does not tell you
The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive arrangement and it applies to the code in this repository; it does not govern the hosted service, which is a separate relationship you establish through an Exa account and API key. Do not read the MIT licence as a statement about data handling or service terms. On maintenance, the practical cost is low for consumers of the hosted endpoint: there is no server to patch, and client configs rarely change. The cost sits with the project's own integration surface, which is wide by necessity. The README lists roughly a dozen clients with different config file locations, and each is a place where a breaking change in a client's MCP support shows up as a support issue. For an adopter, the maintenance question is narrower: how often do you want to re-verify that your client still negotiates streamable-http and still shows the tools you enabled? The material here does not include a changelog, release notes, or a documented compatibility matrix, so that verification is manual. The repository was last pushed in August 2026 and is not archived.
Who should wire this in, and what to check before you do
The fit is an individual engineer or a small team already using an MCP client who wants web search and markdown fetching available to an agent, and who is fine with a remote dependency. The plugin and skill packaging makes it particularly cheap for Claude and Codex users, since the install is a single command and the skills load with it. The misfit is anyone who needs the tool inventory to be fixed and reviewable, anyone whose network policy forbids calls to an external search endpoint, and anyone building a product that would inherit an undocumented availability and pricing dependency. Before adopting, check three concrete things. Open your client's MCP config and confirm it accepts type streamable-http rather than only stdio. Decide your full tool list in advance and write the complete tools parameter, remembering that it replaces the defaults. And if you intend to use agent_run, confirm your authentication route, either OAuth or an API key from the dashboard, because the README states the Exa Agent requires it. If those three checks pass, the setup is a URL and a restart. If any of them fails, the honest answer is that you want a self-hosted server instead.
Editorial conclusion
Adopt it if you want web search, markdown fetching or Exa Agent runs inside an MCP client without running a local server process, and if you are comfortable sending queries to a third-party endpoint. Do not adopt it if you need offline operation, a pinned local build, or per-tool access control that your client can express without editing the URL. Before wiring it into anything shared, verify two things: whether your client supports streamable-http, and what happens to your default tools when you append the tools parameter, since the README states the parameter replaces the defaults rather than adding to them.
Community notes