Click on "Install 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., "@Exa Websets MCP Server create a webset about recent AI breakthroughs and summarize key findings"
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.
A Model Context Protocol (MCP) server that provides Exa AI's websets management capabilities and web search functionality to AI assistants like Claude. This simplified server focuses on comprehensive content collection management through an intuitive interface.
This MCP server provides three essential tools and seven agentic prompts:
websets_manager: A comprehensive tool for managing content collections, searches, and data enhancements
web_search_exa: Real-time web search capabilities powered by Exa AI
websets_guide: Helpful guidance and examples for using websets effectively
knowledge_graph: Maintain connections between webset results in an onboard graph
Interactive workflows to guide you through websets operations:
list_mcp_assets: Comprehensive list of all server capabilities
quick_start: Get started quickly with creating your first webset
webset_discovery: Discover and explore available websets
webset_status_check: Monitor async webset operations with guided instructions
webset_analysis_guide: Step-by-step guide for analyzing completed websets
webhook_setup_guide: Configure webhooks for real-time notifications
enrichment_workflow: Detailed workflow for enriching webset data with AI
horizontal_process: Advanced workflow for creating multiple websets and building meta-datasets from cross-matches
webset_portal: Deep-dive parallel research through webset URLs using Claude Code subagents
iterative_intelligence: Self-improving research system with webset registry for fast retrieval and batch processing
Simplified: Just 3 tools instead of 20+ individual ones
Comprehensive: The websets_manager handles all 20 websets operations in one tool
Guided: Agentic prompts provide step-by-step workflows for complex operations
Fast: No dynamic tool loading - all tools are immediately available
Reliable: 100% operational coverage with graceful error handling
Smart Pagination: Automatic handling of large responses to prevent token overflow
Auto-Polling: Optional automatic polling for async operations (search, enhance)
Related MCP server: Exa Websets MCP Server
Connect directly to Exa's hosted MCP server (instead of running it locally).
https://mcp.exa.ai/websets?exaApiKey=your-exa-api-keyReplace your-api-key-here with your actual Exa API key from dashboard.exa.ai/api-keys.
Add this to your Claude Desktop configuration file:
{
"mcpServers": {
"exa-websets": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://mcp.exa.ai/websets?exaApiKey=your-exa-api-key"
]
}
}
}npm install -g exa-websets-mcp-serverTo install the Exa Websets MCP server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install exa-websets --client claudeYou can find claude_desktop_config.json inside the settings of Claude Desktop app:
Open the Claude Desktop app and enable Developer Mode from the top-left menu bar.
Once enabled, open Settings (also from the top-left menu bar) and navigate to the Developer Option, where you'll find the Edit Config button. Clicking it will open the claude_desktop_config.json file, allowing you to make the necessary edits.
OR (if you want to open claude_desktop_config.json from terminal)
code ~/Library/Application\ Support/Claude/claude_desktop_config.jsoncode %APPDATA%\Claude\claude_desktop_config.json{
"mcpServers": {
"exa-websets": {
"command": "npx",
"args": ["-y", "exa-websets-mcp-server"],
"env": {
"EXA_API_KEY": "your-api-key-here"
}
}
}
}Replace your-api-key-here with your actual Exa API key from dashboard.exa.ai/api-keys.
To configure this MCP server with Claude Code, use the following command:
# Install server locally first
npm install -g exa-websets-mcp-server
# Add to Claude Code with environment variable
claude mcp add exa-websets -e EXA_API_KEY=your-api-key-here -- npx exa-websets-mcp-server
# Or if you have built the project locally:
claude mcp add exa-websets -e EXA_API_KEY=your-api-key-here -- node /path/to/exa-websets-mcp-server/build/index.jsAfter adding the server, you can check its status with:
claude mcp listUse the /mcp command within Claude Code to verify the server is connected.
For the changes to take effect:
Completely quit Claude Desktop (not just close the window)
Start Claude Desktop again
Look for the icon to verify the Exa Websets server is connected
The unified websets manager provides a single interface for all websets operations:
# Create a new content collection
operation: create_collection
collection: { searchQuery: "AI news", description: "Latest AI developments" }
# Search within a collection
operation: search_collection
resourceId: "collection-id"
search: { query: "breakthrough", maxResults: 10 }
# Enhance content with AI
operation: enhance_content
resourceId: "collection-id"
enhancement: { task: "Extract key findings from each article" }Perform real-time web searches:
query: "latest AI developments"
numResults: 10Get help and examples for using websets:
topic: "getting_started"Available topics:
getting_started
creating_collections
searching_content
enhancing_data
setting_notifications
workflow_examples
troubleshooting
best_practices
Prompts provide interactive workflows that guide you through complex websets operations. They're especially useful for:
Understanding the asynchronous nature of websets
Learning best practices for different use cases
Getting step-by-step instructions with example commands
To use a prompt in Claude, simply mention it:
"Use the quick_start prompt to help me create my first webset"
"Show me the webset_status_check for webset_abc123"
The server automatically handles large responses to prevent token overflow:
// List activities - automatically paginated if no limit specified
operation: "list_activities"
// Returns manageable chunks that fit within token limits
// Or specify your own limit if you know what you need
operation: "list_activities"
query: { limit: 5 }How it works:
If you don't specify a limit, the server automatically paginates results
Starts with small batches and adjusts based on response size
Prevents "response too large" errors from MCP clients
Works for activities, websets, and content items
Search and enhancement operations can now wait for results automatically:
// Search with automatic polling (waits up to 1 minute)
operation: "search_webset"
resourceId: "webset_123"
search: {
query: "AI startups",
advanced: {
waitForResults: true // Enable auto-polling
}
}
// Enhancement with automatic polling (waits up to 2 minutes)
operation: "enhance_content"
resourceId: "webset_123"
enhancement: {
task: "Extract company names and funding",
advanced: {
waitForResults: true // Enable auto-polling
}
}Polling intervals:
Search: Checks every 2 seconds for up to 1 minute
Enhancement: Checks every 3 seconds for up to 2 minutes
No exponential backoff - predictable, reasonable intervals
Progress updates logged during polling
When to use:
Enable waitForResults when you need results immediately
Disable it (default) when running batch operations
Polling stops as soon as operation completes or fails
"Guide me through enrichment_workflow for my completed webset"
Each prompt provides contextual guidance, example commands, and best practices tailored to your specific situation.
Run the server directly with npx:
# Run the websets server
npx exa-websets-mcp-serverServer Not Found
Verify the npm package is correctly installed
Check Claude Desktop configuration syntax (json file)
API Key Issues
Confirm your EXA_API_KEY is valid
Check the EXA_API_KEY is correctly set in the configuration
Verify no spaces or quotes around the API key
Connection Issues
Restart Claude Desktop completely
Check Claude Desktop logs for error messages
Events API Unavailable
The events endpoint may return 500 errors
Use webhooks for event notifications instead
Monitor webset status through get_collection_status
Added automatic pagination for large responses to prevent token overflow
Implemented optional auto-polling for async operations (search, enhance)
Added waitForResults option for immediate results from async operations
Improved activity list handling with smart pagination
Added progress logging during polling operations
No exponential backoff - uses predictable, reasonable polling intervals
Added stdio transport support for local MCP connections
Fixed server startup for both Claude Desktop and Smithery deployments
Improved compatibility with Claude Code
Enhanced error handling and security checks
Added comprehensive prompt system with 10 interactive workflows
Improved package metadata for npm publishing
Fixed keep-alive mechanism to prevent connection timeouts
Now sends MCP logging messages to maintain stdio connection
Prevents Claude Desktop disconnections during idle periods
Fixed authentication header from 'Authorization: Bearer' to 'x-api-key'
Resolved network errors in websets operations
All tools now work correctly with Smithery deployment
Initial release with simplified architecture
Three essential tools: websets_manager, web_search_exa, websets_guide
100% operational coverage for all websets operations
Built with ❤️ by team Exa
Maintain an onboard knowledge graph of webset results.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | ||
| entities | No | ||
| relations | No | ||
| observations | No | ||
| deletions | No | ||
| names | No | ||
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as side effects, authorization requirements, or that the tool performs multiple mutation and query operations. The single sentence provides no insight beyond the tool's purpose.
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 extremely concise (one sentence), but this brevity sacrifices essential information. It lacks structure, such as bullet points or sections, and fails to earn its place by omitting critical details about operations and 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?
For a complex tool with 7 parameters, 9 enum operations, and no output schema, the description is grossly inadequate. It provides no information on return values, error handling, or how to use the diverse operations, leaving significant gaps.
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%, and the description adds no information about any of the seven parameters. Properties like 'operation' (with 9 enum values) and others are left entirely to schema names, which are insufficient for correct usage.
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 'Maintain an onboard knowledge graph of webset results' is vague. It uses the generic verb 'maintain' without specifying the broad set of operations (create, delete, read, search, etc.) evident in the input schema. It does not differentiate the tool from siblings or clarify what 'webset results' are.
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?
No guidance is provided on when to use this tool versus its siblings (web_search_exa, websets_guide, websets_manager). There is no mention of appropriate contexts, prerequisites, or alternative tools, leaving the agent without decision support.
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 | Search query | |
| numResults | No | Number of search results to return (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses real-time searching and scraping but lacks details on authentication, rate limits, or behavior when no results. The description is adequate but not comprehensive.
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 two sentences, no fluff, covering the main behavioral aspects. It is well-structured but could be slightly more organized (e.g., separate lines). Still, it is efficient.
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 a 2-parameter tool with no output schema or annotations, the description covers primary functionality and return content. However, it omits details like scraping mechanics, error handling, and data freshness. Adequate but not fully 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 coverage is 100%, so baseline is 3. The description adds 'configurable result counts' (aligning with numResults) and mentions scraping, which is not reflected in parameters. Some extra context but not significantly beyond 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 performs real-time web searches using Exa AI and can scrape content from specific URLs. It distinguishes itself from sibling tools (knowledge_graph, websets_guide, websets_manager) which are not general web search tools, making purpose unambiguous.
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 this is the general web search tool but does not explicitly state when to use it versus alternatives like knowledge_graph or websets_guide. No when-not-to-use or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get helpful guidance, examples, and workflows for using Exa's content websets effectively. Learn how to create websets, search content, enhance data, and set up notifications with practical examples.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | What you'd like guidance on |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as whether the tool is read-only, requires authentication, or what the output format is. Only basic purpose is stated.
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 two sentences, efficiently stating purpose and listing topics. No verbose or irrelevant content, though the topic list is somewhat redundant with the schema.
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 a simple guidance tool with one enum parameter and no output schema, the description covers the purpose and available topics but lacks details on return format, usage context, or behavioral constraints. Could be more informative.
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 100% with a single parameter 'topic' having a description. The description lists topics that mirror the enum values but adds no new meaning beyond the schema. Baseline 3 applies.
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 provides guidance, examples, and workflows for using websets. It uses a specific verb 'Get' and resource 'guidance', and distinguishes from siblings like websets_manager (management) and web_search_exa (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?
The description implies usage when you need guidance on websets, but does not explicitly state when to use this tool vs alternatives or provide exclusions. Lacks comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage content websets, searches, and data enhancements using Exa's platform. This single tool handles creating websets of web content, searching within them, enhancing data with AI, and setting up notifications. Much simpler than using separate tools for each operation.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | What you want to do | |
| resourceId | No | ID of the webset, search, or enhancement to work with | |
| webset | No | ||
| search | No | ||
| enhancement | No | ||
| notification | No | ||
| update | No | ||
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as sync/async nature, permissions, rate limits, or side effects. Minimal disclosure.
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 short (3 sentences) and front-loads the purpose. No unnecessary words, but could benefit from structured formatting like bullet points.
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?
The tool is complex with many operations and nested parameters, but the description provides no details on how to use specific parameters or operations. Extremely incomplete for the tool's complexity.
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?
The description does not explain any parameters; it only offers a high-level overview. With schema description coverage at 25%, the description fails to add meaning beyond the limited 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 manages websets, searches, enhancements, and notifications via Exa. It lists multiple operations, making the purpose clear, though it does not explicitly differentiate from siblings.
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 mentions it's simpler than using separate tools, but provides no explicit when-to-use or when-not-to-use guidance, nor comparison to sibling tools like knowledge_graph or web_search_exa.
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. Dates show when Glama detected each change.
v1.0.0knowledge_graph2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseweb_search_exa2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsewebsets_guide2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsewebsets_manager2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseknowledge_graphweb_search_exawebsets_guidewebsets_managerScored across 4 tools
The tools have overlapping purposes that create ambiguity. The 'websets_manager' tool claims to handle creating websets, searching within them, enhancing data, and setting up notifications, which directly overlaps with the functions described in 'websets_guide' (guidance on creating websets, searching content, enhancing data, and setting up notifications) and partially with 'web_search_exa' (searching). This makes it difficult for an agent to choose between them without confusion.
The naming conventions are mixed and not fully consistent. 'knowledge_graph' and 'web_search_exa' use snake_case, while 'websets_guide' and 'websets_manager' use a descriptive but inconsistent format with underscores. There is no clear verb_noun pattern, as names vary from noun phrases to compound terms, making the set readable but lacking a predictable structure.
With 4 tools, the count is reasonable for a server focused on web content management and search. It is well-scoped for handling knowledge graphs, web searches, guidance, and management operations, though the overlap might suggest some consolidation could improve efficiency without being excessive or too sparse.
Inferring the domain as web content search and management with Exa's platform, the tool set covers key areas like search, knowledge graphs, and webset operations. However, there are notable gaps in lifecycle coverage, such as missing explicit update or delete tools for websets, and the overlap between 'websets_manager' and other tools creates redundancy rather than a complete CRUD surface, potentially leading to agent confusion in workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
Enable AI assistants to perform web searches using Perplexity's Sonar Pro.
Give AI assistants access to real-time data. Search the web, compare flights, find hotels, and more.
Live web access for agents: scrape, SERP search, crawl/map, 74 collectors, datasets, proxies.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/waldzellai/exa-mcp-server-websets'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
