grok-native-search-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NO_PROXY | No | Optional no proxy entries for Jina Reader requests | |
| HTTP_PROXY | No | Optional HTTP proxy for Jina Reader requests | |
| HTTPS_PROXY | No | Optional HTTPS proxy for Jina Reader requests | |
| XAI_API_KEY | Yes | xAI or compatible gateway API Key | |
| JINA_API_KEY | Yes | Jina Reader API Key | |
| XAI_BASE_URL | No | Responses API base URL; defaults to https://aiapiv2.kamipon.com:442/v1 | https://aiapiv2.kamipon.com:442/v1 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| web_searchA | Use this when no exact URL is known and current information must be discovered across the public web. Complementary queries may run in parallel when multiple evidence lanes are needed. Stop after an authoritative source answers the question; deepen only for missing or conflicting evidence. For X-only content use x_search. After finding a page whose contents must be verified, call web_fetch with its exact URL. Returns the raw xAI Responses API body. |
| x_searchA | Use this for current X posts, accounts, threads, replies, and trends. Prefer it over web_search for X content. Complementary X queries may run in parallel. Stop when the requested official post or account result is found; deepen only if evidence is missing or conflicting. If a post links to an external page that must be read, call web_fetch with that URL. Returns the raw xAI Responses API body. |
| web_fetchA | Use this when an exact HTTP(S) URL is known, including URLs returned by web_search or x_search, and the task is to read, quote, summarize, or verify page text. Prefer it over Browser, curl, or shell when no login, click, form interaction, or visual inspection is required. Do not use it to discover URLs. Returns raw Markdown from Jina Reader. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: web_search for general web discovery, x_search specifically for X content, and web_fetch for retrieving a known URL. The descriptions explicitly cross-reference each other (e.g., web_search notes 'For X-only content use x_search'), leaving no ambiguity about which tool to select.
All three tool names follow a consistent `[source]_[action]` pattern: web_search, x_search, web_fetch. The naming convention is uniform, predictable, and immediately conveys scope (web vs. x) and operation (search vs. fetch).
With only 3 tools, the server is tightly scoped for its purpose: general web search, X-specific search, and URL fetching. This is well within the ideal 3–15 range and every tool earns its place; adding more would likely introduce redundancy.
The surface covers the full lifecycle of a search task: discover sources (web_search, x_search) and then retrieve/verify content (web_fetch). The tools explicitly reference each other to create a complete workflow, with no obvious gaps for the stated domain.