deepseek-litresearch

by Wang-JQ77

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation2/5
Several tools have overlapping boundaries: deep_research, plan_research, execute_research, create_research_job, and run_research_job all serve research initiation/execution with subtle workflow differences. While descriptions are detailed, an agent can easily misselect between these overlapping entry points, especially when deciding between one-shot deep_research and the plan/execute split.
Naming Consistency4/5
Most tools follow a clear verb_noun snake_case pattern such as search_literature, read_paper, list_research_jobs, and set_settings. The exceptions are scihub and ezproxy, which are bare product-style names, and deep_research, which reads more like an adjective_noun phrase than a verb-driven action.
Tool Count3/5
The listed surface exposes around 20 tools, which falls into the heavy range and feels over-scoped for a literature research server. The research-job lifecycle alone accounts for roughly ten tools, several of which duplicate the same conceptual operation.
Completeness4/5
The set provides strong domain coverage: multi-source search, full-text reading, citation chaining, settings management, connectivity diagnostics, and job persistence with CRUD operations. Minor gaps exist, such as no dedicated update endpoint for modifying a saved job, but plan_override and settings tools provide workarounds.
Average 4.2/5 across 18 of 18 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
在没有任何 annotations 的情况下，描述额外披露了关键副作用——删除任务时会同时删除进度文件，否则前端标签会永久残留；还注明这是 2026-08-29 的缺口修复，有助于理解行为原因。但未说明删除是否不可恢复，也未提权限要求，略有保留。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述简短且分三段：先讲主要功能，再讲副作用与原因，最后列参数。没有冗余信息，结构清晰、信息密度高。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
由于没有 annotations 和 output schema，描述承担全部上下文责任。它涵盖了删除动作、副作用和参数，但未涉及删除的前提状态（如运行中的任务是否可删）、与 cancel_research_job 的选择条件，以及调用后的返回结果。对于一个删除工具来说基本可用，但仍有明显信息缺口。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema 只有一个必需参数 job_id，类型为 string；描述在 Args 中说明 job_id 为任务 id，与 schema 标题 Job Id 基本重复，没有补充格式、示例或来源。虽然单一参数本身简单，重复解释也算提供基本语义，但价值有限。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述使用明确的动词「删除」和资源「任务」表达操作目标，并说明删除任务的同时会删除进度文件（pill），因此能清楚告知该工具的作用。但没有明确与兄弟工具 cancel_research_job 做区分，所以未达到 5 分。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述未说明何时应该使用删除而非取消任务，也没有提及前置条件或替代工具。兄弟工具中存在 cancel_research_job，但描述没有给出在什么状态下应选择删除、什么状态下应选择取消，因此缺少使用时机指引。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavior disclosure. It adds valuable context by explaining that the returned configuration merges settings.json, environment variables, and defaults. However, it does not disclose potential staleness, error behavior, or whether the plugin must be initialized first, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the purpose and target categories, the second defines the return value semantics. Every word earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with no output schema, the description covers the essential call contract: what it retrieves and the structure of the returned configuration. It could tie usage to set_settings or warn about precedence, but those are more usage-related than completeness gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. There is no parameter information to provide, and the description does not need to explain any. This is appropriate for a parameterless getter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: viewing current plugin settings, enumerating specific categories (Sci-Hub / EZProxy / TDM API / report language). It identifies the resource precisely and explains the return value is the effective merged configuration. However, it does not explicitly differentiate it from sibling tools like get_config_guide or set_settings, relying on the name to imply read vs. write.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention that this is the read companion to set_settings, nor does it advise using it before modifying settings. The agent must infer usage context entirely from the name and purpose, which is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It does state the tool is a query ('查询'), implying a read-only operation, and says it returns status and results. However, it does not disclose potential side effects, whether the query blocks, polling behavior, or error/return semantics. The 'M10' label is cryptic and adds no behavioral value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences, with the purpose stated up front and the parameter explanation immediately following. There is no redundant content. The only minor blemish is the unexplained 'M10', but it does not meaningfully hurt comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter helper, the description covers the core need: what the tool does and where the parameter comes from. However, with no annotations and no output schema, it does not describe the response format, whether results are returned inline, or how this differs from the sibling get_status. That leaves some ambiguity for an agent deciding between tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines job_id as a bare string with no description. The description adds meaningful semantics by specifying that the job_id is the one returned by create_research_job, deep_research, or plan_research. Given 0% schema description coverage, this is valuable compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: querying job status and results ('查询任务状态与结果'), using a specific resource (a research job). This is more specific than the name alone. However, it does not differentiate from the sibling tool 'get_status', which may overlap in function, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by explaining that the job_id comes from create_research_job / deep_research / plan_research jobs. That gives useful context about which jobs this tool applies to. However, it does not provide explicit guidance on when to choose this over siblings like get_status, list_research_jobs, or cancel_research_job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavior disclosure burden. It does add meaningful behavior by stating the cancellation is a clean exit at the nearest stage boundary, but it does not mention side effects, whether the cancellation is reversible, what happens to partial results, or whether the call is synchronous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loads the primary action, and adds only one useful parenthetical behavioral detail. The Args list is minimal and directly matches the single schema parameter with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no annotations and no output schema, the description covers the core purpose and parameter adequately. However, it omits post-cancellation state, return behavior, and any guidance comparing cancellation to deleting or recovering jobs, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the parameter documentation is carried entirely by the Args section. The description defines job_id as 'the id of the running task', which adds a small amount of context beyond the schema's bare title 'Job Id', but it largely restates what the parameter is.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'cancel' and the resource 'a task running in the background', with a useful qualifier about cleanly exiting at the nearest stage boundary. It is specific enough to be distinguished from listing, creating, or deleting jobs, though it does not explicitly contrast with delete_research_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear condition for use: cancel a task that is currently running in the background. It does not explicitly discuss alternatives or exclusions, but the running-task condition is an explicit contextual signal for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the filtering behavior, valid status values, None=all semantics, and the limit cap, which is useful. It does not mention return format, ordering, pagination, or whether the list is user-scoped, but for a list operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with a clear one-line summary followed by a concise Args block. No filler or redundancy; every sentence carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list tool, the params are fully described and the tool can be invoked correctly. However, with no output schema, the description does not explain what the returned jobs look like, ordering, pagination, or the exact scope of 'tasks (M10)', leaving minor downstream uncertainty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates: it explains status's allowed values and None=all behavior, and clarifies that limit is an upper bound with a default of 50. This adds meaningful semantics beyond the bare schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('列出') and resource ('任务'/research jobs), and mentions status filtering, making its purpose clear. It is naturally distinguished from sibling mutations like cancel/delete/run, but does not explicitly contrast with get_research_job or describe scope, so it falls just short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need to list or filter research jobs, and the status values give concrete filtering context. However, it provides no explicit when-to-use/when-not-to-use guidance or alternatives among the many job-management siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 reveals what entities are covered (data sources, subscriptions, LLM providers) and implies a liveness check, but it does not state whether the operation is read-only, whether the liveness probe triggers external network calls or quota usage, or how the status is obtained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the main purpose and then adds specific coverage details. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless status tool, the scope is reasonably clear, but with no output schema the description does not explain what the returned status report contains or how an agent should interpret it. The lack of annotations also leaves side effects and read-only behavior unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter meaning, and there is no parameter-level gap to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports data source configuration and health status, including Sci-Hub/institutional subscription enabled/disabled state and LLM provider liveness. This goes well beyond the tautological 'get status' and distinguishes it from siblings like get_settings or test_fulltext.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a health/status diagnostic, but it gives no explicit guidance on when to prefer this tool over sibling tools such as get_settings or test_fulltext. There are no exclusions, alternatives, or decision criteria mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose core behavior: it searches multiple sources, normalizes metadata, returns metadata plus abstracts, and offers a deep mode with full text. It does not mention rate limits, errors, or explicit read-only confirmation, but for a search tool the stated output and mode behavior are substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose statement is front-loaded in one sentence, followed by a compact Args block. Every line adds information about a parameter or behavior, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter search tool with no output schema and no annotations, the description covers inputs, defaults, output content, and mode behavior. It is slightly incomplete in not relating this tool to sibling read/deep-research workflows, but it gives an agent enough to invoke it correctly in isolation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates fully: query gets an example, sources are enumerated with a default, limit is defined as per-source maximum, and mode is explained semantically. This adds real meaning beyond the bare JSON Schema property names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('跨源检索科学文献') and states the return value (normalized metadata + abstracts). It is clearly about cross-source search, but it does not explicitly compare itself with sibling tools such as read_paper or deep_research, so it stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Args block explains how to issue a query, but there is no guidance on when to choose search_literature instead of a sibling like read_paper, get_citations, or deep_research. The mode options distinguish fast vs deep internally but do not route the agent between this tool and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the disclosure burden. It reveals useful behavioral traits: chunked return, source fallback priority, and the need for at least one identifier. It does not cover errors, concurrency limits, or exact output format, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: purpose in the first line, then source precedence, then an Args list. Every sentence contributes useful information without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five optional-looking parameters and no output schema, the description covers identifiers, source precedence, and chunk control. It does not address edge cases like conflicting identifiers or error behavior, but the essential call contract is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully by explaining every parameter: doi, arxiv_id, pmid, pmcid, and max_chunks. It also gives realistic examples for identifiers, making parameter usage unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (获取/resad) and resource (paper full text, chunked), and the purpose of deep reading. It does not explicitly name sibling tools it differs from, so it stops just short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a usable precondition: at least one identifier must be provided. It also lists the source priority order, which helps the agent reason about behavior. However, it does not explicitly say when to prefer this over siblings like search_literature or test_fulltext.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states the tool writes to ~/.deepseek-litresearch/settings.json and applies changes hot, and it explains important operational details such as defaults, prerequisite flags, and that cookies are not auto-collected. This is well beyond a generic 'updates settings' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but appropriately so for 30 parameters. It front-loads the core purpose first and then uses a clear, scannable list. Some entries, such as session_fallback_provider, are verbose, but the extra context is genuinely useful rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and zero schema-level parameter descriptions, this description is nearly complete: it covers defaults, constraints, prerequisites, and side effects. The main gaps are the undocumented scraperapi_country parameter and the lack of any explicit statement about the tool's return value or acknowledgment behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates strongly by documenting nearly every parameter with defaults, allowed values, and domain-specific meaning (e.g., proxy template variables, fallback behavior, report formats). However, the schema includes scraperapi_country, which is not mentioned anywhere in the description, leaving one parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: '修改插件设置' (modify plugin settings) and adds the concrete destination file and hot-reload behavior. This clearly distinguishes it from the sibling get_settings and the research-execution tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used whenever plugin settings must be changed, and it documents per-field prerequisites such as acknowledge_scihub_risk. However, it never explicitly says when to use this tool versus alternatives like get_settings, nor does it provide exclusions or caveats about when not to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool is read-only, does not modify settings, probes multiple Sci-Hub mirrors, may perform EZProxy login, and returns configuration guidance when EZProxy is not configured. It does not describe failure output or timeout behavior, but it is substantially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core intent and safety guarantee, followed by compact scannable bullets. Every line adds operational detail and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex diagnostic tool with no output schema and no annotations, the description covers both fallback channels, their probe sequences, legal caution, and unconfigured behavior. It does not describe the exact return shape, but it provides enough context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the scihub and ezproxy booleans and mentions DOI usage in prose, but it never defines the timeout parameter or the doi format/default behavior. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: testing the availability of full-text fallback channels, then enumerates the two concrete modes (scihub, ezproxy). This clearly distinguishes it from sibling tools like read_paper or execute_research and is not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames the tool as a read-only diagnostic probe and explicitly says it 'only diagnoses connectivity', which tells an agent when to consider it. It does not explicitly name sibling alternatives or state when not to use it, so it falls short of full alternative-based guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
由於沒有 annotations，描述必須自行承擔行為揭露。它清楚說明任務會持久化、回傳 job_id、且不會立即執行，這些都是讓智能體避免誤以為呼叫後就同步得到研究成果的關鍵行為。雖然未談權限或副作用，但對建立任務類工具已足较誠實。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
開頭一句話載明核心功能，隨後用精簡清單列出全部參數語意，沒有冗句或重複 schema 已有資訊。每個條目都有資訊價值，適合 LLM 快速掃讀。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
對一個 8 參數、無輸出 schema、無 annotations 的非同步建立工具而言，描述已覆蓋呼叫所需的主要語意與回傳值。但「sources 預設全部」未列舉實際可用來源，也未明確說後續可透過 run_research_job 執行已建立的 job，稍有缺漏。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema 參數描述覆蓋率為 0%，描述完全補償了這項缺口。它為每個參數賦予語意和範圍：breadth 1-6、depth 1-3、max_papers 50、format 的枚舉值、critique 的紅隊對抗含義、langauge zh/en，question 也定義為科學問題。這比 schema 本身資訊更豐富，智能體能據此正確填寫參數。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述開頭就明確說出核心動作「创建深度调研任务」，指出資源是研究任務，並補充關鍵行為：M10 持久化、返回 job_id、不立即執行。這能與 run_research_job、execute_research、deep_research 等立即執行類兄弟工具明確區分。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
「不立即執行」暗示此工具適合需要先建立任務、稍後再跑的場景，與執行型兄弟工具形成隱含對比。但描述沒有明確寫出「需要立即執行時請改用 run_research_job/execute_research」，也沒有列舉不適用情境，因此只到隱含使用指引的層級。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
没有注解，描述承担全部披露责任。'查看'暗示只读操作，且列出配置说明的具体范围（Sci-Hub、EZProxy、TDM API），让代理了解返回值内容。未明确说明不修改任何设置，但动词稳定性足够。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
单一、精炼的句子，动词前置，内容紧凑包含范围说明，无任何冗余信息使代理快速理解。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
零参数、无输出schema的工具，描述完整说明工具用途和返回内容主题，足以让代理正确调用，无需额外上下文。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
该工具无参数，描述无需补充参数语义。按照准则无参数时基线为4，且描述与空schema完全匹配。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述使用明确的动词'查看'和资源'插件配置说明'，并列出具体涵盖的主题（Sci-Hub、EZProxy、TDM API），区别于 get_settings 等实际配置工具。清晰标示了此工具是查看说明而非修改配置。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
虽然没有显式说明何时使用或与其他工具对比，但'查看插件配置说明'自然暗示使用场景。缺少对 get_settings/set_settings 等替代工具的排除说明，但零参数简单工具使上下文基本明确。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses direction semantics ('citations' is forward, 'references' is backward), accepted paper_id formats including DOI, and that limit is an upper bound. It does not describe output format or error behavior, but the core behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core benefit, and the Args block is structured without redundancy. Every line contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, this description explains purpose, parameters, ID formats, and direction choices adequately. It stops short of specifying the exact return structure, which would round out the picture, but the tool is still safely invocable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the schema has 0% description coverage, the parameter explanations are essential and are fully provided: paper_id formats, direction values with mappings, and limit semantics. This adds clear meaning the raw schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation (citation snowballing) and the resource (a paper's cited/forward or citing/backward literature). It clearly distinguishes itself from sibling tools like read_paper and search_literature by framing the behavior as citation expansion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '引文扩展（滚雪球）' gives a clear usage context: use this tool when you want to expand from a known paper via its citation graph. It does not explicitly list excluded cases or name alternatives, but the intended use case is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It explicitly states idempotency, the empty-list result when there is nothing to recover, and a subtle safety property: tasks running in background threads of the current process will not be mis-marked. This is strong transparency for a mutation-style tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very compact: two sentences, with the core purpose first and the edge-case/idempotency behavior second. There is no filler or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter maintenance tool, the description covers when to run it, what side effects it performs, and its idempotent behavior. The only minor gap is that it does not describe the return value on success, but there is no output schema and the side effect is fully specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema confirms this with 100% coverage. With no parameters to document, the description does not need to add parameter-level semantics, so the baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (recover interrupted research jobs), a concrete state transition (running tasks left by a crash are marked as pending), and implies a re-run capability. This clearly distinguishes it from sibling tools like cancel_research_job or delete_research_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: after a process crash or when running tasks have lost their executor. It does not explicitly name alternatives or say when not to use it, but the recovery use case is specific enough to guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so well: it states that no search is executed, that it returns an outline and job_id, that track controls SQLite persistence, and that providing job_id avoids creating a new task. These are exactly the side effects an agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well organized: it opens with the purpose and key exclusion, then the workflow, then a clean Args block. Every sentence contributes information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no annotations and no output schema, the description covers purpose, workflow, all parameters, persistence behavior, and task attachment. Nothing essential is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description documents every parameter: question, breadth with range 1-6 and default behavior, language with zh/en values, track with default true, and job_id with its attach-to-existing-task semantics. This fully compensates for the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: '生成调研大纲' and explicitly says '不执行检索'. It clearly differentiates this planning tool from execute_research, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit workflow: first generate the outline, have the user confirm or modify it, then call execute_research(job_id, ...). It also explains when to use job_id with create_research_job or recover_research_jobs. It does not enumerate all alternatives, so it stops just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden and succeeds: it discloses async execution, first-call no-op behavior, plan_override implying confirmation, the strict confirmation gate, None-value fallback semantics, and parameter write-back behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is front-loaded and structured, with purpose first, then workflow gate, async behavior, and parameter list. Minor deduction for dated change-log notes such as '2026-08-29 修复' and '2026-08-30 门禁强化', which add maintenance noise rather than essential procedural meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, 9 parameters, and lack of output schema, the description provides everything needed to invoke it correctly: preconditions, confirmation behavior, async semantics, cancellation/polling paths, and parameter override effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must document the parameters. It covers all 9 parameters, including type domains (depth 1-3, format enum, language zh/en), override semantics, and confirmation logic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '第二步：按已确认的大纲执行深度调研（plan_research 之后调用）', giving a specific action, object, and workflow position. This clearly distinguishes the tool from planning and follow-up siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states explicitly when to invoke the tool (after plan_research), what the confirmation precondition is, and exactly what to use for follow-up (get_research_job for polling, cancel_research_job for cancellation). The workflow guidance is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 that execution is asynchronous, that the call returns immediately, that stored parameters are used, that an outline acts as user confirmation, and that outline_confirm_strict may reject reruns within a time window. This is detailed and actionable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the core action, then adds scenario, condition, and async behavior in a compact structured format. Every sentence contributes operational value, and there is no redundant restatement of the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter async lifecycle tool with no output schema, the description covers the action, applicable statuses, exclusions, confirmation behavior, and the polling path. An agent has everything needed to invoke it correctly and know what to expect afterward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the single required parameter job_id is meaningfully contextualized as the identifier of the existing job to rerun and as the key passed to get_research_job for polling. It does not provide a dedicated parameter definition or format details, but the meaning is recoverable from the prose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: rerun/start an existing research job in pending, planned, or failed status. It also names sibling lifecycle tools such as create_research_job, recover_research_jobs, and plan_research, making the tool's role in the lifecycle unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly enumerates when to use the tool: jobs created by create_research_job, zombie jobs recovered by recover_research_jobs, and failed jobs retried with original parameters. It also gives a clear when-not case: jobs without an outline should first go through plan_research, and polling should be done via get_research_job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
无 annotations，但描述完整披露了内部流水线、大纲先行/直达模式、进度文件写入、导出文件目录、SQLite 持久化、cost 摘要和红队审查默认开启等行为。对调用者可预见的副作用和状态变化说明充分。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
开篇用一句话概括目的，内部流程、执行模式、参数列表分层清晰，信息密度高。对 10 参数、双执行路径的复杂工具来说，长度合理且没有冗余内容。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
无 output schema，但描述已覆盖返回值（status=planned + job_id + plan、report_paths + cost）、进度文件、导出文件、SQLite 跟踪及后续 execute_research 调用方式。对高复杂度工具而言上下文完整，足以让 agent 正确选择和调用。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
schema_description_coverage 为 0%，但描述对全部 10 个参数逐一补充了语义、范围、默认值和行为影响，如 breadth 1-6、depth 1-3、max_papers 50、format 枚举及 confirm_outline 开关。这远超 schema 本身提供的信息量。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确了核心用途：对科学问题进行深度调研并返回带引用的 Markdown 报告。通过'大纲先行'、直达模式和调用 execute_research 的说明，有效将 deep_research 与 plan_research、execute_research 等兄弟工具区分开。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
清楚说明了两种使用路径：默认生成大纲等待用户确认后用 execute_research 继续，或设置 confirm_outline=false 一次跑完。还说明进度文件与 job_id 的用途，对何时调用本工具、何时转交 execute_research 给出了明确指引。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![dsh-litresearch MCP server](https://glama.ai/mcp/servers/Wang-JQ77/dsh-litresearch/badges/card.svg)](https://glama.ai/mcp/servers/Wang-JQ77/dsh-litresearch)

Score Badge

Copy to your README.md:

[![dsh-litresearch MCP server](https://glama.ai/mcp/servers/Wang-JQ77/dsh-litresearch/badges/score.svg)](https://glama.ai/mcp/servers/Wang-JQ77/dsh-litresearch)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Wang-JQ77/dsh-litresearch'

If you have feedback or need assistance with the MCP directory API, please join our Discord server