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., "@Kimi Search MCP search the web for the latest news on Moonshot's Kimi K2 model"
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.
非官方的本地 MCP Server，使用开放平台 API Key 调用 Kimi 联网搜索服务。仅支持 stdio。
Node.js 22 或更新版本
npm
Moonshot 开放平台 API Key
Related MCP server: Ollama Web Search
推荐使用 npm 全局安装，适合日常使用，启动开销较低且无需自行构建。npx 配置方便，适合快速试用，但启动开销较高；源码构建适合需要修改代码的用户。
以下以 Kimi Code 桌面版为例：将配置合并到用户级 ~/.kimi-code/mcp.json，替换 API Key 占位符。
保存配置后，如工具未出现在 MCP 列表中，或配置变更未生效，可尝试重启客户端。
npm install -g kimi-search-mcp@latest安装完成后，使用以下启动配置：
Windows：
{
"mcpServers": {
"kimi-search": {
"command": "cmd",
"args": ["/c", "kimi-search-mcp"],
"env": {
"MOONSHOT_API_KEY": "YOUR_MOONSHOT_API_KEY",
"KIMI_ENABLE_WEB_FETCH": "false"
},
"toolTimeoutMs": 80000
}
}
}macOS / Linux：
{
"mcpServers": {
"kimi-search": {
"command": "kimi-search-mcp",
"args": [],
"env": {
"MOONSHOT_API_KEY": "YOUR_MOONSHOT_API_KEY",
"KIMI_ENABLE_WEB_FETCH": "false"
},
"toolTimeoutMs": 80000
}
}
}无需全局安装或自行编译，配置方便，但启动开销高于全局安装。
Windows：
{
"mcpServers": {
"kimi-search": {
"command": "cmd",
"args": ["/c", "npx", "-y", "kimi-search-mcp@latest"],
"env": {
"MOONSHOT_API_KEY": "YOUR_MOONSHOT_API_KEY",
"KIMI_ENABLE_WEB_FETCH": "false"
},
"toolTimeoutMs": 80000
}
}
}macOS / Linux：
{
"mcpServers": {
"kimi-search": {
"command": "npx",
"args": ["-y", "kimi-search-mcp@latest"],
"env": {
"MOONSHOT_API_KEY": "YOUR_MOONSHOT_API_KEY",
"KIMI_ENABLE_WEB_FETCH": "false"
},
"toolTimeoutMs": 80000
}
}
}首次启动需要联网下载包。
从 GitHub 仓库 下载源码，在项目根目录执行：
npm ci
npm run build构建产物位于 dist。将下方配置合并到客户端的 MCP 配置中，替换 API Key 占位符。下面以 Windows 为例，请填写实际绝对路径：
{
"mcpServers": {
"kimi-search": {
"command": "node",
"args": ["C:/path/to/kimi-search-mcp/dist/index.js"],
"env": {
"MOONSHOT_API_KEY": "YOUR_MOONSHOT_API_KEY",
"KIMI_ENABLE_WEB_FETCH": "false"
},
"toolTimeoutMs": 80000
}
}
}MCP 工具 | 对应接口 |
| |
| |
| 网页抓取，默认关闭 |
接口区别、参数和使用建议见官方联网搜索最佳实践。
变量 | 规则 |
| 必填，使用开放平台 API Key |
| 控制是否启用 |
考虑到不少 Agent 软件已经自带免费的网页抓取（web_fetch）功能，需要付费使用的 kimi_web_fetch 工具默认关闭，也不会出现在客户端的工具列表中。需要时，可将 KIMI_ENABLE_WEB_FETCH 设置为 "true" 来开启。
调用使用开放平台账户额度，具体价格和计费规则以官方联网搜索与网页抓取定价为准。
MIT，Copyright (c) 2026 Caelix。
Search webpages with Kimi Search Basic.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| text_query | Yes | ||
| include_content | No | ||
| timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, and it delivers almost nothing: no mention of result depth, rate limits, auth, whether content is fetched, or how it differs from the pro version. Only the verb "Search" weakly implies a read operation.
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?
It is a single short sentence, but its brevity reflects under-specification rather than efficient conciseness. The second half is redundant with the tool name and the first half is too thin to be useful.
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?
With no annotations, no output schema, 0% parameter coverage, and no explanation of the basic-vs-pro distinction, the definition leaves an agent unable to call the tool correctly or choose it over its sibling. Nothing an agent needs is present.
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 0% across four parameters (text_query, limit, include_content, timeout_seconds), and the description adds no meaning or format hints for any of them. The agent gets no guidance on what include_content returns or how limit/timeout behave.
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 gives a verb+resource ("Search webpages"), so the basic action is clear. However, the trailing phrase "with Kimi Search Basic" merely restates the tool name and gives no distinguishing scope, and the sibling kimi_search_pro is never referenced. The agent cannot tell from the description what separates this from the pro variant.
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?
There is no when-to-use guidance, no prerequisite, and no mention of the sibling kimi_search_pro as the alternative. Given a clearly named pro counterpart exists, the omission of any selection criteria is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search with Kimi Search Pro, returning text chunks and relevance scores.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sites | No | ||
| text_query | Yes | ||
| time_window | No | ||
| timeout_seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the return shape, but says nothing about authentication, rate limits, latency, site/time filtering behavior, or what happens on timeout, which matters for a tool with a 60s timeout parameter.
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?
A single front-loaded sentence with no filler, and the purpose and return value lead the description. It is efficient, though its brevity is partly under-specification rather than deliberate concision.
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?
With no annotations, no output schema, and five undocumented parameters (including a nested object), the description is too thin for the tool's complexity. Only the coarse return type is covered; parameter behavior, constraints, and alternative-tool selection are absent.
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?
All 5 parameters have 0% schema description coverage, including the nested time_window object with start/end fields. The description explains none of them, adding no meaning beyond the bare property names.
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?
States a specific verb and resource ('Search with Kimi Search Pro') plus the return shape ('text chunks and relevance scores'). It does not differentiate itself from the sibling kimi_search_basic, so an agent must infer what 'Pro' adds.
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 when-to-use guidance and no mention of the sibling kimi_search_basic, which is the obvious alternative. The agent gets no criteria for choosing between the two search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0kimi_search_basickimi_search_proScored across 2 tools
The two tools are clearly differentiated by tier: basic returns simple results while pro returns text chunks with relevance scores. An agent can distinguish them, though choosing between basic and pro may still require judgment about cost/quality tradeoffs.
Both tools follow the same predictable pattern kimi_search_basic and kimi_search_pro, using a consistent prefix plus a clear tier suffix.
Only two tools make the surface thin, but for a focused search server offering two quality tiers this is borderline rather than inappropriate. It earns each tool's place but leaves little room for parameterization or content retrieval.
For a web search server, basic and pro tiers cover the core capability, including richer output via relevance scores. Minor gaps exist, such as a dedicated content-fetch or pagination tool, but agents can work around them.
Scrape, crawl and search the web for AI agents via MCP.
Free web search for AI agents. No API key required. Hosted MCP in active development.
Live AI-native web search with citations. One tool for every MCP client. Flat per-request pricing.
Web MCP: scrape/crawl sites, web search, brand assets, app stores, YouTube, Reddit, Hacker News.