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: Perplexity 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プロジェクトをビルドします。
npm run buildグローバル リンクを作成します (これにより、サーバーはどこからでも実行可能になります)。
npm link設定 ⚙️
1. Claude DesktopをExa MCPサーバーを認識するように設定する
claude_desktop_config.json は、Claude デスクトップ アプリの設定内にあります。
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.Search for today's breaking news about tech.Search for the top 10 AI research papers from 2023, and only use live crawling as a fallback.Search for electric vehicles and return 3 results, always using live crawling.サーバーは次のことを行います。
検索リクエストを処理する
最適な設定でExa APIをクエリする(ライブクロールを含む)
フォーマットされた結果をClaudeに返す
将来の参照のために検索をキャッシュする
特徴 ✨
簡素化されたWeb検索ツール: クエリパラメータだけでClaudeがWebを検索できるようにします
カスタマイズ可能な検索パラメータ: 結果の数とライブクロール戦略を制御
自動ライブクロール:指定された戦略に基づいてリアルタイムクロールを使用します
最適なパラメータをプリセット: 結果数と文字数制限に最適なデフォルトを使用します
検索キャッシュ:最近の検索を参照用のリソースとして保存します
エラー処理: APIエラーとレート制限を適切に処理します
型安全性: Zod 検証を備えた完全な TypeScript 実装
MCP準拠:最新のMCPプロトコル仕様を完全に実装
MCP Inspector を使ったテスト 🔍
MCP Inspector を使用してサーバーを直接テストできます。
npx @modelcontextprotocol/inspector node ./build/index.jsこれにより、サーバーの機能を調べたり、検索クエリを実行したり、キャッシュされた検索結果を表示したりできるインタラクティブなインターフェースが開きます。
トラブルシューティング🔧
よくある問題
サーバーが見つかりません
npmリンクが正しく設定されていることを確認する
Claude Desktop の設定構文を確認する
Node.jsが正しくインストールされていることを確認する
APIキーの問題
EXA_API_KEYが有効であることを確認してください
Claude Desktop の設定で EXA_API_KEY が正しく設定されていることを確認します。
APIキーの周囲にスペースや引用符がないことを確認してください
接続の問題
Claude Desktopを完全に再起動します
Claude Desktop のログを確認する: GXP18
ヘルプの取得
問題が発生した場合は、 MCP ドキュメントを確認するか、 GitHub のディスカッションにアクセスしてコミュニティ サポートを受けてください。
謝辞🙏
強力な検索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 a general web search tool for broader queries. There is no overlap in functionality, making it easy for an agent to choose the correct tool based on the query content.
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). The pattern is uniform across the set, with no deviations in style or structure.
With only 2 tools, the server feels thin for a general-purpose search domain, as it might lack coverage for intermediate or specialized tasks beyond code and web searches. However, the tools are well-defined, so it's borderline but not severely mismatched.
The server covers two key search domains (code and web), but there are notable gaps: it lacks tools for other common search types (e.g., image, news, academic) or advanced operations like filtering or saving results. This could limit agent effectiveness in broader search scenarios.
Maintenance
Related MCP Connectors
Connect AI agents to Exa for web search, content fetching, and multi-step research.
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
Give AI assistants access to real-time data. Search the web, compare flights, find hotels, and more.
The best web search for your AI Agent
Related MCP Servers
- AlicenseAqualityCmaintenanceA 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.822,768 npm5,048MIT
- AlicenseBqualityFmaintenanceA server facilitating web search functionality by utilizing Perplexity AI's API, designed to integrate with the Claude desktop client for enhanced search queries.1307MIT
- FlicenseAqualityDmaintenanceA Model Context Protocol server that enables AI assistants like Claude to perform real-time web searches using the Exa AI Search API in a safe and controlled manner.222,768 npm-
- AlicenseBqualityDmaintenanceA server that integrates with Claude Desktop to enable real-time web research capabilities, allowing users to search Google, extract webpage content, and capture screenshots directly from conversations.31,229 npmMIT