Exa MCP Server
Exa MCP サーバー 🔍
モデルコンテキストプロトコル(MCP)サーバーにより、ClaudeのようなAIアシスタントはExa AI Search APIを使用してWeb検索を行うことができます。この設定により、AIモデルは安全かつ制御された方法でリアルタイムのWeb情報を取得できます。
デモビデオhttps://www.loom.com/share/ac676f29664e4c6cb33a2f0a63772038?sid=0e72619f-5bfc-415d-a705-63d326373f60
MCPとは何ですか?🤔
モデルコンテキストプロトコル(MCP)は、Claude DesktopのようなAIアプリが外部ツールやデータソースに接続できるようにするシステムです。これにより、AIアシスタントがユーザーの制御を維持しながら、ローカルサービスやAPIを明確かつ安全に操作できるようになります。
Related MCP server: Exa MCP Server
このサーバーは何をしますか?🚀
Exa MCP サーバー:
Exaの強力な検索APIを使用してAIアシスタントがWeb検索を実行できるようにします
タイトル、URL、コンテンツスニペットを含む構造化された検索結果を提供します
レート制限とエラーケースを適切に処理します
前提条件 📋
始める前に、次のものを用意してください。
Node.js (v18以上)
クロードデスクトップがインストール済み
Gitがインストールされている
次のコマンドを実行して、Node.js のインストールを確認できます。
node --version # Should show v18.0.0 or higherインストール 🛠️
NPMのインストール
npm install -g exa-mcp-server鍛冶屋を使う
Smithery経由で Claude Desktop 用の Exa MCP サーバーを自動的にインストールするには:
npx -y @smithery/cli install exa --client claude手動インストール
リポジトリをクローンします。
git clone https://github.com/exa-labs/exa-mcp-server.git
cd exa-mcp-server依存関係をインストールします:
npm install --save axios dotenvプロジェクトをビルドします。
npm run buildグローバル リンクを作成します (これにより、サーバーはどこからでも実行可能になります)。
npm link設定 ⚙️
1. Claude DesktopをExa MCPサーバーを認識するように設定する
claude_desktop_config.json は、Claude Desktop アプリの設定内にあります。
Claude デスクトップ アプリを開き、左上のメニュー バーから開発者モードを有効にします。
有効にしたら、設定(左上のメニューバーから)を開き、開発者向けオプションに移動します。そこに「設定を編集」ボタンがあります。これをクリックすると、claude_desktop_config.jsonファイルが開き、必要な編集を行うことができます。
または(ターミナルからclaude_desktop_config.jsonを開く場合)
macOSの場合:
Claude デスクトップ構成を開きます。
code ~/Library/Application\ Support/Claude/claude_desktop_config.jsonWindowsの場合:
Claude デスクトップ構成を開きます。
code %APPDATA%\Claude\claude_desktop_config.json2. Exa サーバー構成を追加します。
{
"mcpServers": {
"exa": {
"command": "npx",
"args": ["/path/to/exa-mcp-server/build/index.js"],
"env": {
"EXA_API_KEY": "your-api-key-here"
}
}
}
}your-api-key-here dashboard.exa.ai/ api-keys からの実際の Exa API キーに置き換えます。
3. Claude Desktopを再起動します
変更を有効にするには:
Claude Desktopを完全に終了します(ウィンドウを閉じるだけではありません)
Claude Desktopを再度起動します
Exaサーバーが接続されていることを確認するには、🔌アイコンを探してください
使用方法 🎯
設定が完了したら、Claude にウェブ検索を依頼できます。プロンプトの例を以下に示します。
Can you search for recent developments in quantum computing?Search for and summarize the latest news about artificial intelligence startups in new york.Find and analyze recent research papers about climate change solutions.サーバーは次のことを行います。
検索リクエストを処理する
Exa API をクエリする
フォーマットされた結果をClaudeに返す
将来の参照のために検索をキャッシュする
特徴 ✨
ウェブ検索ツール: クロードが自然言語クエリを使用してウェブを検索できるようにします
エラー処理: APIエラーとレート制限を適切に処理します
型安全性: 適切な型チェックを備えた完全な TypeScript 実装
トラブルシューティング🔧
よくある問題
サーバーが見つかりません
npmリンクが正しく設定されていることを確認する
Claude Desktop の設定構文を確認する
Node.jsが正しくインストールされていることを確認する
APIキーの問題
Exa APIキーが有効であることを確認してください
Claude Desktop の設定で API キーが正しく設定されていることを確認します
APIキーの周囲にスペースや引用符がないことを確認してください
接続の問題
Claude Desktopを完全に再起動します
Claude Desktop のログを確認します。
# macOS tail -n 20 -f ~/Library/Logs/Claude/mcp*.log
ヘルプの取得
問題が発生した場合は、 MCPドキュメントを確認してください。
謝辞🙏
強力な検索APIを提供するExa AI
MCP仕様のモデルコンテキストプロトコル
クロード・デスクトップのAnthropic
Available Tools
2 toolsget_code_context_exaARead-onlyIdempotent
Search and get relevant context for any programming task. Exa-code has the highest quality and freshest context for libraries, SDKs, and APIs. Use this tool for ANY question or task for related to programming. RULE: when the user's query contains exa-code or anything related to code, you MUST use this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query to find relevant context for APIs, Libraries, and SDKs. For example, 'React useState hook examples', 'Python pandas dataframe filtering', 'Express.js middleware', 'Next js partial prerendering configuration' | |
| tokensNum | No | Number of tokens to return (1000-50000). Default is 5000 tokens. Adjust this value based on how much context you need - use lower values for focused queries and higher values for comprehensive documentation. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds value by emphasizing 'highest quality and freshest context' and the programming domain focus, but doesn't disclose additional behavioral traits like rate limits, authentication needs, or response format details. No contradiction with annotations exists.
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 core purpose and usage rule, but includes some redundancy (e.g., repeating 'exa-code' emphasis). Sentences are generally purposeful, though the 'RULE' phrasing could be more integrated. Overall efficient but with minor verbosity.
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?
Given the tool's moderate complexity (2 parameters, no output schema), annotations cover safety aspects, and the description provides clear purpose and usage rules. However, it lacks details on response structure or error handling, which would enhance completeness for a search tool.
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 100%, providing full documentation for both parameters. The description doesn't add meaningful parameter semantics beyond what's in the schema, such as explaining query formulation strategies or token usage trade-offs. Baseline score of 3 is appropriate given the comprehensive 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?
The description clearly states the tool's purpose: 'Search and get relevant context for any programming task' with specific focus on 'libraries, SDKs, and APIs.' It distinguishes from the sibling tool 'web_search_exa' by specifying programming-related content, though it doesn't explicitly contrast their differences beyond domain focus.
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 description provides explicit usage guidance: 'Use this tool for ANY question or task related to programming' and includes a mandatory rule: 'when the user's query contains exa-code or anything related to code, you MUST use this tool.' This clearly defines when to use it versus alternatives, though it doesn't specify when NOT to use it for non-programming queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
web_search_exaARead-onlyIdempotent
Search the web using Exa AI - performs real-time web searches and can scrape content from specific URLs. Supports configurable result counts and returns the content from the most relevant websites.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Websearch query | |
| numResults | No | Number of search results to return (default: 8) | |
| livecrawl | No | Live crawl mode - 'fallback': use live crawling as backup if cached content unavailable, 'preferred': prioritize live crawling (default: 'fallback') | |
| type | No | Search type - 'auto': balanced search (default), 'fast': quick results, 'deep': comprehensive search | |
| contextMaxCharacters | No | Maximum characters for context string optimized for LLMs (default: 10000) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it mentions real-time web searches, scraping from specific URLs, configurable result counts, and returning content from relevant websites. This provides useful operational details without contradicting annotations.
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 appropriately sized at two sentences, front-loading the core purpose. Every sentence adds value: the first defines the tool's function, and the second elaborates on features and output. There's no wasted text, though it could be slightly more structured for optimal clarity.
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?
Given the tool's moderate complexity, rich annotations (covering safety and idempotency), and 100% schema coverage, the description is reasonably complete. It explains the tool's function and key features. The lack of an output schema is a minor gap, but the description mentions return content, partially compensating. For a read-only search tool, this provides adequate context.
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 100%, so the schema fully documents all 5 parameters. The description adds minimal parameter semantics beyond the schema, mentioning only 'configurable result counts' (referencing numResults) and 'content from the most relevant websites' (hinting at query relevance). Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
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 clearly states the tool's purpose: 'Search the web using Exa AI - performs real-time web searches and can scrape content from specific URLs.' It specifies the verb (search/scrape) and resource (web/URLs), making the function unambiguous. However, it doesn't explicitly differentiate from its sibling 'get_code_context_exa' beyond mentioning general web search capabilities.
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 description implies usage for web searches and content scraping, but provides no explicit guidance on when to use this tool versus its sibling 'get_code_context_exa' or other alternatives. It mentions configurable result counts and relevance, which suggests some context, but lacks clear when/when-not directives or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
7 tool updates
v1.0.0- Removed
company_research_exa - Removed
crawling_exa - Removed
deep_researcher_check - Removed
deep_researcher_start - Added
get_code_context_exa - Removed
linkedin_search_exa - Changed
web_search_exa5 fields changed- added
Input schema / properties / contextMaxCharactersAdded value: +{ + "description": "Maximum characters for context string optimized for LLMs (default: 10000)", + "type": "number" +} - added
Input schema / properties / livecrawlAdded value: +{ + "description": "Live crawl mode - 'fallback': use live crawling as backup if cached content unavailable, 'preferred': prioritize live crawling (default: 'fallback')", + "enum": [ + "fallback", + "preferred" + ], + "type": "string" +} - changed
Input schema / properties / numResults / descriptionPrevious value: -"Number of search results to return (default: 5)"New value: +"Number of search results to return (default: 8)" - changed
Input schema / properties / query / descriptionPrevious value: -"Search query"New value: +"Websearch query" - added
Input schema / properties / typeAdded value: +{ + "description": "Search type - 'auto': balanced search (default), 'fast': quick results, 'deep': comprehensive search", + "enum": [ + "auto", + "fast", + "deep" + ], + "type": "string" +}
6 tool updates
- First observed
company_research_exa - First observed
crawling_exa - First observed
deep_researcher_check - First observed
deep_researcher_start - First observed
linkedin_search_exa - First observed
web_search_exa
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: get_code_context_exa is specialized for programming-related searches with high-quality code context, while web_search_exa is for general web searches and URL scraping. There is no overlap in functionality, making it easy for an agent to choose the right tool based on the query type.
Both tools follow a consistent naming pattern: they use snake_case and start with a verb (get, search) followed by a noun (code_context, web), with a suffix (_exa) indicating the server. This uniformity makes the tool set predictable and easy to understand.
With only 2 tools, the server feels thin for its apparent scope of providing search capabilities via Exa AI. While the tools cover code-specific and general web searches, the lack of additional tools (e.g., for filtering, advanced queries, or other Exa features) limits functionality and suggests an incomplete surface for a search-oriented server.
The tool set is severely incomplete for a search server. It lacks essential operations such as configuring search parameters beyond result counts, handling pagination, saving or managing search history, or accessing other Exa AI features. This creates significant gaps that could lead to agent failures when more complex search tasks are required.
Maintenance
Related MCP Connectors
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Free web search for AI agents. No API key required. Hosted MCP in active development.
Hosted Web Crawler MCP server for Claude, ChatGPT and Cursor, with each action switched per account.
Related MCP Servers
- AlicenseAqualityBmaintenanceA Model Context Protocol (MCP) server lets AI assistants like Claude use the Exa AI Search API for web searches. This setup allows AI models to get real-time web information in a safe and controlled way.812,601 npm5,159MIT
- AlicenseAqualityCmaintenanceA server that enables AI assistants like Claude to perform web searches using the Exa AI Search API, providing real-time web information in a safe and controlled way.212,601 npmMIT
- AlicenseBqualityCmaintenanceA Model Context Protocol server that enables AI assistants to perform real-time web searches, retrieving up-to-date information from the internet via a Crawler API.145 npm42ISC
- AlicenseAqualityCmaintenanceA Model Context Protocol server that provides real-time web search capabilities to AI assistants through pluggable search providers, currently integrated with the Brave Search API.5246 npm16MIT