Skip to main content
Glama
Sign In
chocowarsky

Exa Ultra MCP

by chocowarsky
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Exa web search

exa_search

Search the live web and get ranked pages with query-relevant highlights. Control search depth via fast/auto/max modes, enforce domain or date filters, and extract structured fields from results.

Instructions

Search the live web with Exa; returns ranked pages with query-relevant highlights (10 results). Search type comes from the mode unless you set type: fast = lite (<1 s) · auto = auto (~2 s) · max = deep-reasoning (7-20 s, best quality). See exa_mode for the current server mode. Put recency and source preferences in the query text; use filters only when they must be enforced. Use outputSchema (+ systemPrompt for keep/drop rules) to get fields extracted from the pages.

Input Schema

NameRequiredDescriptionDefault
rawNoAlso return the full Exa JSON in structuredContent. Costs many tokens.
modeNoQuality preset for this call: fast (lite search, cheapest agent) · auto (Exa standard) · max (highest free-plan quality). Default: the server mode (see exa_mode). An explicit type/effort wins.
typeNoOverrides the mode. deep-reasoning = strongest · deep = several searches, wide schemas · deep-lite · auto · lite = fastest, cached only.
linksNoReturn up to N links found on each page.
queryYesWhat to retrieve, phrased like a search box entry.
contentNoPage content to return. Pick one. highlights = short query-relevant excerpts (fewest tokens).
noCacheNoSkip the local cache.
categoryNoOnly when results must come from that index. Not for list-building (use exa_agent_run).
maxCharsNoCap on the text returned to you (default 8000).
subpagesNoAlso crawl up to N linked subpages per result.
objectiveNoThe larger goal this search serves: what should rank first, what to exclude, which facts to pull.
imageLinksNoReturn up to N image URLs per page.
numResultsNoDefault 10. Results above 10 cost $0.001 each.
excludeTextNoPages must not contain this phrase (1 phrase, up to 5 words).
includeTextNoPages must contain this phrase (1 phrase, up to 5 words).
maxAgeHoursNoCache freshness: 0 = always live crawl, -1 = cache only, N = accept cache up to N hours. Not a publish-date filter.
outputSchemaNoJSON Schema for synthesized output in output.content. Keep it small.
snapshotAsOfNoExa Snapshot: the page as it was at this ISO date-time. Paid plans only. Not with maxAgeHours/livecrawlTimeout/subpages.
summaryQueryNoWhat the per-page summary should focus on (summary mode; one LLM call per page).
systemPromptNoRules for synthesized output: keep/drop, source preference, what to do with unverifiable fields.
userLocationNoTwo-letter ISO country code, e.g. ID.
maxCharactersNoPer-page cap for text or highlights. Only for a hard budget.
subpageTargetNoKeywords that pick which subpages to crawl, e.g. 'pricing' or ['docs','api'].
summarySchemaNoJSON Schema for a structured per-page summary (summary mode).
excludeDomainsNoHard blocklist.
includeDomainsNoHard allowlist, e.g. ['openai.com/blog','*.substack.com'].
highlightsQueryNoSteer which excerpts are picked (highlights mode).
endPublishedDateNo
livecrawlTimeoutNoLive crawl timeout in ms.
startPublishedDateNoHard filter; drops undated pages. Only for a stated date window.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden, and it does well: it discloses latency per mode (fast <1s, auto ~2s, max 7-20s) and the default of 10 results. It omits auth/plan constraints (e.g. snapshotAsOf is paid-only, noted only in the schema) and caching behavior beyond a pointer.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense paragraph that front-loads what the tool returns and then layers mode guidance and filter advice. Every sentence carries information, though the inline mode latency list partially duplicates the `mode` enum description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 30-parameter tool with no output schema, the description covers the highest-leverage decisions: mode/type selection, content mode, filter discipline, and structured extraction via outputSchema. Per-parameter details like numResults defaults, raw, subpages, and snapshot constraints are left to the schema, which documents them at 97% coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 97%, so baseline is 3; the description still adds value by explaining the mode-vs-type precedence ('Search type comes from the mode unless you set `type`') and by advising that filters be reserved for enforced constraints rather than soft preferences. It also explains the outputSchema/systemPrompt pairing for extracted fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource: 'Search the live web with Exa; returns ranked pages with query-relevant highlights (10 results)', which also states the default result shape. It does not explicitly contrast itself with siblings like exa_answer, exa_find_similar, or exa_contents, so differentiation relies on names rather than the description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives real steering: 'Put recency and source preferences in the query text; use filters only when they must be enforced' and points to exa_mode for the current server mode. It lacks an explicit statement of when to prefer exa_answer or exa_find_similar over this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools