xai-search-mcp
Click on "Deploy 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., "@xai-search-mcpsearch the web for recent breakthroughs in quantum computing"
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.
xAI Search MCP Server
An MCP (Model Context Protocol) server that provides real-time web search and X (Twitter) search capabilities via the xAI API.
Quick Start
The easiest way to use this server is via npx — no clone or build required:
XAI_API_KEY=your_key npx @kicito/xai-search-mcpJust set your XAI_API_KEY environment variable and configure your MCP client (see Configuration below).
Related MCP server: superhighway-mcp
Tools
web_search
Search the web in real-time. Returns results with source citations.
Parameter | Type | Required | Description |
| string | ✅ | The search query |
| string[] | ❌ | Only search within these domains (max 5) |
| string[] | ❌ | Exclude these domains from search (max 5) |
x_search
Search X (Twitter) posts, users, and threads. Returns results with source citations.
Parameter | Type | Required | Description |
| string | ✅ | The search query for X posts |
| string[] | ❌ | Only consider posts from these handles (max 10) |
| string[] | ❌ | Exclude posts from these handles (max 10) |
| string | ❌ | Start date (ISO8601, e.g. |
| string | ❌ | End date (ISO8601, e.g. |
Setup
Prerequisites
Node.js 18+ (for native
fetchsupport)An xAI API key
Install & Build
npm install
npm run buildConfiguration
Claude Desktop
Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"xai-search": {
"command": "npx",
"args": ["-y", "@kicito/xai-search-mcp"],
"env": {
"XAI_API_KEY": "your-xai-api-key-here"
}
}
}
}Cursor
Add to your Cursor MCP settings:
{
"mcpServers": {
"xai-search": {
"command": "npx",
"args": ["-y", "@kicito/xai-search-mcp"],
"env": {
"XAI_API_KEY": "your-xai-api-key-here"
}
}
}
}If you prefer to clone and build manually:
git clone https://github.com/kicito/x_search_mcp.git
cd x_search_mcp
npm install
npm run buildThen use the full path in your config:
{
"mcpServers": {
"xai-search": {
"command": "node",
"args": ["/absolute/path/to/x_search_mcp/build/index.js"],
"env": {
"XAI_API_KEY": "your-xai-api-key-here"
}
}
}
}Environment Variables
Variable | Required | Default | Description |
| ✅ | — | Your xAI API key |
| ❌ |
| The xAI model to use |
How It Works
The server uses the xAI Responses API with built-in server-side tools (web_search and x_search). When an MCP client calls one of the tools, the server:
Sends the query to
POST https://api.x.ai/v1/responseswith the appropriate tool configurationGrok executes the search, gathers results, and generates a response
Citations (source URLs) are extracted from the response annotations
The response text and formatted citations are returned to the MCP client
Development
# Install dependencies
npm install
# Build
npm run build
# Start (requires XAI_API_KEY env var)
XAI_API_KEY=your-key npm startLicense
MIT
Available Tools
2 toolsweb_searchB
Search the web in real-time using xAI. Returns results with source citations.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query | |
| allowed_domains | No | Only search within these domains (max 5). Cannot be used with excluded_domains. | |
| excluded_domains | No | Exclude these domains from search (max 5). Cannot be used with allowed_domains. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions real-time execution and source citations, adding some behavioral context. Without annotations, it carries the full burden, but it does not disclose potential side effects or limitations beyond the basic functionality.
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 with two short sentences that immediately convey the purpose. No wasted words.
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 simplicity (3 parameters, no output schema), the description provides enough context for expected usage. However, it omits information about the result format, which could be helpful.
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 baseline is 3. The description does not add any additional semantics beyond what the schema already provides for each parameter.
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 it searches the web in real-time with source citations. However, it does not differentiate from the sibling tool 'x_search', so it falls short of a 5.
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 alternatives like x_search. The description is purely functional with no contextual usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
x_searchA
Search X (Twitter) posts, users, and threads in real-time using xAI. Returns results with source citations.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query for X posts | |
| to_date | No | End date for search range in ISO8601 format (e.g. YYYY-MM-DD). | |
| from_date | No | Start date for search range in ISO8601 format (e.g. YYYY-MM-DD). | |
| allowed_x_handles | No | Only consider posts from these X handles (max 10). Cannot be used with excluded_x_handles. | |
| excluded_x_handles | No | Exclude posts from these X handles (max 10). Cannot be used with allowed_x_handles. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It adds context about real-time and source citations, but lacks details on authentication, rate limits, or response structure. For a search tool, more transparency on result limits or pagination would be beneficial.
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 a single concise sentence that efficiently communicates the tool's purpose and key features (real-time, source citations). No unnecessary words or repetitions.
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 has 5 parameters and no output schema or annotations, the description provides the essential purpose but lacks details about result structure, limits, or error behavior. It is minimally complete for a straightforward 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?
With 100% schema description coverage, the baseline is 3. The description does not add meaningful information beyond what the schema already provides for parameters like query, dates, and handles. No extra clarification or examples are given.
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 verb 'Search', the specific resource 'X (Twitter) posts, users, and threads', and adds context like 'real-time' and 'source citations'. It effectively distinguishes from the sibling tool 'web_search' by specifying the platform.
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 X-specific content, and the sibling tool 'web_search' provides an obvious alternative for general web searches. However, it does not explicitly state when not to use this tool or mention potential limitations.
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.
2 tool updates
v1.0.3- First observed
web_search - First observed
x_search
TDQS
Scored across 2 tools
The two tools target completely distinct domains: web_search is for general web content, while x_search is specifically for X (Twitter). There is no overlap in their search scopes, so an agent can easily distinguish between them.
Both tools use a consistent verb_noun pattern (web_search, x_search), with the verb 'search' followed by a clear domain identifier. The naming is uniform and predictable.
With only 2 tools, the server is minimal but justified for its focused purpose of providing real-time search across two specific sources (web and X). It could potentially include more search types, but the current count is reasonable for a specialized search server.
The server covers the primary search needs implied by its name: web and X/Twitter searches. Minor gaps like additional search options or filters are missing, but the core functionality is adequately addressed for basic real-time searches.
Related MCP Connectors
An MCP server that integrates with Discord to provide AI-powered features.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
- UnifAPIOAuthcom.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAn MCP server that enables AI agents to perform search-augmented queries and deep multi-source research using the Perplexity API.81 npm25Apache 2.0
- AlicenseAqualityDmaintenanceAn MCP server that provides real-time web search to AI agents via a pay-per-search USDC microtransaction system.538 npm1MIT
- AlicenseNot gradedqualityDmaintenanceMCP server for internet search via direct Google and DuckDuckGo HTML scraping with AI-powered result normalization and optional summarization, requiring no API keys for search.MIT
- AlicenseBqualityDmaintenanceMCP server providing search, extract, map, and crawl tools powered by Tavily for real-time web data access.413 npmMIT