bluex-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., "@bluex-mcpsearch X for latest on @karpathy last 7 days"
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.
bluex-mcp
Live X (Twitter) + web search MCP server β powered by your locally logged-in Grok CLI, running on your X Premium / SuperGrok subscription quota.
Your coding agent doesn't know what shipped this morning. It doesn't see the X thread where ten other developers are hitting the same bug. It can't watch the keynote that started 20 minutes ago, can't follow the leak about your competitor's pricing, can't tell you what @karpathy posted this week.
bluex-mcp closes that gap. If you pay for X Premium ($8/mo), X Premium+ ($40/mo), or SuperGrok ($30/mo), you already have first-class live X + web access through Grok. This is a thin MCP server that exposes it to Claude Code, Codex, Cursor, Claude Desktop, and any other MCP client β by driving your locally logged-in grok CLI. Usage counts against your existing plan.
Why
Other Grok MCP servers use the xAI API. You need a key, a funded account, and you pay per token. bluex-mcp takes a different path.
xAI API (most Grok MCPs) | bluex-mcp | |
Auth |
| Your logged-in |
Cost | Pay-per-token API billing | $0 β runs on your subscription's quota |
Live X access | Yes | Yes (same Grok) |
Setup | Get a key, fund a balance |
|
Footprint | β | 2 search tools + 1 health check |
If you don't already pay for Grok, an API-based MCP is the right call. If you do,
bluex-mcpmakes that subscription do double duty.
Related MCP server: grok-search-mcp
Quick start
npm install -g github:Derek-Wong213/bluex-mcp
grok login
bluex-mcp healthWire it into your agent:
# Claude Code
claude mcp add bluex -- bluex-mcp# Codex (~/.codex/config.toml)
[mcp_servers.bluex]
command = "bluex-mcp"// Cursor / Claude Desktop (mcp.json)
{ "mcpServers": { "bluex": { "command": "bluex-mcp" } } }Restart. Ask "search X for what people are saying about <topic> in the last hour" β it routes through bluex_x_search.
What people actually ask it
Each example is a real moment where an agent without live X access just stalls. They all route through the two search tools below.
Breaking AI / model release, first signal.
"What did @AnthropicAI just announce? Last hour."
The newest model dropped on X 30 minutes ago; your agent's knowledge cutoff is six weeks behind. β bluex_x_search Β· recency=1hr Β· from:@handle
A library or CLI just broke and the docs are clueless.
"X mentions of cursor composer-2.5-fast billing in the last 4 hours?"
The "me too" wave shows up on X a full day before GitHub Issues triages it. β bluex_x_search recency=4hr β bluex_web_search the issue tracker
Vendor support went silent.
"Timeline + verbatim user quotes on the Cursor on-demand billing complaints this week."
The refund ticket disappeared into a black hole; the real signal lives in X user threads. β bluex_x_search mode=deep returns timeline + verbatim quotes + sentiment
Track a thinker, not a feed.
"From @karpathy, last 7 days, anything on nano-banana."
A specific account speaking up is what unblocks the call. β bluex_x_search from:@handle last:7d
Conference happening right now.
"#AnthropicDevDay tweets from the last hour."
The keynote is live; the official blog will recap six hours later. β bluex_x_search with hashtag + last:1hr
Competitor pre-launch intel.
"What's on X about Cursor pricing changes this week?"
Roadmap leaks land on X before any press release. β bluex_x_search recency=7d mode=deep
Breaking change before the docs admit it.
"Anyone hitting issues with Next.js 16 app router migration in the last day?"
The library's docs say "stable"; X has the unfixed-bug thread. β bluex_x_search + bluex_web_search on the upstream issue
Indie launch positioning research.
"Recent MCP server launch posts on X, last 14 days β what got real engagement?"
Studying how others framed a similar product before you ship yours. β bluex_x_search with engagement cues in the prompt
Academic paper reaction loop.
"Show me the X discussion around the <paper title> arXiv preprint."
Authors don't blog; the actual debate plays out in quote-tweets. β bluex_x_search mode=deep for perspectives + verification
Tools
Tool | Purpose |
| Search X/Twitter β filter by |
| Search the live web β domain include/exclude, recency |
| Check grok install, model, profile, login status |
Search modes
Mode | What you get |
| Summary + source items (title, url, author, handle, timestamp, snippet) + citations |
| Basic + |
Example output
bluex_x_search Β· mode: "basic"
{
"summary": "β¦",
"items": [
{ "title": "β¦", "url": "https://x.com/β¦/status/β¦", "handle": "@β¦",
"publishedAt": "2026-06-30T12:00:00Z", "snippet": "β¦" }
],
"citations": [{ "url": "https://x.com/β¦", "domain": "x.com", "secure": true }],
"urls": ["https://x.com/β¦"],
"diagnostics": {
"mode": "x", "analysisMode": "basic", "parseOk": true, "structured": true,
"model": "grok-build", "profile": "shared", "attempts": 1, "warnings": []
}
}mode: "deep" adds:
{
"analysis": {
"timeline": [{ "date": "β¦", "event": "β¦", "source": "β¦" }],
"quotes": [{ "quote": "β¦", "speaker": "β¦", "source": "β¦" }],
"perspectives": [{ "viewpoint": "β¦", "summary": "β¦", "sources": ["β¦"] }],
"sentiment": "β¦",
"verification": {
"confirmed": ["β¦"], "unconfirmed": ["β¦"], "contradictory": ["β¦"]
}
}
}How it works
your agent ββMCP/stdioβββΆ bluex-mcp ββchild processβββΆ grok CLI (your login) βββΆ live X + webEach search runs grok --single β¦ --output-format json --permission-mode dontAsk --json-schema β¦ in a throwaway working directory. The schema constrains the model to emit conforming JSON β no regex-guessing from prose.
Auth cache β login checked every 5 min; a cold probe takes ~2 s, then instant.
Recursion guard β
BLUEX_MCP_ACTIVEenv var prevents circular launches.Isolation β memory / subagents / plan-mode disabled; your grok sessions are untouched.
Configuration
Set these as environment variables in your MCP client's server config. All optional.
Variable | Default | Purpose |
|
| Path to the grok CLI binary |
|
| Per-call timeout (ms) |
|
| Max agentic turns the child grok may take |
|
| Retries on empty/failed runs (exponential backoff) |
| (grok default) | Reasoning effort β |
|
| Run grok under a dedicated clean profile (see below) |
|
| HOME for the isolated profile |
| (off) | Path to JSONL log file |
|
| How the |
|
| Also record per-tool dispatch counts in each log line |
|
| Master switch for the internal A/B experiment sampler (off in production) |
|
| Comma-separated effort levels the A/B sampler picks from. |
|
| Probability of injecting the X search strategy prompt when A/B is on |
Model is pinned to
grok-buildand is intentionally not configurable. The only other locally available model,grok-composer-2.5-fast, is a coding model β not suited for search.
Isolated profile (optional)
By default bluex-mcp reuses your existing Grok login. For full isolation (no grok config, rules, or other MCP servers loaded), set BLUEX_ISOLATED=1 and log in once:
BLUEX_ISOLATED=1 bluex-mcp login
# Then add BLUEX_ISOLATED=1 to your MCP client's environment for this server.FAQ
How is this different from other Grok or Twitter MCP servers? Other Grok-based MCPs are built on the xAI API β they take an XAI_API_KEY and bill per token. bluex-mcp takes a different path: it drives your already-logged-in grok CLI, so calls run on your X Premium / SuperGrok subscription quota. See the Why table for the full comparison.
Do I need an xAI API key? No. grok login with your existing subscription is all you need.
Is there a usage limit? Yes β you're subject to your Grok plan's rate limits. SuperGrok allows ~100 prompts/2 hr; lower tiers less. source This is your normal Grok quota, not an extra limit.
Does SuperGrok include an X blue check? No. SuperGrok is a standalone AI subscription with no X social features. The blue checkmark comes with X Premium / X Premium+. source
Is this affiliated with xAI or X? No. Independent open-source wrapper around the public Grok CLI.
Does it store my credentials? No. Auth lives in the grok CLI's own profile. bluex-mcp only executes the binary.
Will it interfere with my normal grok sessions? No. Each search runs in a throwaway directory with memory/subagents/plan-mode off. For full config isolation, set BLUEX_ISOLATED=1.
Acknowledgements
bluex-mcp's initial architecture was forked from z2z23n0/grok-search-mcp. The deep analysis structure draws on stat-guy/grok-search-mcp, recency presets from mzkrasner/grok-x-insights, and tool categorisation from guzus/grok-mcp.
License
MIT β LICENSE
Available Tools
3 toolsbluex_health_checkCheck bluex-mcp + grok wiringA
Verify the grok CLI is installed, which model is used, the isolated HOME, and whether you are logged in. Run this first if searches fail.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Lists what it checks but omits behavioral details like read-only nature or side effects. Adequate basic transparency.
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?
Two sentences, front-loaded with purpose. No redundant words. Efficient and to the point.
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?
Simple tool with no parameters or output schema. Description covers usage context but lacks detail on output format or results structure.
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?
No parameters, schema coverage 100%. Description adds meaning by explaining the specific checks performed, beyond schema's empty property list.
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 verifies the grok CLI installation, model, HOME, and login status. This distinguishes it from sibling search tools as a diagnostic utility.
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?
Explicitly says 'Run this first if searches fail', providing clear when-to-use guidance. No exclusions mentioned but sufficient for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bluex_web_searchSearch the live webA
Search the live web using your logged-in Grok account. Returns a summary, source items, and citations. Set mode="deep" for timeline, quotes, perspectives, sentiment, and verification.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | basic = fast result list; deep = adds timeline, quotes, perspectives, sentiment, verification | basic |
| query | Yes | What to search the web for | |
| domains | No | Prefer these domains | |
| recency | No | Relative time window: 15min|1hr|4hr|24hr|7d | |
| maxResults | No | Max items to return | |
| excludedDomains | No | Exclude these domains |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions authentication requirement ('logged-in Grok account') and output type (summary, source items, citations), but does not disclose rate limits, read-only nature, or other behavioral traits.
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?
Two concise sentences: first states core function, second explains mode option. No unnecessary words or repetition. Front-loaded with essential information.
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?
Tool has 6 parameters (1 required) with full schema coverage. Description mentions output components but no structure details. No output schema. Adequate for a straightforward search tool, but could mention defaults (e.g., maxResults) or edge cases.
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 baseline is 3. The description adds context for the mode parameter ('deep for timeline...') but does not significantly enhance understanding of other parameters beyond what the schema already provides.
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?
Title 'Search the live web' and description clearly state the tool's function: searching the live web using a logged-in Grok account. It distinguishes from siblings (e.g., bluex_x_search likely searches X/Twitter, bluex_health_check is unrelated).
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?
Description explains when to set mode='deep' for richer results, but lacks explicit guidance on when not to use this tool or alternatives. No mention of preferring sibling tools for specific tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bluex_x_searchSearch X (Twitter) liveB
Search live X/Twitter posts and discussion using your logged-in Grok account. Returns a summary, source items (title, URL, handle, timestamp, snippet), and citations. Set mode="deep" for timeline, verbatim quotes, multiple perspectives, sentiment, and verification.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | basic = fast result list; deep = adds timeline, quotes, perspectives, sentiment, verification | basic |
| query | Yes | What to search X for | |
| since | No | Only posts on/after this date (e.g. 2026-06-01) | |
| until | No | Only posts on/before this date | |
| handles | No | Restrict to these @handles | |
| recency | No | Relative time window: 15min|1hr|4hr|24hr|7d | |
| maxResults | No | Max items to return |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry behavioral disclosure. It mentions account requirement (logged-in Grok) and mode behavior (deep adds timeline, quotes, etc.). However, it does not cover rate limits, data retention, or potential side effects. Adequate but not rich.
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?
Two sentences efficiently convey purpose and key behavior without fluff. Front-loaded with the main action and essential context.
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?
No output schema exists, and the description gives a high-level outline of returns (summary, source items, citations) but lacks detail on structure. Parameter details are covered by schema. Adequate for a search tool but leaves some gaps in return format.
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 value by explaining the mode parameter's additional features (timeline, quotes, perspectives, sentiment, verification) beyond the schema enum descriptions. For other parameters, schema descriptions are sufficient.
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 searches live X/Twitter posts using a Grok account and lists return components (summary, source items, citations). It implicitly differentiates from siblings 'bluex_health_check' and 'bluex_web_search' by focusing on X/Twitter, but does not explicitly contrast them.
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 on when to use this tool versus alternatives, and no explicit when-not scenarios. The description only mentions basic vs deep mode effects but provides no decision criteria for choosing between them.
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.
3 tool updates
v0.1.0- First observed
bluex_health_check - First observed
bluex_web_search - First observed
bluex_x_search
TDQS
Scored across 3 tools
Each tool has a unique and non-overlapping purpose: health check for system readiness, web search for general web queries, and X search for Twitter-specific content. There is no ambiguity in their intended use.
All tool names follow a consistent pattern with the 'bluex_' prefix followed by a descriptive verb-noun pair (health_check, web_search, x_search). The naming is uniform and predictable, aiding agent selection.
With only 3 tools, the server is lean but covers its core functionality adequately. The count is on the lower end of the ideal range but not egregiously small, as each tool serves a distinct and necessary role.
The tool set covers health verification and two main search domains (web and X), which seems sufficient for its stated purpose. Minor gaps like additional search refinement or account management are absent but not critical for basic operation.
Maintenance
Related MCP Connectors
Twitter/X read-only MCP server β 12 tools: search, users, tweets, followers, timelines, trends.
- UnifAPIOAuthcom.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
MCP server for OnceAsk, the AI-native current-address layer for people and agents.
Related MCP Servers
- AlicenseBqualityDmaintenanceMCP server for interacting with the X platform (Twitter) via MCP clients like Claude, Cursor AI, and Windsurf AI.208 npm6MIT
- AlicenseNot gradedqualityCmaintenanceMCP server that enables coding agents to search X/Twitter and the web through the local Grok CLI, providing better search results than default Codex or Claude search without requiring an API key.17 npm6MIT
- AlicenseNot gradedqualityAmaintenanceMCP server for xAI Grok API with 19 tools for chat, web and X search, session management, tool chaining, image and video generation, and documentation.2MIT
- AlicenseAqualityBmaintenanceMCP server for the Twitter/X read API, enabling search, user profiles, tweets, followers, and more via natural language.94984 npmMIT