Paper Pilot is an AI research copilot that automates academic literature review — from searching multiple databases and downloading full-text PDFs to extracting evidence, rendering figures, and syncing with Zotero.
End-to-End Research Workflows
research_topic – Search 6 academic databases, download open-access PDFs, generate a structured Markdown report, render an interactive citation graph, and optionally sync to Zotero
deep_read_topic – Like research_topic but also performs full-text extraction, returning evidence chunks with source attribution and local PDF paths
Literature Search & Discovery
search_literature – Search Semantic Scholar, OpenAlex, arXiv, Crossref, Europe PMC, and DOAJ simultaneously, with filters for year range and open-access
find_similar_papers – Discover related work from a seed paper title or DOI
PDF Access & Reading
inspect_open_access_pdf – Download and preview an open-access PDF
extract_local_pdf_text – Extract full text from a local PDF and return top matching chunks for a research question
render_pdf_pages – Render specific PDF pages as PNG images to visually inspect figures, tables, and layout
get_pdf_page_text – Retrieve exact text from a specific PDF page
Shadow Library Access (Opt-in)
search_scihub / download_scihub_paper – Search and download papers via Sci-Hub by DOI, title, or keyword
search_libgen / inspect_libgen_item – Search LibGen mirrors and download supplemental material
Reference Management
list_zotero_collections – List collections in your local or web Zotero library; research tools can also write papers directly into Zotero
Utilities
healthcheck – Verify the current configuration and status of all enabled integrations
Searches academic papers from arXiv as part of multi-source scholarly search, enabling AI agents to find and access research papers from this preprint repository.
Resolves Digital Object Identifiers (DOIs) for academic papers, enabling AI agents to locate and access specific research papers through DOI-based lookups and Sci-Hub integration.
Searches academic papers from Semantic Scholar as part of multi-source scholarly search, providing access to scholarly literature with citation data and metadata.
Syncs research papers, metadata, and reports to Zotero libraries, enabling AI agents to automatically organize and manage academic references in both local and web-based Zotero instances.
Let Codex and Claude find, download, and read full research papers.
Search six academic databases, read methods and results page by page, inspect figures, and get back to the decision you are trying to make. Paper Pilot is a local MCP server; your existing AI agent does the reasoning.
Install · Real example · Reading guide · Report a problem
Install uv and Git if needed. Choose your client:
Codex
codex mcp add paper_pilot -- uvx --from git+https://github.com/aytzey/paper-pilot paper-pilotClaude Code
claude mcp add --scope user paper-pilot -- uvx --from git+https://github.com/aytzey/paper-pilot paper-pilotRestart your client, then ask:
Use Paper Pilot to find “Attention Is All You Need”. Read the full paper, inspect the architecture figure, and explain the method and its limitations with PDF page citations.
No account, API key, email setup, or Zotero installation is required by Paper Pilot. Your AI client's own access and usage costs still apply. The first launch installs Python dependencies; academic APIs can rate-limit requests.
Claude Desktop or Cursor: use the copyable JSON configuration.
Try the tools without an AI client:
uvx --from git+https://github.com/aytzey/paper-pilot paper-pilot demo "retrieval augmented generation"The CLI downloads accessible papers, saves a reading pack, and opens a citation graph. It does not run an LLM or write a finished research conclusion. Results go into ./data/ by default. These commands install from GitHub; a PyPI release is not required.
Related MCP server: Research MCP
In a recorded stdio MCP check, Attention Is All You Need was delivered as 15 pages of text across four responses. All 39,498 extracted characters arrived in order. The original 2,215,244-byte PDF also arrived unchanged through both supported PDF transfer paths.
What was checked | Recorded result |
Whole-document text | Every batch joined to exactly match extraction from all PDF pages |
Original PDF | Returned bytes matched the downloaded file |
A multidisciplinary example | Two soil-pH papers: 37 pages, 96,163 characters, nine responses |
Read the walkthrough and reproduction steps or inspect the verification data. This verifies delivery, not model comprehension. Codex and Claude UI sessions were not tested in that check.
Start with something you need to decide:
I want to build an inexpensive circuit to measure soil pH. Use Paper Pilot to investigate soil science, electrode materials, and electronics, starting with recent papers and following foundational references. Read the decisive papers in full. Compare cost, calibration, drift, and measurement conditions. Recommend an approach, cite the evidence, and propose the first experiment to validate it.
The server supplies research instructions alongside its tools: split the question across disciplines, continue the relevant searches, inspect the full papers, seek contrary evidence, and disclose gaps before recommending an approach.
Other useful starting points:
Your decision | Ask your agent |
Choose a RAG design | “Compare recent RAG approaches for my document set. Read the evaluation sections and explain which results transfer to my constraints.” |
Understand a disputed result | “Find papers supporting and challenging this claim. Compare their methods and conditions with page citations.” |
Inspect a paper you already have | “Read this PDF completely. Check the main figures and list the assumptions behind its conclusion.” |
Search covers Semantic Scholar, OpenAlex, arXiv, Crossref, Europe PMC, and DOAJ. A working PDF is used directly; missing or failed PDFs are resolved through Unpaywall, with OpenAlex recovery if its API fails. Zotero sync is optional.
flowchart LR
Q[Your question] --> S[Search across disciplines]
S --> P[Download selected PDFs]
P --> R[Read text and inspect figures]
R --> A[Agent compares the evidence]Text: read_pdf_text returns consecutive pages with continuation cursors, including pages longer than a single response.
Figures and tables: render_pdf_pages returns page images for visual inspection.
Original file: read_pdf_document provides the PDF when your agent needs it and the client supports that delivery path.
Evidence trail: retain source, DOI, PDF page, access location, and extraction warnings.
The agent must follow every continuation to complete a text read. Scanned PDFs without a text layer are reported as unreadable; OCR is outside the project scope. Search results reflect returned provider pages, so exhaustive literature coverage is not guaranteed.
See the tool-level reading guide for exact calls, access rules, and limits.
For Claude Desktop or Cursor, add this server to your MCP configuration:
{
"mcpServers": {
"paper-pilot": {
"command": "uvx",
"args": ["--from", "git+https://github.com/aytzey/paper-pilot", "paper-pilot"]
}
}
}Ready-to-copy files: Claude Desktop · Cursor · Codex.
On Windows, if the client cannot find uvx, use the executable's full path from where.exe uvx. Keep the arguments unchanged. Client setup covers configuration locations, local checkouts, updates, PDF capabilities, and optional Zotero setup.
Use it when you want your existing agent to research a question across disciplines and inspect the actual papers. If your main task is different, these projects are also worth a look:
Project | Main focus |
arXiv literature workflows, original LaTeX section reads, BibTeX, and topic watches | |
Working with an existing Zotero library through an AI assistant | |
A RAG system for answering questions from scientific documents with citations |
These are different starting points, not a quality ranking. Paper Pilot does not include its own LLM or require a vector database.
Try a paper or decision you know well. If the agent misses a source, cannot retrieve a PDF, or loses part of a page, open an issue with the DOI, client, and failed step. A small reproducible case is particularly useful.
For code contributions, see CONTRIBUTING.md. The most useful work is reliable source access, reading correctness, and verified client instructions.
Architecture · Agent instructions · Codex guide · Claude guide · Optional integrations
MIT licensed. If this is useful for your next research task, star Paper Pilot to keep it handy. Sharing a case that worked helps other people decide whether to try it.
Search, download, extract full text, and return evidence chunks plus local PDF paths for direct inspection.
By default the result is just [result_dict]: it carries every downloaded PDF's local path in
pdf_paths (and in deep_reads[].pdf_path / downloads[].pdf_path), so a client can open the
files when needed without any base64 in the payload. Opt in to inline content when your client
benefits: render_top_pages=True appends the top paper's relevant pages as images (vision models);
attach_top_pdf=True embeds its PDF as an application/pdf resource (Claude API style). include_scihub=True
adds a Sci-Hub fallback; write_graph=True also renders a citation graph (path in graph_path).
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| research_question | No | ||
| limit_per_source | No | ||
| related_limit | No | ||
| download_top_n | No | ||
| top_chunks_per_paper | No | ||
| chunk_size_chars | No | ||
| chunk_overlap_chars | No | ||
| include_scihub | No | ||
| scihub_fallback_limit | No | ||
| from_year | No | ||
| to_year | No | ||
| open_access_only | No | ||
| write_to_zotero | No | ||
| existing_collection_key | No | ||
| existing_collection_name | No | ||
| create_collection_name | No | ||
| attach_pdfs | No | ||
| write_graph | No | ||
| render_top_pages | No | ||
| max_render_pages | No | ||
| render_scale | No | ||
| attach_top_pdf | No | ||
| attach_pdf_max_mb | No | ||
| attach_pdf_max_pages | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It explains default behavior (result dict with pdf_paths), side effects (write_graph, write_to_zotero), fallback (include_scihub), and output format details (local paths, no base64). This provides substantial transparency, though it could mention rate limits or authentication requirements if applicable.
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 divided into two focused paragraphs: the first states the high-level purpose, and the second details optional behaviors. Every sentence provides useful information, though it could be slightly shortened without losing key details. The structure supports quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (25 parameters, no output schema, no annotations), the description covers the main output structure and key options but omits explanations for many parameters. It provides enough context for basic usage but may leave agents uncertain about lower-level settings. Return values beyond paths are not detailed.
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 0%, so the description must add meaning. It explains several key parameters (render_top_pages, attach_top_pdf, include_scihub, write_graph, etc.) and their effects. However, many parameters (e.g., limit_per_source, related_limit, download_top_n, chunk settings) are not described, leaving gaps. The description adds value but incompletely compensates for the lack of schema descriptions.
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 starts with a clear verb and resource: 'Search, download, extract full text, and return evidence chunks plus local PDF paths for direct inspection.' It distinguishes itself from sibling tools like research_topic or search_literature by emphasizing local file paths and optional inline content, making its unique value proposition evident.
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 guidance on when to opt into inline content (e.g., 'when your client benefits: render_top_pages=True appends top paper's relevant pages as images...'), but it does not explicitly state when to prefer this tool over its siblings (e.g., research_topic, search_literature) or when to avoid it. The usage context is partially clear but lacks comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a paper PDF via Sci-Hub using its DOI. Returns local path and text preview. Requires SCIHUB_ENABLED=true.
| Name | Required | Description | Default |
|---|---|---|---|
| doi | Yes | ||
| topic_hint | No | scihub |
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 the download action and output format, but does not mention potential failures, network dependencies, or the scope of the text preview. The information is adequate but not exhaustive.
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 with no redundant information. It is concise and front-loaded, effectively communicating the essential purpose and prerequisite.
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 mentions the return type (local path and text preview) adequately. However, it lacks details on error handling, file naming, or the length of the preview, leaving some gaps for a complete understanding.
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 description explains the 'doi' parameter by stating 'using its DOI', which provides context. However, the 'topic_hint' parameter is not explained at all, leaving its purpose unclear. With 0% schema description coverage, the description should compensate more fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (download), the resource (paper PDF), the method (via Sci-Hub using DOI), and the output (local path and text preview). It effectively distinguishes from siblings like search_scihub and read_pdf_document.
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 includes a prerequisite (SCIHUB_ENABLED=true) and implies the use case (having a DOI for a paper). It does not explicitly state when not to use or name alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract full text from a local PDF, save a text sidecar, and return top matching chunks.
| Name | Required | Description | Default |
|---|---|---|---|
| pdf_path | Yes | ||
| title_hint | No | ||
| research_question | No | ||
| chunk_size_chars | No | ||
| chunk_overlap_chars | No | ||
| top_chunks | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It mentions saving a sidecar file (a side effect) and returning chunks, but does not disclose overwrite behavior, permissions needed, or the underlying matching mechanism. Basic transparency is present but incomplete.
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 core action. It could be more structured (e.g., listing outputs), but it wastes no words and is easily scannable.
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?
The tool has 6 parameters and no output schema, yet the description omits critical details: the meaning of 'top matching chunks', how the sidecar is saved, and what the tool returns. It is insufficient for an agent to confidently invoke the tool without additional documentation.
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 0%, so the description should clarify parameters. It hints that 'research_question' and 'title_hint' drive matching, but does not explain 'chunk_size_chars', 'chunk_overlap_chars', or 'top_chunks'. The added semantic value is minimal beyond the parameter names.
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 actions: extracting full text from a local PDF, saving a sidecar text file, and returning top matching chunks. It distinguishes itself from siblings like 'get_pdf_page_text' by implying chunked-based retrieval, but does not explicitly differentiate from 'read_pdf_document' or 'inspect_open_access_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?
No guidance is provided on when to use this tool versus alternatives, prerequisites (e.g., file accessibility), or when not to use it. The agent must infer usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find similar papers starting from a seed paper title or DOI.
| Name | Required | Description | Default |
|---|---|---|---|
| seed_title | Yes | ||
| seed_doi | No | ||
| limit | No | ||
| open_access_only | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It does not disclose error handling (e.g., if both seed_title and seed_doi are provided), rate limits, or what the output contains. The description is too brief to be transparent.
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 immediately conveys the core purpose. However, it could include a brief note on the optional parameters without becoming 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?
With 4 parameters, no output schema, and no annotations, the description is insufficient. It fails to explain how the seed parameters interact, the meaning of 'limit' and 'open_access_only', or the expected output format. This leaves the agent underinformed.
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 has 0% description coverage, so the description must compensate. It only hints at using a seed title or DOI but does not explain 'limit' or 'open_access_only'. This adds minimal value beyond the schema itself.
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: finding similar papers using a seed title or DOI. It uses a specific verb ('find') and resource ('similar papers'), and distinguishes from siblings like 'search_literature' which perform broader searches.
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 (e.g., 'search_literature', 'research_topic'). There is no mention of prerequisites, typical use cases, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the exact extracted text of specific PDF pages (1-based) as plain JSON.
For fine-grained lookups over the wire (a single reference entry, a table, a footnote) without base64 and without filesystem/shell access. Use deep_read_topic first to get the pdf_path and the page mapping (deep_reads[*].chunk_manifest_path), then fetch the exact pages you need here.
| Name | Required | Description | Default |
|---|---|---|---|
| pdf_path | Yes | ||
| page_numbers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses that the operation is read-only (getting text) and works over the network without base64/filesystem. However, it does not explicitly state that it has no side effects or any error behavior. Given the simplicity, this is adequate but not comprehensive.
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 with zero wasted words. The first sentence states purpose and output; the second gives usage context and prerequisites. 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?
With no output schema, the description mentions the output is 'plain JSON' but does not detail its structure. However, for a simple text extraction tool with two parameters, the description covers the essential workflow and constraints. Minor improvement would be to specify the JSON format (e.g., mapping page numbers to text), but it's still fairly 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 description coverage is 0%, so the description must compensate. It explains that 'pdf_path' comes from deep_read_topic and that 'page_numbers' are 1-based and 'exact pages'. This adds meaningful context beyond the schema's bare type declarations, helping the agent understand parameter origins and behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return the exact extracted text of specific PDF pages'), the resource ('PDF pages'), and the output format ('as plain JSON'). It distinguishes itself from siblings like read_pdf_document and extract_local_pdf_text by specifying 'over the wire' and avoiding base64/filesystem access.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('for fine-grained lookups over the wire') and what prerequisite step is required ('Use deep_read_topic first to get the pdf_path and the page mapping'). It also contrasts with alternatives by noting it avoids base64 and shell access, making its use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search a topic and render an interactive citation/relatedness graph as a self-contained HTML file.
Nodes are papers (size scales with citation count, color by year); edges connect papers that share keywords or a venue, plus similarity links radiating from the top result. Returns the local HTML path. Open it in a browser to explore or screenshot the landscape.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| limit_per_source | No | ||
| related_limit | No | ||
| from_year | No | ||
| to_year | No | ||
| open_access_only | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full behavioral burden. It describes node encoding (size, color) and edge logic, but omits details about failure modes (e.g., empty results), authentication, or rate limits. The behavior is mostly transparent but incomplete.
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 three sentences, front-loaded with the core action, and every sentence provides unique information. No redundancy or unnecessary detail.
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 complexity of a graph-generation tool and lack of output schema, the description explains the return value (HTML path) and visual encoding. However, it misses parameter explanations and does not set expectations about performance or source dependencies, leaving gaps 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?
With 0% schema description coverage and 6 parameters, the description must compensate but does not. Only 'topic' is implied. No explanation is given for limit_per_source, related_limit, from_year, to_year, or open_access_only, leaving the agent without necessary guidance for 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's purpose: searching a topic and rendering an interactive citation/relatedness graph as an HTML file. The verb 'search' and 'render' are specific, and the resource (citation graph) is distinct from siblings like search_literature or deep_read_topic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for visual exploration of citation relationships but does not explicitly state when to use this tool over alternatives or provide usage exclusions. No mention of when-not to use or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return current configuration summary and enabled integrations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 describes the output but does not disclose behavioral traits like read-only nature, speed, or authentication needs. It is adequate but not rich.
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?
One sentence with eight words, no fluff, and no repetition. It is appropriately sized and front-loaded.
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 parameters and no output schema, the description is nearly complete. It specifies the return content. Missing a note on performance or prerequisites, but these are minor.
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?
No parameters exist, and the schema coverage is 100% trivially. Per guidelines, 0 parameters baseline is 4. The description adds no parameter info because none is needed.
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 states a clear verb ('Return') and resource ('configuration summary and enabled integrations'), which is specific and distinguishable from sibling tools that perform research or document operations.
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 or when not to. While the purpose is clear, there is no mention of context or alternatives, though no sibling tool serves the same purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve LibGen mirror links, download a PDF when possible, and return a preview.
| Name | Required | Description | Default |
|---|---|---|---|
| mirror_1 | Yes | ||
| title | Yes | ||
| author | No | ||
| year | No | ||
| extension | No | ||
| publisher | No | ||
| size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must fully disclose behavior. It mentions downloading and previewing but omits important details like rate limits, network dependency, failure modes for broken links, or handling of non-PDF extensions.
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 but lacks structure; parameter information is absent and necessary details are omitted. Not all sentences earn their place.
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 tool with 7 parameters and no output schema, the description is severely incomplete. It fails to explain input semantics, return value format, or error handling, leaving the agent underinformed.
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 0% and description adds no parameter meaning. It does not explain what 'mirror_1', 'title', or optional fields (author, year, etc.) represent or how they affect the operation.
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 resolves mirror links, downloads a PDF, and returns a preview, which is specific and distinguishes it from sibling tools like 'search_libgen' or 'download_scihub_paper'. However, the verb 'inspect' is vague without the description's context.
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 (e.g., after searching LibGen). Lacks explicit context, exclusions, or mention of prerequisites like prior search results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download an open-access PDF and return a local preview.
| Name | Required | Description | Default |
|---|---|---|---|
| pdf_url | Yes | ||
| filename_hint | No | paper |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states download and preview, omitting side effects, prerequisites, or limitations (e.g., download location, preview persistence).
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, very concise. Could be structured better but gets the core point across without waste.
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 low complexity, the description lacks detail on expected input format, output behavior, and error handling. Very incomplete for effective agent 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?
Schema coverage is 0%. Description adds no explanation for pdf_url or filename_hint beyond the schema itself.
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?
Clearly states the action (download) and resource (open-access PDF) and result (local preview). Distinguishes from siblings like download_scihub_paper.
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 vs alternatives, such as Sci-Hub downloaders. Implied by 'open-access' but no when-not-to-use or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Zotero collections visible to the configured web or local Zotero integration.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as read-only nature, rate limits, authentication needs, or side effects. It merely states the function without further context.
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 extremely concise (one sentence) and front-loaded with the core action. However, it may be too brief, lacking necessary details. It is not verbose, but earns high marks for clarity without waste.
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 of the tool (one optional parameter, no output schema, no annotations), the description provides a minimal viable understanding. However, it omits details like output format, pagination, or how the query works, leaving gaps for the 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?
The sole parameter 'query' has no description in the schema (0% coverage) and the tool description provides no explanation of its purpose, format, or effect. The agent receives no insight beyond the schema's type definition.
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 lists Zotero collections, specifying the scope as 'visible to the configured web or local Zotero integration.' This is a specific verb+resource combination that distinguishes it from sibling tools, which focus on papers and literature.
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. There is no mention of prerequisites, when not to use it, or how it relates to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a downloaded PDF's local path so a client can open the file when it needs it.
By default nothing is base64-inlined: the result is [metadata, resource_link] where metadata carries pdf_path / doc_id / page_count / size_bytes. The PDF stays on disk; clients that read local files (e.g. Claude Code) or fetch the paperpilot://pdf/{doc_id} resource use it without payload bloat. Set embed_base64=True to inline the PDF as an application/pdf resource for clients that read PDFs that way (Claude API integrations), bounded by max_mb / max_pages.
| Name | Required | Description | Default |
|---|---|---|---|
| pdf_path | Yes | ||
| embed_base64 | No | ||
| max_pages | No | ||
| max_mb | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the transparency burden. It discloses default behavior (disk-only), optional inline embedding, bounds (max_mb, max_pages), and return format. It does not mention read-only safety but implies it via 'download' and 'read' context. No destructive actions are described, which is appropriate for a read 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 two compact paragraphs with no redundant sentences. The first sentence encapsulates the core purpose, and the second provides necessary detail on optional behavior. Every sentence adds value, and the structure is front-loaded with the primary action.
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 sufficiently explains the return format ([metadata, resource_link] with fields). It covers default and embed modes, size limits, and client usage examples. No critical gaps are apparent for a file-access 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 input schema has 0% description coverage, so the description must explain all parameters. It does so effectively: pdf_path is implied, embed_base64 is explained with client context, and max_mb/max_pages are described as bounding constraints. Every parameter receives semantic context beyond type/default.
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 explicitly states the tool returns a PDF's local path or inlined content, with clear distinction between default and embed modes. It uses specific verbs ('Return', 'download') and resources ('PDF', 'local path'), and implicitly distinguishes from siblings focused on text extraction (e.g., extract_local_pdf_text) by focusing on file access rather than content parsing.
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 clear guidance on when to use the default vs. embed mode, including client compatibility (local readers vs. Claude API integrations) and size constraints. However, it does not explicitly compare with sibling tools or state when not to use this tool (e.g., when text extraction is needed instead of whole file access).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render selected PDF pages to PNG and return them as images the model can see.
The result is [metadata_dict, image, image, ...]: the dict keeps pdf_path and
images (local PNG paths) for path-based clients, and the trailing image blocks
let a vision-capable model inspect figures, tables, and layout directly. Set
include_images=False to return only the paths.
| Name | Required | Description | Default |
|---|---|---|---|
| pdf_path | Yes | ||
| page_numbers | Yes | ||
| scale | No | ||
| include_images | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes output format as [metadata_dict, image, ...] and notes the include_images option. With no annotations, description adds useful behavioral context beyond schema, though could expand on scale effect or error handling.
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?
Three sentences, front-loaded with action, no fluff. Could be slightly tighter, but effectively communicates key points.
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?
Explains purpose, output format, and the include_images option. Missing details on scale, performance, or error cases, but sufficient for an AI agent to use the tool effectively given the 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?
With 0% schema coverage, description adds meaning only for include_images. pdf_path and page_numbers are clear from names, but scale is completely unexplained. Does not compensate adequately for missing parameter descriptions.
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?
Clearly states 'Render selected PDF pages to PNG' – specific verb and resource. Distinguishes from siblings (e.g., extract_local_pdf_text, get_pdf_page_text) which focus on text extraction.
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?
Implied usage for visual inspection of PDF content, but no explicit guidance on when to use versus alternatives or when not to use. Missing exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the end-to-end research workflow and optionally sync the result into Zotero. Set include_scihub=True to use Sci-Hub as a fallback for papers without open-access PDFs. Set write_graph=True to also render an interactive citation graph HTML (path returned as graph_path).
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| limit_per_source | No | ||
| related_limit | No | ||
| download_top_n | No | ||
| include_libgen | No | ||
| libgen_limit | No | ||
| libgen_download_top_n | No | ||
| include_scihub | No | ||
| scihub_fallback_limit | No | ||
| from_year | No | ||
| to_year | No | ||
| open_access_only | No | ||
| write_to_zotero | No | ||
| existing_collection_key | No | ||
| existing_collection_name | No | ||
| create_collection_name | No | ||
| attach_pdfs | No | ||
| write_graph | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It only mentions two optional behaviors (Sci-Hub fallback, graph rendering) but fails to describe the core workflow steps, sources searched, or output format, leaving significant ambiguity.
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?
Three sentences, concise and front-loaded with the main purpose. No wasted words, though a bit more structure (e.g., listing key features) would improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, no output schema, no annotations), the description is incomplete. It omits details on the overall workflow, expected outputs, and default behavior, leaving the agent with many unknowns.
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 0%, so the description must compensate. It only explains two parameters (include_scihub, write_graph) out of 18, leaving most parameters like topic, limits, and year ranges undocumented. Parameter names are somewhat self-explanatory but insufficient.
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 runs an end-to-end research workflow with optional Zotero sync, which is a specific verb and resource. However, it does not differentiate from sibling tools like deep_read_topic or graph_topic, so it misses explicit distinction.
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 some context by mentioning optional flags (include_scihub, write_graph) but gives no explicit guidance on when to use this tool versus alternatives. It lacks when-not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search LibGen mirrors for supplemental research material.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| search_type | No | title | |
| limit | No | ||
| allowed_extensions | No |
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 only states 'Search LibGen mirrors', implying possible mirror failover or aggregation, but offers no details on error handling, result format, rate limits, or authentication needs. This is insufficient for safe invocation.
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 extremely short (one sentence), but conciseness is not achieved at the cost of informativeness. Key details about parameters, behavior, and context are missing, making it under-specified rather than efficiently compact.
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 4 parameters with 0% schema coverage, no output schema, and no annotations, the description is severely incomplete. It does not mention return values, pagination, error handling, or typical usage patterns, leaving a high burden on the agent to infer correct usage.
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 has 0% description coverage (no titles or descriptions beyond bare names), and the tool description does not explain any of the four parameters (query, search_type, limit, allowed_extensions). The agent gets no semantic guidance beyond schema structure, which is inadequate for correct 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 action ('Search') and the resource ('LibGen mirrors'), and specifies the content type as 'supplemental research material'. This differentiates it from siblings like search_scihub (which targets Sci-Hub) and search_literature (which might be broader). However, it could be more precise about what kind of material (e.g., books, papers, etc.) is found.
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 given on when to use this tool versus alternatives such as search_literature or inspect_libgen_item. The description does not specify use cases, prerequisites, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Semantic Scholar, OpenAlex, Europe PMC, arXiv, Crossref, and DOAJ for a topic.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| limit_per_source | No | ||
| from_year | No | ||
| to_year | No | ||
| open_access_only | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the basic action, omitting details like multi-source aggregation, rate limits, pagination, or whether searches are by title/abstract.
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, making it concise but too brief. It front-loads the core action but omits necessary details, balancing conciseness against completeness.
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 five parameters, no output schema, and many sibling tools, the description is insufficient. It fails to explain output structure, parameter effects, or selection criteria, leaving agents underinformed.
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 0%, so the description should explain parameters. It only mentions 'topic', ignoring limit_per_source, year filters, and open_access_only. No compensation for the lack of schema descriptions.
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 for a topic across six named academic databases, distinguishing it from siblings like research_topic or find_similar_papers. The verb 'search' and resource 'literature from specific sources' are specific, though it lacks details on what is returned.
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 vs alternatives (e.g., research_topic, find_similar_papers). No context on prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Sci-Hub for papers by DOI, title, or keyword. Use search_type='doi', 'title', or 'keyword'. Requires SCIHUB_ENABLED=true.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| search_type | No | doi | |
| limit | No | ||
| check_availability | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It mentions searching and an environment flag, but doesn't clarify behavior if SCIHUB_ENABLED is false, error handling, or whether it's 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 extremely concise, just two sentences with no redundant information. It front-loads the action and required conditions.
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 4 parameters and no output schema or annotations, the description is too brief. It lacks explanation of return values, error conditions, and the check_availability parameter.
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 0% description coverage. The description explains search_type values but not query, limit, or check_availability. This is insufficient for a tool with 4 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches Sci-Hub for papers by DOI, title, or keyword, and names the search_type options. However, it doesn't differentiate from sibling tools like search_libgen or search_literature.
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?
It specifies the allowed search_type values and the prerequisite SCIHUB_ENABLED=true, but doesn't provide guidance on when to use this tool versus siblings like search_libgen or search_literature.
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.7.0deep_read_topic7 fields changedInput schema / properties / attach_pdf_max_mbAdded value: +{
+ "default": 5,
+ "title": "Attach Pdf Max Mb",
+ "type": "number"
+}Input schema / properties / attach_pdf_max_pagesAdded value: +{
+ "default": 60,
+ "title": "Attach Pdf Max Pages",
+ "type": "integer"
+}Input schema / properties / attach_top_pdfAdded value: +{
+ "default": false,
+ "title": "Attach Top Pdf",
+ "type": "boolean"
+}Input schema / properties / max_render_pagesAdded value: +{
+ "default": 6,
+ "title": "Max Render Pages",
+ "type": "integer"
+}Input schema / properties / render_scaleAdded value: +{
+ "default": 2,
+ "title": "Render Scale",
+ "type": "number"
+}Input schema / properties / render_top_pagesAdded value: +{
+ "default": false,
+ "title": "Render Top Pages",
+ "type": "boolean"
+}Input schema / properties / write_graphAdded value: +{
+ "default": false,
+ "title": "Write Graph",
+ "type": "boolean"
+}get_pdf_page_textgraph_topicread_pdf_documentrender_pdf_pages1 field changedInput schema / properties / include_imagesAdded value: +{
+ "default": true,
+ "title": "Include Images",
+ "type": "boolean"
+}research_topic1 field changedInput schema / properties / write_graphAdded value: +{
+ "default": false,
+ "title": "Write Graph",
+ "type": "boolean"
+}v0.4.0deep_read_topicdownload_scihub_paperextract_local_pdf_textfind_similar_papershealthcheckinspect_libgen_iteminspect_open_access_pdflist_zotero_collectionsrender_pdf_pagesresearch_topicsearch_libgensearch_literaturesearch_scihubScored across 16 tools
Most tools have distinct purposes, but there is some overlap between deep_read_topic and research_topic, and between various search/download tools. Descriptions help differentiate them.
All tool names follow a consistent verb_noun pattern in snake_case, except for 'healthcheck' which is a single word but still clear. Overall very consistent.
16 tools is well-scoped for a research assistant server covering search, download, extraction, visualization, and Zotero integration. No extraneous tools.
Covers major workflows (search, download, extraction, graphing, Zotero) but lacks tools for managing Zotero items beyond collections or batch operations. Minor gaps.
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Search 340M+ academic papers — citation graphs, semantic similarity, and AI literature reviews.
AI research grounded in 300M scientific works — every citation a verifiable DOI.
Find academic papers across major sources like arXiv, PubMed, bioRxiv, and more. Download PDFs whe…
