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., "@CNKI MCP Server Search for papers on deep learning"
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.
知网(CNKI)论文检索 MCP 服务 —— 让 AI 助手直接搜索和获取知网论文信息。
Tool | 说明 |
| 搜索知网论文，支持 15 种搜索类型、分页、排序 |
| 从详情页提取完整元数据（标题/摘要/作者/DOI等） |
| 按字符相似度匹配最相近的论文标题 |
Resource | 说明 |
| 列出所有可用搜索类型及别名 |
| 查看服务运行状态 |
Related MCP server: CNKI MCP Server
Python >= 3.10
uv（推荐）或 pip
Chrome 浏览器
无需手动安装，配置后自动拉取：
{
"mcpServers": {
"cnki": {
"command": "uvx",
"args": ["cnki-mcp"]
}
}
}uvx --from git+https://github.com/你的用户名/cnki-mcp cnki-mcpgit clone <repo-url> cnki-mcp
cd cnki-mcp
uv sync
# 或 pip install -e .编辑 claude_desktop_config.json:
{
"mcpServers": {
"cnki": {
"command": "uvx",
"args": ["--from", "e:\\data_agent\\cnki-mcp", "cnki-mcp"]
}
}
}编辑 Cursor 的 MCP 配置:
{
"mcpServers": {
"cnki": {
"command": "uvx",
"args": ["--from", "e:\\data_agent\\cnki-mcp", "cnki-mcp"]
}
}
}中文 | 英文别名 | 说明 |
主题 | subject, theme | 综合搜索（默认） |
篇关摘 | — | 篇名+关键词+摘要 |
关键词 | keyword, keywords | 关键词搜索 |
篇名 | title | 按标题搜索 |
全文 | fulltext, full_text | 全文搜索 |
作者 | author | 作者名搜索 |
第一作者 | first_author | 第一作者搜索 |
通讯作者 | corresponding_author | 通讯作者搜索 |
作者单位 | affiliation, institution | 机构搜索 |
基金 | fund | 基金项目搜索 |
摘要 | abstract | 摘要搜索 |
参考文献 | reference | 参考文献搜索 |
分类号 | classification | 分类号搜索 |
文献来源 | source | 期刊/来源搜索 |
DOI | doi | DOI 精确搜索 |
中文 | 英文 |
相关度（默认） | relevance |
发表时间 | time, date |
被引 | cited, citation |
下载 | download, downloads |
每次搜索建议 1-3 页，避免频繁请求触发反爬
搜索间隔建议 2-3 秒
首次运行会自动下载 ChromeDriver
打开浏览器开发者工具，检查知网搜索页/详情页的 HTML 结构
编辑 src/cnki_mcp/selectors.py，更新对应的选择器
每个字段支持多选择器回退，格式为 "策略:选择器"，策略支持 css、xpath、id
编辑 selectors.py 中的 SEARCH_TYPE_VALUES 和 SEARCH_TYPE_ALIASES 字典。
本项目的改进：
选择器配置化 — 所有 XPath/CSS 集中在 selectors.py，知网改版只需改一个文件
多选择器回退 — 每个元素有多套选择器策略，一个失败自动尝试下一个
结构化错误处理 — 自定义异常体系，每个步骤独立容错
更好的反检测 — 更多反自动化检测措施
可维护架构 — 清晰的模块分离（浏览器管理 / 选择器配置 / 业务逻辑）
去掉冗余 — 移除 FastAPI 版本，专注 MCP
MIT
根据论文标题在知网中查找最匹配的论文。使用字符相似度算法匹配第一页搜索结果中与输入标题最相似的论文。
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | 论文标题 | |
| search_type | No | 搜索类型，默认"篇名"（按标题搜索） | 篇名 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 the tool uses character similarity and only considers the first page of search results, which is a key behavioral constraint. However, it does not mention potential edge cases like no match found or whether it performs network requests.
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 two concise sentences, front-loaded with the main purpose and followed by the matching algorithm detail. Every word earns its place, with 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 the tool has an output schema, the description need not explain return values. It covers the core scope (matching on first page, using similarity) and parameters sufficiently. It omits discussion of edge cases, but the simplicity of the tool and the output schema compensate.
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 both parameters are already documented. The description adds minimal extra meaning beyond reinforcing that the title is used for matching and the default search type is '篇名'. It does not further elaborate parameter usage.
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 finds the most matching paper in CNKI based on the input title, using a character similarity algorithm on first-page search results. This specific verb+resource combination distinguishes it from siblings like search_cnki and get_paper_detail.
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 the tool is for when you have a paper title and want the best match from CNKI, but it does not explicitly mention when to use it versus alternative tools. It lacks explicit alternatives or exclusions, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取知网论文的详细信息：标题、作者、机构、摘要、关键词、DOI、来源期刊、被引次数、下载次数等。传入论文详情页 URL。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 论文详情页 URL（如 https://kns.cnki.net/kcms2/article/abstract?v=...） |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It describes the returned data fields, which is helpful, but does not mention potential access restrictions, error behavior for invalid URLs, or any side effects. As a read-only retrieval tool, the core behavior is clear, but important context is missing.
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, well-structured sentence that front-loads the purpose and lists the return fields. There is no unnecessary information, and it is easy to parse quickly.
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 one-parameter tool with an output schema, the description is fairly complete. It covers what the tool does, what input is needed, and what output can be expected. However, it lacks explicit links to sibling tools and any mention of potential failure modes or access requirements, leaving some 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?
The schema already provides a 100% description coverage for the single 'url' parameter, including an example. The tool description simply repeats '传入论文详情页 URL' without adding new meaning beyond what the schema states, so it meets the baseline but does not exceed it.
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: retrieving detailed information for a CNKI paper, listing specific fields (title, author, institution, etc.). The verb '获取' and resource '知网论文的详细信息' are specific, and it distinguishes from siblings like search_cnki and find_best_match, which are search-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 instruction '传入论文详情页 URL' makes clear that the tool requires a paper detail page URL, implying it should be used when such a URL is already available. However, it does not explicitly mention alternatives or when not to use it (e.g., when searching is needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索知网(CNKI)论文。支持主题、关键词、篇名、作者、作者单位等多种搜索类型，支持分页和排序。每次建议搜索 1-3 页，间隔 2-3 秒。
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 页码，从 1 开始，建议 1-3 页 | |
| sort | No | 排序方式: 相关度/发表时间/被引/下载 (或英文: relevance/time/cited/download) | 相关度 |
| query | Yes | 搜索关键词 | |
| page_size | No | 每页结果数，默认 20 | |
| search_type | No | 搜索类型，支持中文（主题/关键词/篇名/作者/作者单位等） 和英文别名（subject/keyword/title/author/affiliation等） | 主题 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses pagination/sorting support and cautions about page limits and intervals, hinting at rate limiting or anti-scraping behavior. However, it does not mention error handling, result formats, or other side effects, so transparency is moderate.
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 two sentences: the first defines purpose and capabilities, the second gives precise usage advice. Every word earns its place, with no redundancy or fluff.
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 search tool with 5 parameters and an output schema, the description covers the core functionality, supported search types, sorting/pagination, and practical constraints. It lacks guidance on when to use this versus sibling tools, but otherwise is sufficiently complete.
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 has 100% coverage of parameter descriptions, so baseline applies. The description reinforces search_type and pagination/sorting but adds no additional parameter-level meaning 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 searches CNKI papers with a specific verb and resource. It lists supported search types, but does not explicitly differentiate from sibling tools like find_best_match, though the focus on general search is implied.
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?
Provides practical usage guidance: '建议搜索 1-3 页，间隔 2-3 秒' (recommend searching 1-3 pages, interval 2-3 seconds). However, it does not explain when to use this vs. alternatives like get_paper_detail or find_best_match, leaving that decision implicit.
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.0find_best_matchget_paper_detailsearch_cnkiScored across 3 tools
Each tool has a clearly distinct purpose: search_cnki for general querying, get_paper_detail for retrieving metadata from a URL, and find_best_match for fuzzy title matching. There is no overlap in their primary functions, making selection unambiguous.
All tool names follow a consistent verb_noun pattern (search_cnki, get_paper_detail, find_best_match) with snake_case and action-first naming. The verbs clearly reflect the operation, and the naming style is uniform.
With 3 tools, the server is well-scoped for its purpose of searching and retrieving CNKI papers. Each tool serves a distinct need without redundancy, fitting within the ideal 3-15 range.
The tool set covers the core workflow: search for papers, retrieve details, and match specific titles. A minor gap is the lack of a direct way to browse by subject or export results, but the existing tools handle the main research workflow effectively.
Search peer-reviewed papers and research methodology guidance from your AI agent.
Search 340M+ academic papers — citation graphs, semantic similarity, and AI literature reviews.
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Scholarly search: OpenAlex, Crossref, arXiv, OpenCitations and PubMed in one endpoint.
