模型上下文协议 (MCP) 服务器允许像 Claude 这样的 AI 助手使用 Exa AI Search API 进行网页搜索。此设置允许 AI 模型以安全可控的方式获取实时网页信息。
演示视频https://www.loom.com/share/ac676f29664e4c6cb33a2f0a63772038?sid=0e72619f-5bfc-415d-a705-63d326373f60
模型上下文协议 (MCP) 是一个允许 AI 应用（例如 Claude Desktop）连接到外部工具和数据源的系统。它为 AI 助手提供了一种清晰、安全的方式，使其能够使用本地服务和 API，同时保持用户的控制权。
Related MCP server: Exa MCP Server
Exa MCP 服务器：
使 AI 助手能够使用 Exa 强大的搜索 API 执行网络搜索
提供结构化的搜索结果，包括标题、URL 和内容片段
优雅地处理速率限制和错误情况
在开始之前，请确保您已：
Node.js （v18 或更高版本）
Git 安装
您可以通过运行以下命令来验证您的 Node.js 安装：
node --version # Should show v18.0.0 or highernpm 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您可以在 Claude Desktop 应用程序的设置中找到 claude_desktop_config.json：
打开 Claude 桌面应用程序并从左上角的菜单栏启用开发者模式。
启用后，打开“设置”（也可以从左上角的菜单栏中打开），然后导航到“开发者选项”，在那里你会找到“编辑配置”按钮。点击它将打开 claude_desktop_config.json 文件，允许你进行必要的编辑。
或者（如果您想从终端打开 claude_desktop_config.json）
打开您的 Claude Desktop 配置：
code ~/Library/Application\ Support/Claude/claude_desktop_config.json打开您的 Claude Desktop 配置：
code %APPDATA%\Claude\claude_desktop_config.json{
"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 密钥。
要使更改生效：
完全退出 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
缓存搜索以供将来参考
网络搜索工具：使 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 文档
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. |
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.
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) |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0company_research_exacrawling_exadeep_researcher_checkdeep_researcher_startget_code_context_exalinkedin_search_exaweb_search_exa5 fields changedInput schema / properties / contextMaxCharactersAdded value: +{
+ "description": "Maximum characters for context string optimized for LLMs (default: 10000)",
+ "type": "number"
+}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"
+}Input schema / properties / numResults / descriptionPrevious value: -"Number of search results to return (default: 5)"New value: +"Number of search results to return (default: 8)"Input schema / properties / query / descriptionPrevious value: -"Search query"New value: +"Websearch query"Input schema / properties / typeAdded value: +{
+ "description": "Search type - 'auto': balanced search (default), 'fast': quick results, 'deep': comprehensive search",
+ "enum": [
+ "auto",
+ "fast",
+ "deep"
+ ],
+ "type": "string"
+}company_research_exacrawling_exadeep_researcher_checkdeep_researcher_startlinkedin_search_exaweb_search_exaScored 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.
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.