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., "@KnowS MCP Server search for evidence on type 2 diabetes treatments"
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.
KnowS 医学证据检索与分析平台的 MCP (Model Context Protocol) Server。
本包发布在 GitHub Packages，需要先配置 npm registry。在 ~/.npmrc 中添加：
//npm.pkg.github.com/:_authToken=YOUR_GITHUB_TOKEN
@PancrePal-xiaoyibao:registry=https://npm.pkg.github.com
YOUR_GITHUB_TOKEN需要有read:packages权限。
变量 | 必填 | 说明 |
| 是 | KnowS API 密钥 |
| 否 | API 地址，默认 |
在 ~/.claude/settings.json 或项目 .claude/settings.json 中添加：
{
"mcpServers": {
"knows": {
"command": "npx",
"args": ["@PancrePal-xiaoyibao/knows-mcp-server"],
"env": {
"KNOWS_API_KEY": "your_api_key",
"KNOWS_API_HOST": "https://api.nullht.com"
}
}
}
}在 ~/Library/Application Support/Claude/claude_desktop_config.json（macOS）中添加：
{
"mcpServers": {
"knows": {
"command": "npx",
"args": ["@PancrePal-xiaoyibao/knows-mcp-server"],
"env": {
"KNOWS_API_KEY": "your_api_key",
"KNOWS_API_HOST": "https://api.nullht.com"
}
}
}
}# 通过 npx
KNOWS_API_KEY=your_key npx @PancrePal-xiaoyibao/knows-mcp-server
# 或全局安装后运行
npm install -g @PancrePal-xiaoyibao/knows-mcp-server
KNOWS_API_KEY=your_key knows-mcp-serverRelated MCP server: Agent Care MCP
# 安装依赖
npm install
# 使用 bun 开发（热重载）
KNOWS_API_KEY=your_key bun run dev
# 构建
npm run build
# 运行构建产物
KNOWS_API_KEY=your_key npm start工具 | 说明 |
| AI 检索，根据问题返回相关医学证据列表 |
| 单篇证据 AI 概要总结 |
| 获取所有证据的 AI 总结 |
| 获取证据被引用的原文内容 |
| 基于问题和证据生成场景总结 |
| 场景总结（流式收集） |
| 证据自动化标签提取 |
| 英文文献详情 |
| 中文文献详情 |
| 指南详情 |
| 会议详情 |
| 历史提问列表 |
| 文献解读历史列表 |
| 通过 PDF 创建新证据 |
项目附带了推荐的系统提示词 SYSTEM_PROMPT.md，用于指导 AI 助手基于 KnowS 工具进行结构化的医学文献调研。
# 更新 package.json 中的 version 后
git tag v0.x.x
git push origin v0.x.x推送 v* tag 后，GitHub Actions 会自动运行测试并发布到 GitHub Packages。
AI 检索：用户提问，返回与该问题相关的医学证据列表
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 用户提问的问题文本 | |
| data_scope | Yes | 检索范围的证据类型 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it returns a list of evidence, but with no annotations provided, it fails to disclose critical behavioral traits such as query language support, result ordering, pagination, or any side effects. The agent lacks information about what happens with the query or data_scope parameters beyond the schema.
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, short sentence that efficiently conveys the core function. It is front-loaded and concise. However, it could be slightly more structured by including usage hints, but it is not overly verbose.
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 has no output schema and only two parameters, the description is minimal. It explains the overall purpose but does not cover return format, error conditions, or how the tool integrates with siblings. The description is adequate for a simple search tool but leaves gaps.
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 coverage is 100% with descriptions for both 'query' and 'data_scope'. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate. The enum values for 'data_scope' are already clear in the schema.
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 performs AI search and returns a list of medical evidence related to a user question. It specifies the verb '检索' (search) and the resource '医学证据' (medical evidence), which is sufficiently clear. However, it does not explicitly differentiate itself from sibling tools like 'all_evidence_summary' or 'answer', which also deal with evidence or answers.
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 when a user has a question and wants evidence, but it provides no explicit guidance on when to use this tool versus alternatives like 'all_evidence_summary' or 'answer_stream'. There is no mention of prerequisites, exclusion criteria, or context boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取所有证据的单篇 AI 总结（收集完整的流式响应后返回）
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the tool collects the complete streaming response before returning, indicating it aggregates an async stream. However, since no annotations are provided, the description carries the full burden and does not cover permissions, side effects, or rate limits.
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, concise sentence that front-loads the key action and important behavioral detail (streaming response collection).
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 parameters and no output schema, the description adequately explains the tool's purpose and behavior. It could optionally clarify what 'all evidence' refers to or the expected output format, but it is sufficient for an agent to select this tool.
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 zero parameters, so the description's meaning about the tool's purpose and behavior adds sufficient value beyond the empty schema.
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 retrieves a single AI summary of all evidence, and mentions the streaming response behavior, which distinguishes it from sibling tools like evidence_summary.
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 does not specify when to use this tool versus alternatives like evidence_summary or answer_stream, nor does it provide guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
基于问题和检索出来的证据，生成场景总结（非流式）
| Name | Required | Description | Default |
|---|---|---|---|
| question_id | Yes | 问题 ID（来自 ai_search 返回的 question_id） | |
| answer_type | Yes | 回答类型：临床、学术研究、科普 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the basic function without mentioning side effects, auth requirements, rate limits, or return format.
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 one concise sentence that front-loads the purpose. It is efficient but could benefit from structured formatting for easier parsing.
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?
Without an output schema, the description should explain the return value or summary format. It only covers basic functionality, leaving gaps about prerequisites and edge cases.
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 coverage is 100% with descriptions for both parameters. The description adds no extra meaning beyond the schema, so baseline of 3 is appropriate.
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 generates a scenario summary based on question and evidence, with the non-streaming qualifier distinguishing it from the sibling tool answer_stream.
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 when to use this tool (non-streaming) versus answer_stream (streaming) but does not explicitly state when-not-to-use or provide alternative names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
基于问题和检索出来的证据，生成场景总结（收集完整的流式响应后返回）
| Name | Required | Description | Default |
|---|---|---|---|
| question_id | Yes | 问题 ID | |
| answer_type | Yes | 回答类型 |
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 discloses that the tool collects the full streaming response before returning, but does not mention any destructive or authorization requirements, rate limits, or other behavioral traits.
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 sentence that conveys core functionality concisely. However, it could be structured with separate statements for purpose and behavior for easier parsing.
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 low complexity (2 required params, no output schema), the description covers the basic purpose and streaming behavior. However, it lacks details on the expected output format and any dependencies (e.g., evidence must be retrieved beforehand).
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 coverage is 100%, and parameter descriptions are clear. The tool description does not add significant meaning beyond the schema, such as explaining the effect of different answer_type values, so baseline score of 3 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?
Description specifies 'generate scenario summary' based on questions and evidence, and mentions streaming response, differentiating it from sibling tools like 'answer' and 'evidence_summary'. However, '场景总结' (scenario summary) is somewhat vague and could be clarified further.
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 explicit guidance on when to use this tool versus alternatives like 'answer' or 'evidence_summary'. The description implies you need a question and retrieved evidence but does not state prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
对证据进行自动化标签提取（如研究类型、疾病领域、样本量等）
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | 文本内容（与 evidence_id 二选一） | |
| evidence_id | No | 证据 ID（与 content 二选一，用于需要全文的标签类型） | |
| tagging_type | Yes | 标签类型 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full responsibility for behavioral disclosure. It does not indicate whether the tool is read-only, modifies the database, requires authentication, or has rate limits. The phrase 'automated tag extraction' suggests a read operation, but this is not confirmed.
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?
Single sentence of 20 Chinese characters, efficient and front-loaded with the verb 'extract'. No redundant information.
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 output schema, the description should clarify return format or side effects. It lacks guidance on choosing between content and evidence_id, and does not address whether the tool stores tags or just returns them. The tool has 3 parameters with conditional requirements, but the description omits this complexity.
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 coverage is 100%, so baseline is 3. The description adds examples of tag types (e.g., research type, disease area) that map to enum values, but does not add depth beyond the schema's minimal descriptions. No explanation of the mutual exclusivity of content and evidence_id.
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?
Description clearly states the tool performs automated tag extraction for evidence, with examples of tag categories. It distinguishes from sibling tools that focus on search, summaries, or PDF creation, making its purpose clear.
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 explicit guidance on when to use this tool versus alternatives. The description does not specify that content or evidence_id must be provided, or which tag types are appropriate for different scenarios. Users must infer usage from parameter descriptions alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
通过上传 PDF 文件创建新的证据
| Name | Required | Description | Default |
|---|---|---|---|
| pdf_base64 | Yes | PDF 文件的 Base64 编码内容 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the creation action via PDF upload but does not mention side effects (e.g., file storage, processing time), authentication needs, rate limits, or any constraints beyond the parameter. This is insufficient for a creation 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 a single concise sentence with no wasted words. It is front-loaded with the core purpose. This is appropriate given the tool's simplicity.
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?
Despite having only one parameter and no output schema, the description lacks completeness. It does not explain what 'new evidence' means in the system context, whether the PDF is stored or parsed, or any return value. A minimally complete description for a creation tool should at least mention the expected outcome or confirmation.
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 coverage is 100% (one parameter described in schema). The tool description adds no new information beyond the schema's parameter description ('Base64 encoded content of PDF file'). Since coverage is high, baseline is 3; the description does not elevate it further.
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 action: creating new evidence by uploading a PDF. The verb '创建' (create) and resource '证据' (evidence) are specific, and the method '通过上传 PDF 文件' (by uploading PDF file) distinguishes it from sibling tools like ai_search or evidence_summary, which are read-only or retrieval focused.
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, no prerequisites, no exclusions, and no mention of when not to use it. It is a simple declarative statement of functionality without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
返回单篇证据被引用的原文部分（高亮内容）
| Name | Required | Description | Default |
|---|---|---|---|
| evidence_id | Yes | 证据 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond the basic purpose. It does not mention whether the tool is read-only, what exact format the returned content has, or any limitations (e.g., only works for certain evidence types).
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 sentence that is concise and front-loaded. It efficiently conveys the core purpose but could be slightly improved by clarifying what 'highlighted content' entails without adding unnecessary length.
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 simplicity (one required parameter, no output schema), the description provides adequate context for basic understanding. However, because no output schema exists, the description should ideally describe the structure or format of the returned content to ensure 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?
The input schema includes one parameter (evidence_id) with a description of '证据 ID'. The tool description mentions '单篇证据', which aligns with the parameter meaning. Schema description coverage is 100%, so the description adds no extra semantic value beyond what the schema already provides.
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 function: returning the highlighted original text referenced by a single piece of evidence. It uses a specific verb-resource combination and distinguishes well from siblings like evidence_summary and create_evidence_by_pdf.
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 context (when needing highlighted content for an evidence) but does not provide explicit guidance on when to use this tool instead of alternatives such as evidence_summary or all_evidence_summary. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
对单篇证据进行 AI 概要总结
| Name | Required | Description | Default |
|---|---|---|---|
| evidence_id | Yes | 证据 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure, but it only restates the tool's purpose without details on model, cost, or output format.
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?
Single sentence is concise and front-loaded, though slightly under-specified.
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 single-parameter tool without output schema, the description is minimally sufficient but lacks hints about return behavior.
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 coverage is 100%, and the description adds no additional meaning beyond the schema's 'evidence ID' explanation.
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 (summarize), resource (single evidence), and action (AI summary), distinguishing it from sibling 'all_evidence_summary'.
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 explicit when-to-use or alternatives provided; usage is implied but lacks contextual guidance or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取医学指南的详细信息
| Name | Required | Description | Default |
|---|---|---|---|
| evidence_id | Yes | 证据 ID | |
| translate_to_chinese | No | 是否翻译标题为中文，默认 false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose read-only behavior, error handling, or required permissions. It only states 'get detailed information', which is insufficient for understanding tool 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?
The description is a single concise sentence with no redundant information. It is front-loaded and efficient.
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 simplicity and presence of similar sibling tools, the description lacks details about the output, how it differs from evidence summaries, and what 'detailed information' entails. Incomplete for proper tool selection.
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 coverage is 100%, with descriptions for both parameters. The description adds no extra meaning beyond the schema, meeting the baseline but not enhancing usability.
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 'Get detailed information of medical guide', which is a specific verb+resource. However, it does not differentiate from sibling tools like evidence_summary or get_paper_cn, leaving ambiguity.
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 guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites or scenarios, making it hard for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取医学会议记录的详细信息
| Name | Required | Description | Default |
|---|---|---|---|
| evidence_id | Yes | 证据 ID | |
| translate_to_chinese | No | 是否翻译标题和摘要为中文，默认 false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is read-only, destructive, or requires authentication. It only states the basic function.
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 concise sentence with no wasted words. It is appropriately front-loaded, though lacks structured formatting.
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 has two parameters and no output schema, the description is minimal. It does not mention the output format, how the tool fits with siblings, or any additional context for effective use.
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?
Both parameters have descriptions in the schema (100% coverage), so the description adds no additional semantic value. Baseline of 3 is appropriate.
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 retrieves detailed information of medical meeting records, specifying a verb and resource. It distinguishes from sibling tools focused on papers (e.g., get_paper_cn, get_paper_en). However, it does not explicitly differentiate from other evidence-related tools.
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, no context for typical use cases, and no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取中文文献的详细信息
| Name | Required | Description | Default |
|---|---|---|---|
| evidence_id | Yes | 证据 ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as side effects, authentication requirements, or whether it is read-only.
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 concise sentence with no extraneous information. However, it could be restructured to front-load key details.
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 output schema, the description should explain what data is returned, but it does not. The tool has one parameter, yet the description lacks completeness about the operation's scope.
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 coverage is 100%, and the description adds no additional meaning beyond the schema. The parameter 'evidence_id' is described in the schema, but the description does not elaborate on its purpose or format.
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 retrieves detailed information of Chinese literature, distinguishing it from the likely English counterpart 'get_paper_en'. However, it could be more specific about what '详细信息' entails.
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 guidance on when to use this tool versus alternatives like 'get_paper_en'. The description does not provide context or scenarios for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取英文文献的详细信息（标题、摘要、影响因子、分区等）
| Name | Required | Description | Default |
|---|---|---|---|
| evidence_id | Yes | 证据 ID | |
| translate_to_chinese | No | 是否翻译标题和摘要为中文，默认 false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose any behavioral traits such as read-only nature, required permissions, rate limits, or side effects. The description only lists returned fields, lacking transparency 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, concise sentence front-loaded with the verb 'get'. No superfluous content; every word adds value.
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 retrieval tool with 2 parameters and no output schema, the description is adequate but not thorough. It lacks details on authentication, error handling, or output format, leaving some gaps for an AI agent.
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% with clear parameter descriptions. The tool description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
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 retrieves detailed information for English literature, listing specific fields (title, abstract, impact factor, classification). It distinctly separates from the sibling get_paper_cn tool by language, making the purpose unambiguous.
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 usage context is implied by the tool name and sibling list (choose this for English papers, get_paper_cn for Chinese), but there is no explicit guidance on when to use this tool versus alternatives or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取用户的单篇文献 AI 解读历史记录，支持时间范围和分页
| Name | Required | Description | Default |
|---|---|---|---|
| from_time | No | 起始时间戳（毫秒） | |
| to_time | No | 终止时间戳（毫秒） | |
| page | No | 页码，从 1 开始，默认 1 | |
| page_size | No | 每页条数，最大 50 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only mentions pagination and time range. It omits details on data limits, ordering, empty results, or side effects. The read-only nature is implied but not explicit.
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 sentence, clear and free of redundancy. It front-loads the primary purpose and key features, though some behavioral details are missing.
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 list tool with 4 parameters and no output schema, the description is adequate but incomplete. It covers what the tool does and basic options, but lacks details on return format, sorting, or maximum 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?
Schema coverage is 100%, so parameters are documented. The description adds minimal value (repeating time range and pagination support). Baseline 3 is appropriate.
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 retrieves AI interpretation history for a single piece of literature, with time range and pagination support. It specifies the verb (获取) and resource (单篇文献AI解读历史记录), distinguishing it from siblings like list_questions.
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 guidance on when to use this tool versus alternatives, nor any conditions or exclusions. It only lists features (time range, pagination) without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取用户的历史提问列表，支持时间范围和分页
| Name | Required | Description | Default |
|---|---|---|---|
| from_time | No | 起始时间戳（毫秒），例：1729246077911 | |
| to_time | No | 终止时间戳（毫秒） | |
| page | No | 页码，从 1 开始，默认 1 | |
| page_size | No | 每页条数，最大 50 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions time range and pagination but omits critical details like read-only nature, authentication needs, sorting order, or what happens with empty results.
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 concise sentence, efficient for the agent to parse. However, it lacks structural elements like bullet points or clear separation of behavior from usage.
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 output schema or annotations, the description is insufficient. It omits return value format, error handling, rate limits, or any behavioral nuances, leaving the agent with limited understanding for complex invocations.
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 coverage is 100% with descriptions for each parameter. The tool description adds 'supports time range and pagination' which slightly reinforces purpose but does not add meaning beyond the schema. Baseline 3 is appropriate.
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 retrieves the user's historical question list with time range and pagination support. It is specific but does not explicitly distinguish from sibling tools like 'answer' or 'evidence_summary', although the naming alone largely suffices.
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, nor any conditions or exclusions. It simply states what the tool does without context for decision-making.
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.2.2ai_searchall_evidence_summaryansweranswer_streamauto_taggingcreate_evidence_by_pdfevidence_highlightevidence_summaryget_guideget_meetingget_paper_cnget_paper_enlist_interpretationslist_questionsScored across 14 tools
Most tools have distinct purposes (e.g., ai_search vs. answer vs. evidence_summary). However, answer and answer_stream are clearly variants of the same operation, and all_evidence_summary and evidence_summary overlap in scope, causing slight ambiguity.
Naming patterns are mixed: some tools use verb_noun (get_guide, list_questions) while others use noun_verb or noun_noun (evidence_highlight, ai_search). The presence of answer and answer_stream as single verbs breaks the pattern, reducing consistency.
With 14 tools covering search, summarization, evidence management, and history, the count feels well-scoped for a medical knowledge server. Each tool serves a clear role without unnecessary redundancy.
The tool set covers core workflows like searching, answering, and summarizing, but lacks update/delete operations for evidence and does not provide listing tools for guides or meetings, leaving notable gaps in lifecycle coverage.
Source-traced evidence research for AI agents. We organise the evidence; you decide.
Medical RAG: semantic search for clinical guidelines, drug interactions, diagnoses & EHR data.
Medical RAG: semantic search for clinical guidelines, drug interactions, diagnoses & EHR data.
Search 36M+ PubMed biomedical articles and ClinicalTrials.gov studies.
