grok-native-search-mcp
# Grok Native Search MCP
一个极简的 stdio MCP Server,提供两个只读工具:
- `web_search(query)`:Grok 原生 Web Search 与 X Search
- `web_fetch(url)`:Jina Reader 网页转 Markdown
搜索固定使用 `grok-4.6`、`reasoning.effort: low`、`max_turns: 1` 和
`parallel_tool_calls: true`。可用来源包括中文社区、英文社区、官方途径和通用公开网站,由 Grok
根据问题选择相关类别。搜索答案解决问题后立即回答。
`web_search` 返回紧凑 JSON,只保留最终答案、带 `should_fetch` 决策的实际引用、Grok 选中链接的
Jina Reader 正文、模型、token 用量与 Web/X 搜索调用统计;`web_fetch` 继续原样返回 Jina Reader
Markdown。
使用 `web_search` 一次性提交完整问题并联网获取实时信息;MCP 内部并行读取 Grok 标记为
`should_fetch: true` 的链接,并将正文放入对应引用的 `content` 字段。用户要求读取具体 URL 时使用
`web_fetch`。
```json
{
"answer": "搜索结果生成的答案",
"citations": [
{
"url": "https://example.com/source",
"should_fetch": true,
"content": "页面 Markdown"
}
]
}
```
## 环境变量
| 变量 | 用途 |
| --- | --- |
| `XAI_API_KEY` | xAI 或兼容网关的 API Key |
| `XAI_BASE_URL` | 可选,Responses API 基础地址;默认使用 `https://aiapiv2.kamipon.com:442/v1` |
| `JINA_API_KEY` | Jina Reader API Key |
| `HTTP_PROXY` / `HTTPS_PROXY` / `NO_PROXY` | 可选,仅供 Jina Reader 请求使用的环境代理配置 |
## 使用 npx 启动
```bash
npx -y grok-native-search-mcp@latest
```
## Codex 配置
```toml
[mcp_servers.grok_native_search]
command = "npx"
args = ["-y", "grok-native-search-mcp@latest"]
env_vars = ["XAI_API_KEY", "JINA_API_KEY", "HTTP_PROXY", "HTTPS_PROXY", "NO_PROXY"]
```
配置后重启 Codex。
## 本地开发
```bash
npm install
npm test
```
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.