Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-exa search the web for recent AI news about MCP servers"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server to give client the ability to connect to Exa
cp .env.example .env # then fill in EXA_API_KEY
uv syncThe server starts without a key; tools return a setup error until EXA_API_KEY is set.
Register it in an MCP client (e.g. Claude Desktop):
{
"mcpServers": {
"exa": {
"command": "uv",
"args": ["--directory", "/path/to/mcp-exa", "run", "main.py"]
}
}
}Related MCP server: Exa MCP Server
exa_search: web search with highlights or full text; filters for category
(company, news, publication, people, ...), domains, and published-date range
exa_get_contents: read known URLs, optionally only the passages relevant to a query
exa_deep_search: multi-step search that synthesizes a cited answer, as text or
shaped by a JSON Schema (output_schema)
exa_research_start / exa_research_get: Exa's research agent for lists and reports.
Runs take minutes, so start returns a run_id and get waits up to 50 seconds per call
The free tier gives $10 of credits per month. Every response includes cost_dollars.
Roughly: instant search $4/1k, auto/fast $7/1k (+$1/1k per result above 10),
deep search $12–15/1k, contents $1/1k pages; research runs cost the most. To keep one call
from draining the budget, the server caps results at 25, URLs at 10 per call, and research
effort at medium.
Multi-step Exa search that synthesizes an answer with citations. Costs ~2x a normal search.
Args:
query: The question to answer (e.g., "Who is Braincore Indonesia's CEO and where is it based?")
output_schema: Optional JSON Schema for a structured answer, e.g.
{"type": "object", "required": ["ceo"], "properties": {"ceo": {"type": "string"}}}.
Without it the answer is plain text.
type: "deep-lite" (cheapest), "deep" (default) or "deep-reasoning" (most thorough)
num_results: Number of source results to return alongside the answer (1-25, default: 10)
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | deep | |
| query | Yes | ||
| num_results | No | ||
| output_schema | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does reasonably well: it discloses the multi-step nature, citation output, the ~2x cost, that output_schema yields structured answers versus plain text otherwise, and the num_results range. Missing are latency expectations and whether calls are billable/rate-limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the one-line essence, followed by a compact Args block. The query and output_schema examples are slightly verbose but each earns its place by making the format concrete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be detailed, and the description still notes that results are returned alongside the answer. All four sparse-schema parameters are covered; the only real gap is guidance against sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate and it does: every parameter is explained, including the exact enum values for type, the 1-25 range and default for num_results, and a concrete JSON example for output_schema clarifying the plain-text fallback.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Multi-step Exa search that synthesizes an answer with citations.' The '~2x a normal search' cost note implicitly contrasts it with exa_search, but no sibling is named, so differentiation requires inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied via the cost note and the type tiers ('cheapest' / 'default' / 'most thorough'), which guide mode selection but not tool selection. There is no statement of when to prefer this over exa_search or exa_research_start.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the content of known web pages through Exa (handles JS-heavy and blocked sites).
Args:
urls: Page URLs to read (max 10)
highlight_query: Optional; return only the passages relevant to this query
instead of the full text (e.g., "IEEE papers")
max_characters: Max characters of text per page when no highlight_query (default: 5000)
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | ||
| max_characters | No | ||
| highlight_query | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It usefully notes that the tool handles JS-heavy and blocked sites and that highlight_query changes the return from full text to relevant passages; however, it omits auth requirements, rate limits, error behavior, and explicit read-only safety, leaving the behavioral picture incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, then lists three parameters in a compact Args block. It wastes little space, though the Args formatting is slightly mechanical; overall it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values, and it covers purpose, all parameters, and key capabilities. It leaves out auth/rate-limit context and explicit read-only signaling, but for a straightforward content-fetch tool it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full parameter burden. It does so thoroughly: it states urls accepts up to 10 page URLs, explains that highlight_query returns only relevant passages instead of full text (with an example), and clarifies that max_characters applies only when no highlight_query is given, plus its 5000 default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Read the content of known web pages') and distinguishes the tool from search siblings by specifying 'known' pages and noting JS-heavy/blocked site handling. It does not explicitly name an alternative, but the scope is clear enough for an agent to select it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage ('known web pages') but offers no explicit when-to-use guidance, no prerequisites, and no named alternatives among exa_search, exa_deep_search, etc. An agent can infer it is for URLs already in hand, but the description stops short of actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the status and result of a research run started with exa_research_start.
Args:
run_id: The run_id returned by exa_research_start
wait_seconds: Wait up to this long for the run to finish before returning (0-50, default: 30)
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes | ||
| wait_seconds | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the non-obvious blocking/polling behavior (waits up to wait_seconds for completion before returning), which is genuinely useful, but says nothing about auth, error behavior, or what is returned when the run is still incomplete after the wait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose sentence followed by a compact Args block; there is minor redundancy in repeating exa_research_start twice, but no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the polling semantics are covered. The remaining meaningful gap is what happens when the run has not finished within wait_seconds (partial status vs. timeout error), which an agent needs to branch on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does: run_id is explained as the identifier returned by exa_research_start, and wait_seconds is defined as the pre-return wait with its 0-50 range. It stops short of describing run_id's format or the consequence of hitting the wait limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: retrieving the status and result of a research run. It explicitly ties itself to the sibling exa_research_start as the originating call, so an agent can place it in the async research lifecycle without reading either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The pairing with exa_research_start makes the usage context clear (call this after starting a run to poll/collect it). It gives no explicit when-not conditions or timeout-handling guidance, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an Exa research agent for open-ended tasks (building lists, analyzing a topic
across many sources). Runs take minutes, so this returns a run_id right away;
fetch the result with exa_research_get. This is the most expensive Exa tool.
Args:
query: The research task (e.g., "Find 10 AI consultant companies in Indonesia")
output_schema: Optional JSON Schema for a structured result; without it the result is a report
effort: "minimal", "low" (default), "medium" or "auto"
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| effort | No | low | |
| output_schema | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the async pattern (returns run_id immediately), latency ('runs take minutes'), and relative cost. It omits failure/retry behavior and any auth or rate-limit context, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose, then the async/cost caveat, then a compact Args block. Every sentence adds signal and nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an async tool with an output schema, it covers what an agent needs: purpose, the run_id/fetch handoff, cost, and all three parameters. It stops short only on failure handling and the practical meaning of effort levels.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it does: query is explained with a concrete example, output_schema is described behaviorally (structured result vs. a report when omitted), and effort's enum values including the default are listed even though the schema lacks them. Minor gaps remain (e.g., cost/quality tradeoff between effort levels).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (start an Exa research agent) and scopes it to open-ended tasks like building lists or analyzing a topic across sources. It explicitly routes the async result retrieval to the sibling exa_research_get and flags cost relative to other tools, so an agent can distinguish it from exa_search/exa_deep_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states the context for use ('open-ended tasks') and gives the follow-up path via exa_research_get, plus a cost warning ('most expensive Exa tool'). It does not explicitly say when NOT to use it in favor of exa_search or exa_deep_search, so the exclusion guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web with Exa and return ranked results with page content.
Args:
query: Natural-language search query (e.g., "AI consultant companies in Indonesia")
num_results: Number of results (1-25, default: 10; each result above 10 costs extra)
type: "auto" (default), "fast", "instant" (cheapest) or "neural"
category: Optional focus: "company", "news", "publication", "personal site",
"financial report" or "people"
include_domains: Only return results from these domains (e.g., ["arxiv.org"])
exclude_domains: Never return results from these domains
start_published_date: Only results published on/after this date (YYYY-MM-DD)
end_published_date: Only results published on/before this date (YYYY-MM-DD)
content: "highlights" (default, relevant snippets), "text" (full page text) or "none"
max_characters: Max characters of page text per result when content="text" (default: 3000)
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | auto | |
| query | Yes | ||
| content | No | highlights | |
| category | No | ||
| num_results | No | ||
| max_characters | No | ||
| exclude_domains | No | ||
| include_domains | No | ||
| end_published_date | No | ||
| start_published_date | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does add genuine behavioral context with the cost signal ('each result above 10 costs extra') and the default content mode, but says nothing about auth/API key requirements, rate limits, latency differences between search types, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads a one-line purpose, then a tight docstring-style arg list where each line earns its place. No filler, though the block is long by necessity given 10 undocumented parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and all input parameters plus cost implications are covered. The only real gap is sibling disambiguation and any auth/rate-limit context, which matters for a search tool with several near-neighbor variants.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must do all the work, and it does: every one of the 10 parameters gets meaning, valid values, defaults, ranges, or an example (query, num_results 1-25 + cost, type enum with cost ranking, category enum, include/exclude domains with examples, YYYY-MM-DD date formats, content modes, max_characters default). This is a strong compensation for an otherwise bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search the web with Exa') plus the output shape ('ranked results with page content'), which is enough to distinguish it from the content-fetching sibling. However, it never contrasts itself with exa_deep_search or exa_research_start, so an agent must guess which search variant fits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is implied rather than stated: 'instant (cheapest)' and the cost note on num_results help pick values, but there is no explicit when-to-use-this-tool-vs-siblings statement or prerequisite/exclusion guidance. The agent is left to infer that deep/research siblings handle heavier cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0exa_deep_searchexa_get_contentsexa_research_getexa_research_startexa_searchScored across 5 tools
exa_search, exa_deep_search, and exa_research_start all perform search-like operations, so there is some conceptual overlap. However, the descriptions clearly differentiate them: ranked results vs. synthesized answer with citations vs. long-running research agent, which helps an agent choose correctly.
All tools use a consistent exa_ prefix and snake_case. Minor deviation: exa_search and exa_deep_search are noun-style while exa_get_contents, exa_research_start, and exa_research_get follow verb_noun, but the pattern remains readable and predictable.
Five tools is well-scoped for a web search and research server, with each tool earning its place (search, read, synthesize, async start, async poll). No redundancy or padding.
The surface covers the full search lifecycle: ranked search, page reading, synthesized answers, and async research with status polling. Minor gap: no find-similar/lookup-by-URL tool that Exa typically offers, but core workflows are covered.
Connect AI agents to Exa for web search, content fetching, and multi-step research.
Live AI-native web search with citations. One tool for every MCP client. Flat per-request pricing.
Exa MCP — neural/semantic web search + content retrieval (exa.ai)
Your agent needs the open web — searched by more than one engine, and read as clean markdown rather than raw HTML. **What you can ask for** • "Search this question with two providers and tell me where they disagree." • "Scrape these 40 URLs into markdown, in one batch." • "Crawl this documentation site and give me every page." • "Do deep research on this topic and cite the sources." • "Find the academic papers behind this claim." **How to use it** Point any MCP client at https://mcp.aisa.one/search/mcp and sign in with OAuth — there is no key to create or paste. 30 tools across several independent providers: Tavily and Exa search, answers, contents and agent runs; Firecrawl scrape, batch scrape, crawl, map and search; Perplexity Sonar, Sonar Pro, reasoning and deep research; Oxylabs AI search and LLM jobs; OpenAI and Anthropic web search; and scholarly search. **Why this rather than the source** Several independent indexes behind one account, because one engine's blind spot is not visible from inside it. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Find the page here, then ask the same agent who links to it or how much traffic it gets — without adding a second server. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** https://mcp.aisa.one/seo-serp/mcp for the Google results page itself, https://mcp.aisa.one/seo-serp-other-engines/mcp for Bing, Baidu and Naver.
