Link MCP
Link MCP is a Model Context Protocol server for Cursor IDE that provides intelligent web documentation fetching and conversation memory management.
Fetch Web Documentation (fetch_link_documentation): Automatically retrieve and extract structured content from any webpage, including UI components, API interfaces, code examples, page titles, and related links. Supports configurable crawling depth (0-3 levels) and content focusing via CSS selectors.
Save Conversation Memories (save_cursor_memory): Intelligently analyze, summarize, and save conversation history, key discussion points, code examples, and technical decisions as well-formatted Markdown files in the project's .cursor directory. Allows categorization and tagging for better organization and team sharing.
Retrieve Cursor Memories (get_cursor_memories): Search and access previously saved conversation summaries and documentation by category or tags, with optional result limiting for easy recall of important information.
Enables fetching and analyzing Ant Design component documentation, extracting component APIs, usage examples, and implementation details from the official documentation site
Provides capability to fetch and extract content from Baidu web pages for documentation and analysis purposes
Supports CSS selector-based content extraction from web pages, allowing targeted scraping of specific elements and sections
Integrates with GitHub for issue reporting and project collaboration, as mentioned in the documentation for support purposes
Generates and manages structured Markdown files for conversation summaries, technical documentation, and project notes with proper formatting
Distributed and installed through npm package registry, supporting global installation and npx execution for easy deployment
Enables fetching and analyzing React documentation, tutorials, and component examples from the official React documentation site
Click on "Install 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., "@Link MCPfetch the React docs from react.dev/learn and save our discussion on hooks"
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.
🚀 Link MCP - 智能文档获取与记忆管理
一个功能强大的 Model Context Protocol (MCP) 服务器,为 Cursor IDE 提供智能网页文档抓取和对话记忆管理功能。
✨ 核心功能
🔗 智能文档获取
网页内容抓取 - 自动获取任意网页的结构化内容
组件识别 - 智能识别 UI 组件、API 接口和代码示例
深度爬取 - 支持多层级链接爬取(0-3层可配置)
内容解析 - 提取标题、代码块、API 文档和相关链接
🧠 AI智能记忆管理
一键保存 - 用户一句话触发,AI自动总结并保存对话
智能分析 - 自动提取关键讨论点、代码示例、技术决策
工作区存储 - 保存到当前项目的
.cursor目录,便于团队共享结构化输出 - 生成格式化的 Markdown 文件,便于 Cursor AI 理解和引用
Related MCP server: AnyCrawl MCP Server
📦 安装配置
方法一:🌟 NPX 直接使用(推荐)
在 Cursor 中配置 MCP,将以下配置添加到 Cursor 的设置中:
打开 Cursor,按
Ctrl/Cmd + ,进入设置搜索 "MCP" 或找到 "Model Context Protocol" 部分
添加以下配置:
{
"mcpServers": {
"link-mcp": {
"command": "npx",
"args": ["link-mcp2"]
}
}
}就这么简单! 配置完成后重启 Cursor 即可使用。
方法二:📦 NPM 安装后配置
如果你想先通过npm安装包,然后配置到cursor的MCP中,可以按以下步骤操作:
1. 配置npm代理源(如果使用内部npm源)
# 设置npm代理源
npm config set registry http://10.100.1.27:8688/repository/npmmirror/
# 验证配置
npm config get registry2. 安装包到全局
# 从公共npm源安装
npm install -g link-mcp
# 或者从内部代理源安装
npm install -g link-mcp23. 配置 Cursor MCP
在 Cursor 的 MCP 配置中添加以下内容:
如果使用 Cursor 设置界面:
打开 Cursor,按
Ctrl/Cmd + ,进入设置搜索 "MCP" 或找到 "Model Context Protocol" 部分
添加以下配置:
{
"mcpServers": {
"link-mcp": {
"command": "link-mcp"
}
}
}如果使用 mcp.json 配置文件:
在项目根目录或 Cursor 配置目录创建 mcp.json 文件:
{
"mcpServers": {
"link-mcp": {
"command": "link-mcp"
}
}
}注意: 无论安装的是 link-mcp 还是 link-mcp2,MCP配置中的命令都是 link-mcp,因为这是在 package.json 中 bin 字段定义的可执行文件名。
4. 重启 Cursor
配置完成后重启 Cursor 即可使用。
🎮 立即开始
1. 重启 Cursor
配置完成后,重启 Cursor 以加载新的 MCP 服务器。
2. 验证工具
重启后,你将拥有 2 个强大的新工具:
fetch_link_documentation- 获取网页文档save_cursor_memory- AI智能保存对话记忆
3. 首次测试
请使用 fetch_link_documentation 工具测试
URL: https://www.baidu.com📖 工具使用指南
🔗 网页文档获取 (fetch_link_documentation)
参数说明:
url(必需) - 目标网页链接selector(可选) - CSS选择器,默认 "body"depth(可选) - 爬取深度 0-3,默认 1
使用示例:
# 基础用法
请使用 fetch_link_documentation 获取 Vue 官网文档
URL: https://vuejs.org/guide/
# 深度爬取
请使用 fetch_link_documentation 深度获取 WindUI 组件文档
参数:
url: https://wind-ui.com/components
depth: 2
selector: .content返回内容包括:
📄 页面标题和结构化内容
🧩 识别的组件和 UI 元素
🔌 提取的 API 接口和函数
💡 代码示例和使用案例
🔗 相关文档链接
🧠 智能保存对话记忆 (save_cursor_memory)
核心特点:
AI自动总结 - 智能分析整个对话历史
无感保存 - 用户只需一句话触发
结构化输出 - 自动格式化为清晰的markdown
工作区存储 - 保存到当前项目的
.cursor目录
使用方式: 用户只需要说:
"保存这次对话"
"记住刚才讨论的内容"
"把这次的技术讨论存起来"
"保存我们刚才的代码解决方案"AI会自动完成:(开发中)
🧠 智能分析整个对话内容
📋 提取关键讨论点、代码示例、技术决策
📝 格式化为结构化markdown文档
💾 保存到
.cursor/时间戳_主题.md✅ 告知用户保存位置和文件名
生成的文件包含:
对话主题概述
关键技术讨论点
代码示例和解决方案
重要决策和待办事项
完整的上下文信息
🎨 实际应用场景
📚 学习新技术栈
1. 获取官方文档
请使用 fetch_link_documentation 获取 React 官方教程
URL: https://react.dev/learn
2. 学习讨论后保存
用户:"保存我们刚才关于 React Hooks 的讨论"
AI 自动:分析对话 → 总结要点 → 保存到 .cursor/2025-09-09-react-hooks学习总结.md🧩 组件库研究
1. 深度抓取组件文档
请使用 fetch_link_documentation 获取 Ant Design 按钮组件
URL: https://ant.design/components/button
depth: 2
2. 研究完成后保存
用户:"把这次 Ant Design 的研究结果记录下来"
AI 自动:整理讨论内容 → 保存组件用法和最佳实践💬 技术讨论记录
在技术讨论过程中或结束后:
用户:"保存这次对话"或"记住刚才的解决方案"
AI 自动:
- 提取问题和解决方案
- 整理代码示例
- 记录决策过程
- 保存为结构化文档🔍 故障排除
❌ 重启后看不到 MCP 工具
解决方法:
检查 Cursor MCP 配置是否正确
确保网络连接正常(需要从 npm 下载)
完全关闭并重启 Cursor
查看 Cursor 的开发者工具是否有错误信息
❌ 网页抓取返回空内容
可能原因:
目标网站有反爬虫机制
网络连接问题
URL 格式错误
解决方法:
检查 URL 格式(需包含 http:// 或 https://)
尝试不同的网站测试
使用简单的静态网站进行测试
❌ 对话记忆无法保存
可能原因:
当前工作目录没有写权限
磁盘空间不足
.cursor目录创建失败
解决方法:
检查当前工作目录的写权限
确保磁盘有足够空间
手动创建
.cursor目录测试查看是否有防病毒软件阻止文件创建
📄 许可证
MIT License
🎉 开始使用
现在就可以开始:
配置 Cursor: 添加上面的 MCP 配置
重启 Cursor
测试功能:
使用
fetch_link_documentation获取网页文档说"保存这次对话"测试智能记忆功能
祝你使用愉快!🚀
如需帮助,请在 GitHub 提交 Issue。
Available Tools
3 toolsfetch_link_documentationC
Fetch and analyze documentation from a website link, extracting all available components, APIs, and usage examples
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | How deep to crawl links (0-3, default: 1) | |
| selector | No | Optional CSS selector to focus on specific content | body |
| url | Yes | The URL to fetch documentation from (e.g., WindUI documentation) |
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 of behavioral disclosure. It mentions 'fetch and analyze' and 'extracting all available components', but lacks details on rate limits, authentication needs, error handling, output format, or whether it modifies data. For a tool that interacts with external websites and performs analysis, this is a significant gap in 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?
The description is a single, efficient sentence that front-loads the core purpose ('fetch and analyze documentation') and specifies key outputs ('components, APIs, and usage examples'). There is zero waste or redundancy, making it highly concise and well-structured for quick comprehension.
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?
Given the tool's complexity (fetching and analyzing external web documentation), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like network dependencies, analysis methods, or return values, leaving the agent with insufficient context for reliable use. A more comprehensive description is needed to compensate for missing structured data.
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 three parameters (url, depth, selector) with descriptions and defaults. The description adds no additional meaning beyond what the schema provides, such as examples of valid URLs or practical use cases for depth/selector. Baseline 3 is appropriate when the schema does the heavy lifting.
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 verb 'fetch and analyze' and the resource 'documentation from a website link', with specific components mentioned ('components, APIs, and usage examples'). It distinguishes from sibling tools like 'get_cursor_memories' and 'save_cursor_memory' by focusing on external web content rather than cursor memories. However, it doesn't explicitly differentiate from hypothetical similar tools (e.g., 'fetch_webpage'), so it's not a perfect 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., internet access), exclusions (e.g., non-documentation sites), or compare to other tools for similar tasks. The agent must infer usage solely from the purpose statement, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_cursor_memoriesB
Retrieve saved Cursor memories by category or tag
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category | |
| limit | No | Maximum number of memories to return | |
| tag | No | Filter by tag |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves memories but offers no details on permissions required, rate limits, pagination behavior, or what happens if no filters are applied. This leaves significant gaps in understanding how the tool behaves beyond basic functionality.
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 a single, efficient sentence that directly states the tool's purpose and key filtering options. It is front-loaded with essential information and contains no redundant or unnecessary details, making it highly concise and well-structured.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what a 'Cursor memory' entails, the return format, or error handling. For a tool with 3 parameters and no structured behavioral hints, more context is needed to fully understand its operation and limitations.
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 schema description coverage is 100%, so the input schema already documents all parameters (category, limit, tag) with descriptions. The description adds marginal value by mentioning filtering by category or tag, but doesn't provide additional context like format examples or interaction effects between parameters. Baseline 3 is appropriate as the schema handles most documentation.
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 action ('Retrieve') and resource ('saved Cursor memories'), making the purpose evident. It distinguishes from 'save_cursor_memory' by focusing on retrieval rather than creation. However, it doesn't explicitly differentiate from 'fetch_link_documentation', which might also involve retrieval but of different resources.
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 description implies usage for filtering memories by category or tag, but provides no explicit guidance on when to use this tool versus alternatives like 'fetch_link_documentation'. It mentions filtering options but lacks context on prerequisites, exclusions, or specific scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_cursor_memoryA
Save conversation summary or important information to Cursor memory files. IMPORTANT: The model should first summarize the conversation or information into a well-formatted document before calling this tool. The content should be properly structured with markdown formatting for better readability.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Category for organization: 'conversation' (对话记录), 'documentation' (技术文档), 'code-patterns' (代码模式), 'project-notes' (项目笔记) | conversation |
| content | Yes | Well-formatted and summarized content in markdown format. Should include: main points, key insights, code examples (if any), decisions made, and actionable items. The model should process and structure the information before saving. | |
| tags | No | Relevant tags for better searchability (e.g., ['react', 'hooks'], ['api', 'design'], ['meeting', 'decisions']) | |
| title | Yes | Clear, descriptive title for the memory entry (e.g., 'React Hooks 学习总结', 'API 设计讨论摘要') |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this is a write operation ('Save'), implies persistence to files, and specifies formatting requirements (markdown, structured content). However, it lacks details on permissions, error handling, or file storage behavior, leaving some gaps.
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, followed by critical usage instructions. Both sentences earn their place by providing essential guidance without redundancy, making it efficient and well-structured.
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?
Given no annotations and no output schema, the description adequately covers the tool's purpose and usage. It addresses key aspects like content formatting and pre-call summarization. However, it could improve by mentioning potential side effects or response expectations, slightly reducing completeness.
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 parameters thoroughly. The description adds minimal value beyond the schema, only reinforcing that content should be 'well-formatted and summarized' in markdown, which aligns with schema details. Baseline 3 is appropriate as the schema does the heavy lifting.
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 verb ('Save') and resource ('conversation summary or important information to Cursor memory files'), distinguishing it from siblings like 'fetch_link_documentation' (retrieving) and 'get_cursor_memories' (reading). It specifies the type of content being saved, making the purpose explicit and distinct.
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 description provides explicit usage instructions: 'The model should first summarize the conversation or information into a well-formatted document before calling this tool.' It also implies when to use it (for saving summarized content) versus alternatives like 'get_cursor_memories' for retrieval, offering clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool has a clearly distinct purpose with no overlap. fetch_link_documentation handles web documentation extraction, get_cursor_memories retrieves saved memories, and save_cursor_memory stores new memories. The domains (web analysis vs. memory management) and actions (fetch, get, save) are completely separate, eliminating any risk of misselection.
The tools follow a consistent verb_noun pattern with snake_case throughout (fetch_link_documentation, get_cursor_memories, save_cursor_memory). The minor deviation is that two tools use plural 'memories' while one uses singular 'memory', but this doesn't affect readability or predictability.
With only 3 tools, the server feels thin for a 'Link MCP' server that implies broader link/documentation capabilities. While the tools cover distinct functions, the count is borderline low for a server that might be expected to handle more link-related operations beyond just documentation fetching and memory management.
There are significant gaps in the tool surface for a link/documentation server. While documentation fetching and memory tools exist, there's no basic link validation, metadata extraction, content summarization without saving, or other common link processing operations. The memory tools are well-covered, but the link/documentation domain is severely incomplete.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Turn any URL into clean Markdown and structured data. Scrape, crawl, search and extract.
Web scraping for AI agents. Converts URLs to clean, LLM-ready Markdown with anti-bot bypass.
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
- AlicenseNot gradedqualityCmaintenanceEnables web scraping and crawling capabilities for LLM clients, supporting single-page scraping, multi-page website crawling, and web search with multiple engines (Playwright, Cheerio, Puppeteer) and flexible output formats including markdown, HTML, text, and screenshots.146MIT
- FlicenseNot gradedqualityDmaintenanceEnables AI assistants to crawl websites, extract and store web content with semantic search capabilities using vector embeddings, and retrieve information through natural language queries with tag-based filtering and intelligent content cleaning.
- FlicenseNot gradedqualityDmaintenanceEnables crawling and extracting clean content from documentation websites with optional LLM-powered analysis for intelligent summaries, code example extraction, and content classification.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lijianye521/link-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server