xai-search-mcp
You can use this MCP server to run real-time web and X (Twitter) searches via the xAI API, returning cited results.
web_search: search the web in real-time with optional domain allow/exclude filters (max 5 each; cannot combine allow and exclude).x_search: search X posts, users, and threads with optional handle allow/exclude filters (max 10 each; cannot combine allow and exclude) andfrom_date/to_daterange filters.Queries are required, trimmed, and must not be empty.
Results include source citations extracted from xAI response annotations.
Can be run via
npxor a local build by settingXAI_API_KEY; optionalXAI_MODELandXAI_TIMEOUT_MSare configurable.
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
Requires Node.js 22 or newer. The easiest way to use this server is via npx — no clone or build required:
XAI_API_KEY=your_key npx @kicito/xai-search-mcpOn Windows PowerShell:
$env: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; trimmed and must not be empty |
| 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; trimmed and must not be empty |
| string[] | ❌ | Only consider posts from these handles (max 10) |
| string[] | ❌ | Exclude posts from these handles (max 10) |
| string | ❌ | Inclusive start date (valid calendar date in |
| string | ❌ | Exclusive end date (valid calendar date in |
Input validation
Queries are trimmed; empty or whitespace-only queries are rejected.
Domains are trimmed, lowercased and IDNA-normalized, with a trailing root dot removed. Supply bare domains (for example,
example.com) rather than URLs. Empty or invalid entries are rejected.X handles are trimmed and a leading
@is removed. Handles must contain 1–15 letters, digits or underscores; case is preserved. Profile URLs are not accepted.For each tool, nonempty allow and exclude lists cannot be combined. Empty filter arrays (and
nullor omitted filters) are treated as absent.Dates must be real calendar dates in exactly
YYYY-MM-DDformat, not timestamps. When both dates are provided,from_datemust be on or beforeto_date.
X handle/date filters apply to search, not thread fetches. Handle lists are conservatively capped at 10 entries.
Setup
Prerequisites
Node.js 22 or newer
An xAI API key
Install & Build
npm ci
npm run buildRun these commands from a cloned checkout. The build uses TypeScript and a Node.js helper, with no POSIX chmod command required; it works on Linux, macOS, and Windows.
Configuration
OpenCode V2 (MCP server and optional agent skill)
The optional xai-search skill tells OpenCode agents when and how to use web_search and x_search, including filters and source citations. It is guidance, not an executable tool or an MCP server. In this checkout, OpenCode can load the skill from .opencode/skills/xai-search/SKILL.md. To use it in another project, copy the xai-search skill directory to ~/.config/opencode/skills/xai-search/ for your user, or to that project's .opencode/skills/xai-search/.
Configure the MCP server separately. With Node.js 22+ and an xAI API key, put the following in your OpenCode opencode.jsonc (merge with any existing config):
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"servers": {
"xai-search": {
"type": "local",
"command": ["npx", "-y", "@kicito/xai-search-mcp"],
"environment": {
"XAI_API_KEY": "{env:XAI_API_KEY}"
}
}
}
}
}Set XAI_API_KEY in the environment that launches OpenCode; do not commit your key to git. Check the server connection with opencode mcp list. The skill alone cannot supply the server or API key. This OpenCode V2 config uses mcp.servers, not the mcpServers format shown below for Claude Desktop and Cursor.
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 ci
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 |
| ❌ |
| Application request timeout in milliseconds; positive integer, maximum |
Requests are bounded by the application timeout, including response-body processing. MCP request cancellation aborts the upstream request and stops processing without a response. Timeouts and upstream failures return tool errors; upstream error details are sanitized and bounded rather than returning arbitrary raw response bodies. Requests are not automatically retried.
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 the locked dependencies
npm ci
# Type-check without emitting build output
npm run typecheck
# Build
npm run build
# Build and run offline tests
npm test
# Build and verify npm package contents and executable metadata (offline dry-run)
npm run test:package
# Start after setting XAI_API_KEY in your shell or MCP client
npm startnpm run check:package checks an existing build without rebuilding. Package checks verify the CLI entrypoint, executable metadata, build files, README, manifest, and MIT license using npm pack --dry-run --json; they do not publish or require an API key. Tests use mocked requests, not live xAI searches.
CI runs type-checking, tests, and package checks on Node.js 22 and 24 on Linux, plus Node.js 22 on Windows. Tag-triggered npm publishing is gated on the same checks and uses Node.js 22.
License
MIT — see LICENSE.
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.
Maintenance
Related MCP Connectors
Hosted X (Twitter) MCP server for Claude, ChatGPT and Cursor, with each action switched per account.
Official MCP server for twitterapis.com. Read and write Twitter/X: search, users, tweets, DMs.
One MCP server for all web data. Scrape, search, crawl, and AI research in one install.
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.42 npm25Apache 2.0
- AlicenseAqualityFmaintenanceAn MCP server that provides real-time web search to AI agents via a pay-per-search USDC microtransaction system.5127 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.48 npmMIT