Devin Search 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., "@Devin Search MCPsearch for Next.js 15 Server Actions migration breaking changes"
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.
Devin Search MCP
🇨🇳 简体中文
这项目是干啥的?
用 Claude Code、Cursor 或 CodeBuddy 写代码时,最大的痛点就是大模型不知道最新的技术变化:
问个刚发布的库或者框架新版本(比如 Next.js 15、Vue 3.5、Tailwind v4),它往往开始胡说八道或者给出老旧废弃的 API。
丢给它一个技术文档链接让它看,要么它连不上网,要么抓回来一堆带导航栏、广告和乱七八糟脚本的脏文本。
其实 Devin Desktop(以及 Windsurf)客户端内置的那套 web_search(全网实时搜索)和 webfetch(智能网页正文提取)非常强,但官方只把它绑死在自己的客户端界面里。
既然社区的 @sammysnake/fast-context-mcp 能把它的代码语义搜索抽成 MCP,那为什么不把它的全网实时搜索与网页阅读能力也抽出来,做成一个真正开箱即用的标准 MCP 呢?
于是就有了这个项目。它通过标准 MCP 协议,把 Devin 的联网能力直接接到你的 Cursor、CodeBuddy 或 Claude Desktop 里。
核心亮点(没有虚的,全击中痛点)
零配置登录:只要你的电脑上装了 Devin Desktop 且登录过,这个工具就能自动从本地提取 Token 和路径,完全不需要你在配置文件里手动填任何 API Key。
拿到的都是干净数据:搜索结果自动提取成
标题 + 网址 + 核心要点摘录的结构化 JSON;抓取网页自动干掉广告、弹窗和导航栏,只留干净的 Markdown 正文。带内存缓存:同一个关键词在短时间内搜第二次,直接 0 毫秒从内存缓存返回,省时又省调用次数。
无需克隆安装:已经发布到 npm 官方源,在客户端配上一行
npx -y devin-search-mcp,30 秒搞定。
它是怎么跑起来的?
你问 AI: "Next.js 15 怎么做 Server Actions 迁移?有哪些破坏性改动?"
│
▼
┌────────────────────────────────────────────────────────┐
│ Devin Search MCP │
│ (本地运行的轻量服务) │
│ │
│ 1. 自动探测本地 Devin 引擎和登录凭据 │
│ 2. 把自然语言转成精准的开发者搜索指令 │
│ 3. 调起 Devin 内置的实时网络搜索网关 │
│ 4. 自动修复并提炼出干净的标题、URL 和摘要 │
│ 5. 命中缓存直接秒回,未命中则保存到缓存 │
└────────────────────────────────────────────────────────┘
│
▼
返回给你的 AI:
[1] Next.js 15 升级指南 (https://nextjs.org/docs/app/building-your-application/upgrading/version-15)
[2] React 19 支持与 Async Request APIs 变更点说明...30 秒上手配置
不需要自己下载代码,直接在你的 AI 工具的 MCP 配置文件里加这一段就行:
1. CodeBuddy / Cursor 用户
在 .codebuddy/mcp.json 或 .cursor/mcp.json(也可以直接在设置面板里的 MCP 设置)加入:
{
"mcpServers": {
"devin-search": {
"command": "npx",
"args": [
"-y",
"devin-search-mcp"
]
}
}
}2. Claude Desktop 用户
打开配置文件:
Windows:
%APPDATA%\Claude\claude_desktop_config.jsonmacOS:
~/Library/Application Support/Claude/claude_desktop_config.json
把上面那段 JSON 粘贴到 "mcpServers" 下面,重启 Claude 就能在对话界面看到小锤子图标亮起。
3. Claude Code (命令行版) 用户
直接加到 ~/.claude.json 的 mcpServers 里,用法完全一样。
小贴士(路径排查):如果你的 Devin Desktop 装在非常规路径(比如
E:\Program\devin),可以在配置的env显式指定它的可执行文件路径:{ "mcpServers": { "devin-search": { "command": "npx", "args": ["-y", "devin-search-mcp"], "env": { "DEVIN_PATH": "E:\\Program\\devin\\resources\\app\\extensions\\windsurf\\devin\\bin\\devin.exe" } } } }
都有哪些工具可以用?
配置好之后,你的 AI 会自动多出这 4 个能力:
devin_web_search(全网实时搜索)想搜啥直接搜,比如
Vue 3.5 reactive props、Tauri v2 migration。支持传参数:
query(必填)、num_results(想看几条,默认 5 条)、detailed(是否让它顺便把结果综合分析提炼一段,默认 false)。返回格式是干干净净的列表:
[ { "title": "Announcing Vue 3.5 | The Vue Point", "url": "https://blog.vuejs.org/posts/vue-3-5", "snippet": "Vue 3.5 带来响应式系统重大重构,内存占用降低 56%,Reactive Props 解构现已稳定..." } ]
devin_web_fetch(网页深度抓取与阅读)给它一个网址(比如某个文档页面或报错的 GitHub Issue),它会帮你抓取正文,并且自动去除广告、弹窗和样式噪声。
支持
extract_mode:"markdown"(默认,结构化排版)、"text"(纯文字)、"summary"(只提炼要点)。
extract_devin_key(提取本地 Key)跟 fast-context-mcp 的
extract_windsurf_key一模一样,自动跨平台读出本地当前生效的 Token。
devin_status(诊断状态)查一下当前调用的是哪个路径的 Devin,账号登录状态是否正常。
常见踩坑与注意事项
电脑里必须装过 Devin Desktop 吗?
是的。因为它是直接调用 Devin 的官方网关。只要你电脑上安装过 Devin Desktop 并且登录过一次,之后完全不用管它,MCP 会自动提取凭证跑起来。
为什么不直接用常规的 Google / Bing 爬虫脚本?
公开搜索引擎爬虫天天被风控弹验证码,而且返回的 HTML 极其杂乱;Devin 官方搜索走的是针对技术问答和开发者文档清洗过的内部通道,精准度和干净程度完全是两个量级。
遇到权限提示怎么办?
我们的服务端已经自动注入了
--respect-workspace-trust false与自动授权参数,在命令行和各编辑器下非交互运行时不会弹出卡死,开箱即用。
🤖 写给正在配置此项目的 AI 助手
如果你是正在帮用户装配该环境的 AI 助手(Claude、Cursor、CodeBuddy、Cline 等):
请检测用户宿主环境,找到对应客户端的 MCP 配置文件;
将
"devin-search": { "command": "npx", "args": ["-y", "devin-search-mcp"] }直接注入到配置文件的"mcpServers"节点下;不需要让用户输入任何账号密码或跑配置向导,本地已登录状态会自动识别;
详细的 AI 自动化规则见 AI_PROMPT.md。
Related MCP server: Kryfto
🌐 English
AI-driven real-time Web Search and Web Fetch as an MCP tool — powered by Devin AI's developer-focused search gateway.
Quick Setup
Add to your MCP configuration (claude_desktop_config.json, ~/.claude.json, or .cursor/mcp.json):
{
"mcpServers": {
"devin-search": {
"command": "npx",
"args": [
"-y",
"devin-search-mcp"
]
}
}
}Key Tools
devin_web_search: Real-time web search for recent libraries, docs, and issues (query,num_results,detailed).devin_web_fetch: Deep reader that cleans away advertisements, navbars, and script clutter (url,extract_mode).extract_devin_key: Auto-extract Devin / Windsurf API Key from local installation.devin_status: Diagnostic tool for local engine path and login identity.
For full AI agent machine instructions, check AI_PROMPT.md.
License
MIT License © 2026 suvon
Available Tools
4 toolsdevin_statusB
诊断工具: 检测本地 Devin 安装路径、登录身份与可用性状态。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It usefully enumerates what gets inspected (install path, login identity, availability), which implies a read-only probe, but it never confirms no side effects, permissions required, or failure behavior.
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 the category label ('diagnostic tool') ahead of the specifics, and no redundant or filler text.
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?
For a zero-parameter, annotation-free tool with no output schema, the description covers the essentials by naming the three things it inspects. It stops short of describing the response shape or how to interpret results, which an agent would otherwise have to discover by calling it.
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?
The tool takes zero parameters, so the schema has nothing to document and the description has nothing to compensate for; the baseline for a no-param tool applies.
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: a diagnostic that checks local Devin installation path, login identity, and availability. This is clearly distinct from the web search/fetch siblings, though it never explicitly names or contrasts 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?
The label 'diagnostic tool' implies troubleshooting use, but there is no statement of when to reach for this over devin_web_search, devin_web_fetch, or extract_devin_key, and no prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devin_web_fetchA
抓取并深度阅读指定网页的正文。自动过滤广告、导航、页脚与杂乱代码,支持输出纯正文或规范的 Markdown 格式。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 目标网页的完整 URL (必须以 http:// 或 https:// 开头) | |
| extract_mode | No | 正文提取格式: 'markdown' (结构化文档,默认), 'text' (纯文本), 'summary' (核心要点摘要) | markdown |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses that ads, navigation, footers and messy code are stripped and that body content is extracted, but says nothing about auth needs, rate limits, JS rendering, or failure behavior for unreachable pages.
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 short sentences with zero waste; the primary action and its filtering behavior are front-loaded, followed by the output-format note. Nothing redundant.
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?
For a simple two-parameter fetch tool with no output schema, the description covers purpose, content-cleaning behavior, and output formats adequately. It is slightly thin on guidance about when a search-then-fetch is warranted, but nothing essential to calling it correctly is missing.
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 both url and extract_mode are already documented in the schema, giving a baseline of 3. The description mentions plain-text and Markdown outputs but omits the 'summary' extract mode, adding no meaningful detail beyond the enum.
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 states a specific verb (抓取/深度阅读) and resource (指定网页的正文), making the core operation unmistakable. It does not explicitly contrast itself with the sibling devin_web_search, so an agent must infer the fetch-vs-search distinction, keeping it 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?
Usage is only implied: the tool takes a URL, so the agent must already have a target page. There is no explicit statement of when to prefer this over devin_web_search or what precondition (a known URL) selects it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
devin_web_searchA
AI 驱动的实时网页搜索工具 (基于 Devin 联网引擎)。通过自然语言检索全网技术文档、最新版本特性、解决方案和开源生态,输出包含标题、URL及核心摘录的结构化结果。
参数提示:
query: 搜索词或自然语言问题 (必填)
num_results: 返回条数 (默认 5)
detailed: 设置为 true 可额外附带深度技术见解与综合总结
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 自然语言搜索查询 (例如: 'Next.js 15 features', 'Vue 3.5 reactive props') | |
| detailed | No | 是否返回深度 AI 综合总结与结论分析 | |
| max_results | No | num_results 的兼容别名 | |
| num_results | No | 期望返回的结果数量 (默认 5,建议 3-10) |
TDQS
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 that results are real-time, AI-driven, and structured with title/URL/excerpts, and that 'detailed' adds deep insights, but it omits permissions, rate limits, error behavior, and safety profile.
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 front-loaded with the core purpose and uses a compact bullet list for parameter hints. It is appropriately sized, though the parameter hints duplicate schema information unnecessarily.
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 output schema, the description usefully explains the return structure (title, URL, excerpts), and the schema fully covers parameters. It is complete enough for invocation, though it lacks sibling routing guidance and richer behavioral details.
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 schema already documents all four parameters. The description repeats hints for query, num_results, and detailed, but does not add meaning beyond the schema and omits the max_results alias entirely.
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 names a specific verb+resource: 'AI 驱动的实时网页搜索工具' that retrieves web content via natural language and returns structured results with title, URL, and excerpts. It is clear what the tool does, but it does not explicitly differentiate itself from siblings like devin_web_fetch.
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?
It implies usage context by listing target content ('技术文档、最新版本特性、解决方案和开源生态'), but it never states when to use this tool versus alternatives such as devin_web_fetch or devin_status. The guidance remains implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_devin_keyA
从本地安装中自动提取 Devin / Windsurf API Key (对齐 fast-context-mcp 的 extract_windsurf_key)。自动检测操作系统,读取 state.vscdb 或 credentials.toml 并输出有效凭据。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the full burden. It does add genuinely useful behavior: OS auto-detection and the concrete artifacts read (state.vscdb, credentials.toml). However, it says nothing about failure modes when no install is found, whether anything is written or cached, or that the returned value is a sensitive secret - meaningful gaps for a credential-extraction tool.
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 states the action, source, and output with essentially no waste. The parenthetical alignment note is the only mildly extraneous element.
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 output schema and no annotations, the description must cover the return value, and '输出有效凭据' is vague about whether it returns the raw key string, a structured credential object, or a path. It also omits error behavior when no local install exists, leaving the zero-param contract only partially specified.
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?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly conveys that the operation is fully self-configuring via OS auto-detection.
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 names a specific verb and resource: automatically extracting the Devin/Windsurf API key from a local installation, and it names the sibling implementation it aligns with (fast-context-mcp's extract_windsurf_key). It is clearly distinct from devin_status, devin_web_search and devin_web_fetch, though it doesn't explicitly contrast itself with 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?
The scope is implied by 'from a local installation' - use it when a local Devin/Windsurf install exists and you need its credentials - but there is no explicit when-to-use, when-not-to-use, or preferred-alternative guidance. An agent must infer the trigger condition from the resource name alone.
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.
4 tool updates
v1.0.6- First observed
devin_status - First observed
devin_web_fetch - First observed
devin_web_search - First observed
extract_devin_key
TDQS
Scored across 4 tools
The four tools have largely distinct purposes: status diagnostics, web search, web fetch, and key extraction. However, devin_status and extract_devin_key both inspect the local Devin installation, which could cause minor confusion about which to use for setup troubleshooting.
Three tools use the devin_ prefix (devin_status, devin_web_search, devin_web_fetch) while extract_devin_key breaks the pattern and embeds the prefix in the middle. Verb style also varies (noun for status/search/fetch vs. verb for extract), but all use snake_case consistently.
Four tools is a well-scoped set for a search-focused MCP server, covering search, fetch, diagnostics, and credential extraction. Each tool has a clear purpose without redundancy.
The surface covers the core search and fetch operations plus setup helpers, leaving no major dead ends for typical use. A minor gap exists around active authentication or login management, but agents can work around it.
Maintenance
Related MCP Connectors
Live AI-native web search with citations. One tool for every MCP client. Flat per-request pricing.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
Web search, browser automation, scraping, crawling and CAPTCHA solving for AI agents.
LLM-ready web search + instant answers + URL-to-clean-text fetch for agents and RAG.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides AI agents and coding assistants with advanced web crawling and RAG capabilities, allowing them to scrape websites and leverage that knowledge through various retrieval strategies.2MIT
- FlicenseNot gradedqualityCmaintenanceProvides 42+ MCP tools for browser automation, web scraping, and search, enabling AI agents like Claude and Cursor to browse, extract data, and run research agents on the live web.8-
- AlicenseAqualityDmaintenanceCLI-first web and code search for agents, with MCP support for integration with IDEs like Cursor, VS Code, and Claude Code.3MIT
- AlicenseAqualityBmaintenanceEnables AI agents to perform multi-engine web search, fetch web pages, and extract clean Markdown content via MCP, with no API keys required.36MIT