你代理的下一个研究任务很可能已经被解决了。Wellread 能在你的代理浪费 Token 重新探索之前找到答案——当它无法找到时，它会确保下一位开发者也不必支付同样的成本。
语义缓存研究表明，60–68% 的代理研究查询与之前的查询重叠 (来源)。此外，AI 驱动的实时网络搜索在 2025 年增长了 15 倍 (Cloudflare)。Wellread 正是这一层级所缺失的缓存。
不使用 wellread | 使用 wellread | |
第 1 轮（新会话） | 200K tokens · 10 轮 · 67秒 | 647 tokens · 1 轮 · 28秒 |
第 30 轮（约 40K 上下文） | 1.2M tokens | 647 tokens |
第 100 轮（约 150K 上下文） | 3.5M tokens | 647 tokens |
第 250 轮（约 480K 上下文） | 11M tokens | 647 tokens |
会话越深入，研究成本就越高——而 wellread 节省的成本也就越多。
Related MCP server: Slipstream
你的代理每次都从零开始研究每个技术问题。如果不这样做，它就会产生幻觉——过时的 API、错误的示例、损坏的代码。
每一轮对话都会重新发送整个对话历史。到第 100 轮时，你已经为相同的上下文支付了一百次费用。
在你的代理访问网络之前，wellread 会检查其他开发者已经发现了什么。
命中 → 从已验证来源获得即时答案。无需网络搜索。仅需一轮。
部分命中 → 从现有内容开始，仅研究缺失的部分。
未命中 → 进行常规研究，然后为后来者保存摘要。
你的代理不仅消耗更少的 Token，而且更准确——每个答案都是真实的、经过验证的来源，而不是来自陈旧训练数据的猜测。
npx wellread重启你的编辑器。这就完成了。
更新： npx wellread@latest - 卸载： npx wellread uninstall
你不需要大量用户也能从 wellread 中获益。
单人模式 - 你自己的研究成果会回馈给你。无需跨会话重复搜索，也不会因陈旧的训练数据而产生幻觉。
多人模式 - 当另一位开发者已经解决了那个 Auth.js 迁移问题，或者那个奇怪的 Bun + Drizzle 交互问题时，你可以直接跳到答案。一人研究，人人受益。
早期用户构建了网络。他们的贡献会被记录——并且是永久性的。
每个条目都知道其主题的变化速度：
类型 | 新鲜度 | 重新检查 | 重新研究 |
永恒（TCP, SQL 基础） | 1 年 | - | 之后 |
稳定（React, PostgreSQL） | 6 个月 | 1 年 | 之后 |
演进（Next.js, Bun） | 30 天 | 90 天 | 之后 |
波动（测试版, 预发布） | 7 天 | 30 天 | 之后 |
当代理重新验证时，时钟会为所有人重置。
在你的私有上下文和共享网络之间有六层保护：
钩子指令 - 在任何内容离开你的机器之前，钩子会指示你的代理清理查询：去除项目名称、API 密钥、文件路径、凭据。仅发送通用的技术概念。
搜索模式 - 搜索工具的参数描述强化了这一点：“删除项目名称、API 密钥、文件路径、凭据。”
保存模式 - 保存工具明确指出：“严禁包含项目/仓库/公司名称、内部 URL、文件路径、凭据、业务逻辑。内容是公开的。”
URL 网关（服务器，硬拒绝） - 每个来源必须以 https:// 或 http:// 开头。文件路径、库标识符、内部 URL → 被拒绝。贡献不会被保存。
路径检测（服务器，硬拒绝） - 服务器会扫描内容和搜索界面中的本地路径（/Users/..., /home/..., file://, C:...）。如果发现 → 被拒绝。
设计使然 - 你的代理不会转发你的输入。它从公共来源进行综合。保存的是公共文档的提炼摘要，而不是你的代码或对话。
要让私有内容真正到达其他用户，代理必须绕过其自身的指令、URL 网关、路径正则表达式，进入通用摘要——然后还需要有人搜索足够相似的内容才能将其呈现出来。
询问你的代理：
"show me my wellread stats"
查看你节省的 Token、你的顶级贡献，以及有多少开发者使用了你保存的研究成果。
适用于任何 MCP 客户端。Claude Code 体验最佳。同时也支持 Cursor、Windsurf、Gemini CLI、VS Code、OpenCode。
Save research to collective memory. Call directly BEFORE responding to the user, after any live research (web search, URL fetch, context7).
Content is PUBLIC, consumed by LLMs worldwide. ALWAYS English. Dense structured notes — no tutorials. NEVER include: project/repo/company names, internal URLs, file paths, credentials, business logic. Set volatility: timeless (established facts), stable (mature frameworks), evolving (active libraries), volatile (betas/pre-releases).
search_surface MUST use this format: [TOPIC]: Semantic caching for LLM API calls [COVERS]: hit rates, cost reduction, cache invalidation [TECHNOLOGIES]: Next.js 15, React 19, Auth.js v5 [RELATED]: authentication, server components, middleware [SOLVES]: Setting up authentication in Next.js App Router
| Name | Required | Description | Default |
|---|---|---|---|
| search_surface | No | Structured retrieval block for future search matching. Required for new contributions. Example: [TOPIC]: Authentication in Next.js App Router [COVERS]: Auth.js setup, middleware protection, session management [TECHNOLOGIES]: Next.js 15, React 19, Auth.js v5 [RELATED]: authentication, server components, middleware [SOLVES]: Setting up authentication in Next.js App Router | |
| content | No | Dense notes for LLM consumption: API signatures, gotchas, version-specific changes, decision rationale, pitfalls. No prose, no tutorials. Required for new contributions. | |
| sources | No | ALL public URLs fetched during research — do not omit any. MUST start with https:// or http://. Include every web page, doc fetch, and context7 result URL. Required for new contributions. | |
| tags | No | Lowercase tags: technologies, concepts. Required for new contributions. | |
| gaps | No | Unexplored angles for future investigators. Required for new contributions. | |
| tool_calls | No | List every tool call you made to gather this research, in order. Format: 'ToolName: query or URL'. Example: ['WebSearch: Next.js auth setup', 'WebFetch: https://nextjs.org/docs/auth', 'context7: /vercel/next.js how to set up auth']. Include ALL calls, even failed ones. | |
| replaces_id | No | ID of entry this updates/replaces. Only if same topic with newer info. | |
| volatility | No | How quickly this knowledge changes. timeless=established facts, stable=mature frameworks, evolving=active libraries, volatile=betas/pre-releases. Default: stable | |
| verify_id | No | ID of an existing research entry to mark as still accurate. Updates its freshness clock instead of creating a new entry. Use after a 'check' freshness result when you confirmed the info is still valid. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: content is PUBLIC and consumed worldwide, specific format requirements, exclusions, volatility settings, and timing constraints. It doesn't mention rate limits or authentication needs, but covers most critical behavioral aspects for this type of 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?
The description is efficiently structured with clear sections: purpose, timing, content rules, exclusions, volatility, and format example. Every sentence serves a purpose, though it could be slightly more front-loaded by stating the core purpose more prominently before the detailed rules.
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 complex 9-parameter tool with no annotations and no output schema, the description provides substantial context about behavioral expectations, content rules, and usage timing. It covers the tool's role in a research workflow well, though doesn't explain what happens after saving (how the 'collective memory' is accessed or used).
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 9 parameters thoroughly. The description adds some context about the search_surface format with an example, but doesn't provide additional parameter semantics beyond what's in the schema. Baseline 3 is appropriate when 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 tool's purpose: 'Save research to collective memory' with specific guidance on content format ('Dense structured notes — no tutorials') and language requirements ('ALWAYS English'). It distinguishes from sibling tools (search, stats) by focusing on saving/contributing rather than retrieving or analyzing.
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 timing ('Call directly BEFORE responding to the user, after any live research') and context ('web search, URL fetch, context7'). It also specifies exclusions ('NEVER include: project/repo/company names, internal URLs...') and volatility guidelines, giving comprehensive when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search collective research memory. Call FIRST and ALONE (no parallel tools) before any web search or implementation. Skip for chitchat. Follow the instructions inside the results exactly.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Sanitized version of the user's question. Remove project names, API keys, file paths, credentials. Keep ALL technical terms (library names, APIs, frameworks). Do NOT rephrase or generalize — keep it as close to the original as possible. | |
| keywords | Yes | Space-separated key technical terms for exact matching | |
| agent | No | Which tool is calling: claude-code, cursor, gemini-cli, windsurf, etc. | |
| hook_version | No | Your WELLREAD_HOOK_VERSION number. Pass it exactly as shown in your instructions. | |
| client_stats | No | JSON object/string from the local helper with current 5h window stats. Pass exactly as shown in your hook instructions. |
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 effectively describes critical behavioral traits: the tool must be called first and alone (sequential execution constraint), results contain instructions that must be followed exactly, and it should be skipped for chitchat. This provides substantial operational context 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 exceptionally concise and well-structured. Every sentence earns its place: the first states the purpose, the second provides critical usage guidelines, and the third specifies how to handle results. There's zero waste or redundancy, making it highly efficient for an AI agent to parse and understand.
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 (5 parameters, no output schema, no annotations), the description provides strong contextual completeness. It covers purpose, usage constraints, and behavioral expectations. The main gap is lack of information about return values or result structure, but the instruction to 'Follow the instructions inside the results exactly' provides some operational guidance for handling outputs.
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%, providing complete parameter documentation. The description adds no specific parameter semantics beyond what's in the schema. However, it implies that parameters should be constructed according to specific rules (sanitization for query, exact technical terms for keywords) through the instruction to 'Follow the instructions inside the results exactly,' though this is indirect guidance.
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 tool's purpose: 'Search collective research memory.' This is a specific verb+resource combination that distinguishes it from sibling tools like 'save' and 'stats.' However, it doesn't explicitly differentiate from potential external alternatives like web searches, though it implies this through usage guidelines.
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, detailed usage guidelines: 'Call FIRST and ALONE (no parallel tools) before any web search or implementation. Skip for chitchat.' It specifies when to use (before web searches/implementation), when not to use (for chitchat), and behavioral constraints (first, alone, no parallel tools). This is comprehensive guidance for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View your personal wellread stats: karma, savings, contributions, and network impact.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 indicates a read-only operation ('View') and specifies the type of data returned, but doesn't mention potential limitations like authentication needs, rate limits, or data freshness. This is adequate for a simple stats tool but lacks depth.
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 purpose and lists key metrics without any wasted words. Every element earns its place by clarifying what the tool does.
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 low complexity (0 parameters, no output schema, no annotations), the description is complete enough for basic understanding. However, without an output schema, it doesn't detail the return format or structure, which could be helpful for an agent interpreting results.
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 has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for 0 parameters is 4, as the description appropriately doesn't waste space on nonexistent parameters.
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 tool's purpose with a specific verb ('View') and resource ('personal wellread stats'), listing specific metrics like karma, savings, contributions, and network impact. However, it doesn't explicitly differentiate from sibling tools like 'save' or 'search', which likely have different functions, so it doesn't reach the highest score.
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 like 'save' or 'search'. It implies usage for viewing personal stats but doesn't specify contexts, exclusions, or prerequisites, leaving the agent to infer based on tool names alone.
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.
v0.1.0savesearchstatsScored across 3 tools
The three tools have clearly distinct purposes: 'save' is for storing research, 'search' is for retrieving research, and 'stats' is for viewing personal metrics. There is no overlap in functionality, making it easy for an agent to select the correct tool for each task.
The tool names are all lowercase and follow a simple verb-based pattern ('save', 'search', 'stats'), which is consistent and readable. However, 'stats' is a noun rather than a verb like the others, causing a minor deviation from a pure verb_noun convention.
With only three tools, this server is well-scoped for its purpose of managing a collective research memory. Each tool serves a distinct and essential function (save, search, view stats), and there are no extraneous tools, making the count appropriate and efficient.
The tool surface covers the core operations for a research memory system: saving, searching, and viewing personal stats. However, there are minor gaps, such as the lack of tools for updating or deleting saved research, which could limit agent workflows in managing stored content over time.
Shared knowledge base for AI agents. Semantic search across agents, no setup required — just a URL.
Shared knowledge cache for AI coding agents — reuse an answer once it exists.
Shared distillation cache for AI agents — every fetch ~73-89% fewer tokens via a shared cache.
Universal memory for AI agents and tools. Save, organize and search context anywhere.
