Retrieves preprint full texts from arXiv as a fallback route in the full-text resolution ladder, clearly labelled as not the version of record.
Integrates with the Semantic Scholar API for scholarly metadata, with an optional API key to raise rate limits for citation and reference lookups.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@scilib find open-access papers on quantum error correction from the last two years"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for open-access scientific literature.
scilib gives an AI assistant three capabilities it does not have by default: search across the open scholarly record, retrieve full text through legal open-access routes with full provenance, and search the papers you already have on disk by their contents.
It runs entirely on your own machine. Nothing is uploaded, and the only data that leaves is the search terms and identifiers you ask it to look up.
Related MCP server: Paper Search MCP
Two different problems get confused with one another.
Acquisition. Finding a free, legal copy of a paper. This is largely solved, and the solution is underused. Roughly half of all literature, and a higher share of recent biomedical work, is legally available through PubMed Central, Europe PMC, preprint servers, institutional repositories and publisher open-access programmes. Much of it is invisible to a search that only checks the publisher's own page, because a closed paper very often has a legal author manuscript deposited in a repository under a funder mandate.
Retrieval. Knowing what is inside the papers you already hold. This is not solved, and it is where the expensive mistakes happen. A keyword search over titles and abstracts can only return answers to questions you already thought to ask, so it is structurally incapable of surfacing the result that reframes your problem. Papers sit unread in project folders for months.
scilib addresses both, and treats the second as the more important one.
scilib does not use Sci-Hub, LibGen or any other pirate mirror. It does not scrape publisher article pages, and it does not use shared or scraped credentials.
This is an engineering decision as much as a legal one. Publishers monitor institutional proxy traffic for bulk retrieval, and the standard response is to suspend access for the entire institution, after which the university traces it to an individual account. A tool shared across a research group that behaved this way would put every member's legitimate access at risk in order to reach a small number of papers the legal routes largely cover anyway.
Where a paper genuinely has no open copy, lit_request_copy drafts a reprint
request to the corresponding author. This was the normal way to obtain a paper
before the web, it is entirely lawful, and it still works.
Python | 3.10 or newer |
| from poppler-utils, required for indexing PDFs |
Disk | a few hundred MB for a typical personal library |
Accounts | none required; two optional free API keys raise rate limits |
Install pdftotext:
sudo apt install poppler-utils # Debian / Ubuntu
brew install poppler # macOSgit clone https://github.com/Hiran001/scilib-mcp.git
cd scilib-mcp
./scripts/install.shThe installer creates a self-contained virtualenv at .venv, installs the two
dependencies (mcp and httpx), and verifies that the server imports cleanly.
It does not modify anything outside the project directory.
Claude Code
claude mcp add scilib -- "$(pwd)/.venv/bin/python" "$(pwd)/scilib/server.py"Claude Desktop, or any client using a JSON config, add to mcpServers:
{
"mcpServers": {
"scilib": {
"command": "/absolute/path/to/scilib-mcp/.venv/bin/python",
"args": ["/absolute/path/to/scilib-mcp/scilib/server.py"]
}
}
}Use absolute paths. Restart the client, and confirm the server shows as connected before continuing.
Run once, in your assistant:
configure(email="you@university.edu")The address is sent to the polite pools operated by Crossref, Unpaywall, OpenAlex and NCBI. These services request a contact address and grant higher rate limits in return. It is the only personal data scilib transmits, Unpaywall requires it, and everything else works without it.
Configuration is stored at ~/.config/scilib/config.json.
setting | default | purpose |
| empty | contact address for API polite pools |
|
| where retrieved papers and the index live |
|
| block free-text queries from leaving the machine |
| empty | optional, free, raises the CORE rate limit |
| empty | optional, free, raises the Semantic Scholar rate limit |
|
| log every outbound request locally |
configure(confidential_mode="on")With this enabled, free-text searches will not leave the machine unless a call
explicitly passes allow_external=true. Identifier lookups are unaffected,
since a DOI carries no unpublished reasoning. This matters for groups working on
unpublished hypotheses, where the wording of a search query is itself a
disclosure.
Index the papers you already have:
lib_index("/path/to/your/papers")Then search their full text:
lib_search("thermal denaturation midpoint")Find and retrieve something new:
lit_search("bacterial cell division regulators", limit=10)
lit_get("10.1038/s41467-018-08056-2") # metadata plus every legal route
lit_fetch("10.1038/s41467-018-08056-2") # download, store, index
lib_read("10.1038/s41467-018-08056-2", section="methods")Start from a structure:
pdb_entry("4HHB") # returns the entry AND its primary citationCheck what the server holds:
lib_status()tool | description |
| Federated search across the configured sources, merged and de-duplicated on DOI. Marks results already in your library. |
| Resolve a DOI, PMID, PMCID or title to full metadata plus every legal full-text route, without downloading. |
| Retrieve the best available full text, store it with provenance, extract and index it. |
| Papers citing a given DOI. |
| The bibliography of a paper, resolved, marking what you already hold. |
| Draft a reprint request to the corresponding author. Returns the text; sends nothing. |
tool | description |
| Full-text search across every indexed paper on your machine. |
| Read a held paper, optionally one section: |
| Index a directory of PDF, JATS XML or text files. |
| Holdings, licence and source breakdown, current configuration. |
tool | description |
| PDB metadata and its primary citation, resolving the DOI by title when RCSB omits it. |
| Sequence, annotated features, and cross-referenced PDB entries. |
tool | description |
| Contact address, library path, confidential mode, optional API keys. |
| Every request scilib has made, most recent last. |
lit_fetch works down an ordered ladder and stops at the first route that
returns a real document. The order is by fidelity, not convenience.
Already on disk. No network request.
Europe PMC fullTextXML. Sectioned JATS, the highest-fidelity form.
PubMed Central OA subset via the AWS Open Data bucket, preferring XML, then text, then PDF.
Unpaywall, publisher open access first, then repository copies.
OpenAlex best open-access location.
Preprint on bioRxiv, medRxiv or arXiv, clearly labelled as not the version of record.
No open copy. Reports this honestly and drafts an author request.
XML is preferred over PDF because it preserves section structure, which is what
makes lib_read(paper, section="surface plasmon resonance") a real operation. A
PDF flattens into an undifferentiated block of text.
A route that promises a PDF and returns HTML is a login wall, not a paper. scilib detects this and moves to the next route rather than storing it.
Everything stays local. The library, the index and the logs are files on your machine. scilib has no server component and no telemetry.
Every file is stamped with its source, source URL, licence and SHA-256, so a figure or a number quoted from a paper can be traced to the exact bytes it came from.
Licences are recorded, not assumed. Reusing a figure requires the licence,
not merely the citation. lib_status breaks holdings down by licence.
Outbound requests are logged to <library>/outbound_queries.log. Read it
with audit_log() at any time.
Rate limiting is shared across processes through a lock file, so several instances, or several colleagues behind one institutional NAT, queue against a single clock rather than collectively tripping a limit.
All sources are public, documented, and used as their operators intend.
source | coverage | notes |
~250M works, all disciplines | CC0, no key required | |
~45M biomedical records | ~6M with open full text as JATS | |
open-access articles | via the NCBI Cloud Service, a permitted automated route | |
DOI registration metadata | authoritative licence and funder data | |
~50M DOIs | legal free copies; requires a contact email | |
citation graph | open-PDF pointers, optional free key | |
preprints | includes published-version mapping | |
preprints | one request per three seconds | |
fully open-access journals | ||
European repositories | ||
~300M repository records | free API key required | |
structures and sequences |
PMC content carries the attribution its terms require: NIH NLM NCBI PubMed Central (PMC) Article Datasets, https://registry.opendata.aws/ncbi-pmc.
The server shows as failed or disconnected. Run it directly to see the error, since MCP clients usually report only that the connection closed:
.venv/bin/python scilib/server.py < /dev/nullIt should produce no output and wait. Any traceback is the real cause.
lib_search returns nothing.
Check that something is actually indexed with lib_status(). If chunks is 0,
run lib_index() over your paper directories first.
A PDF indexed with no text.
It is almost certainly a scan without OCR. These are reported by name in the
failures list rather than counted as successes. Run OCR over them, for example
with ocrmypdf, and re-index.
Searches return fewer results than expected.
lib_search accepts FTS5 syntax: "exact phrase", AND, OR, NOT, and
prefix*. A query that FTS5 cannot parse is retried in a quoted form rather
than failing, which can broaden it. Matching happens at chunk level first and
falls back to document level, so terms in different sections of one paper are
still found.
Rate-limit errors.
Set a contact address with configure(email=...), which grants access to the
polite pools. arXiv answers a rate limit with HTTP 406 rather than 429, which
can look like a malformed query; scilib backs off and retries automatically.
See CONTRIBUTING.md. In short: new sources are welcome if they are public APIs whose terms permit programmatic use. Additions that bypass access controls are out of scope and will not be merged.
Run the offline test suite before opening a pull request:
.venv/bin/python tests/test_offline.pyEvery test corresponds to a bug that actually occurred. If you fix one, add the test that would have caught it.
scilib is a thin client. Everything it is useful for was built by other people, most of it public infrastructure funded by grants and sustained by non-profits. Citations are a large part of how that funding is justified, so if scilib contributes to published work, please cite the sources it drew on rather than only this tool.
source | citation |
OpenAlex | Priem J, Piwowar H, Orr R. OpenAlex: A fully-open index of scholarly works, authors, venues, institutions, and concepts. arXiv 2022. 10.48550/arXiv.2205.01833 |
Europe PMC | Ferguson C, et al. Europe PMC in 2020. Nucleic Acids Research 2020. 10.1093/nar/gkaa994 |
PubMed Central | NIH NLM NCBI PubMed Central (PMC) Article Datasets, accessed via the AWS Open Data registry. https://registry.opendata.aws/ncbi-pmc |
Crossref | Hendricks G, et al. Crossref: The sustainable source of community-owned scholarly metadata. Quantitative Science Studies 2020. 10.1162/qss_a_00022 |
Unpaywall | Piwowar H, et al. The state of OA: a large-scale analysis of the prevalence and impact of Open Access articles. PeerJ 2018. 10.7717/peerj.4375 |
Semantic Scholar | Kinney R, et al. The Semantic Scholar Open Data Platform. arXiv 2023. 10.48550/arXiv.2301.10140 |
bioRxiv | Sever R, et al. bioRxiv: the preprint server for biology. bioRxiv 2019. 10.1101/833400 |
CORE | Knoth P, Zdrahal Z. CORE: Three Access Levels to Underpin Open Access. D-Lib Magazine 2012. 10.1045/november2012-knoth |
OpenAIRE | Manghi P, et al. The OpenAIRE Research Graph Data Model. 2019. 10.5281/zenodo.2643199 |
RCSB PDB | Berman HM, et al. The Protein Data Bank. Nucleic Acids Research 2000. 10.1093/nar/28.1.235 |
UniProt | The UniProt Consortium. UniProt: the Universal Protein Knowledgebase in 2025. Nucleic Acids Research 2024. 10.1093/nar/gkae1010 |
AlphaFold DB | Varadi M, et al. AlphaFold Protein Structure Database in 2024. Nucleic Acids Research 2023. 10.1093/nar/gkad1011 |
arXiv, DOAJ | No canonical citation; both are acknowledged here with thanks. |
Every DOI above was verified against Crossref and OpenAlex before being written, rather than recalled. Four of an initial set of remembered DOIs turned out to point at unrelated papers, which is the argument for checking them.
Built on the Model Context Protocol Python SDK (MIT) and httpx (BSD-3-Clause).
The implementation was written by Claude (Anthropic) in an extended pair-programming session, directed, reviewed and tested by the repository owner, who set the scope, the design constraints and the decision to use only legal open-access routes. This is stated because being precise about where work came from is the same discipline as being precise about where a number came from.
The test suite is part of that record. Every test in tests/test_offline.py
corresponds to a defect found during development, including a module that
shadowed a Python standard-library package, a case-sensitive DOI index that
silently lost full text for several major journals, and a chunked search index
that dropped any multi-term query spanning a section boundary.
If you maintain something that overlaps with this, the preferred outcome is one good tool rather than two partial ones. Open an issue and say what you have built; extending or integrating is more useful to everyone than a parallel implementation.
MIT for the code.
Retrieved content keeps whatever licence it arrived with. That licence is
recorded per file and reported by lib_status. scilib does not relicense
anything it downloads, and it is your responsibility to honour the terms
attached to each item, particularly when reusing figures.
Show what this tool has sent off the machine, most recent last.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only operation by using 'Show', and indicates the output ordering. However, it does not disclose any side effects, permission requirements, or whether the log is session-scoped or persistent. For a simple read-only tool, this is minimal but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose and ordering constraint. No wasted words; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so the return shape need not be described. However, the 'lines' parameter is undocumented both in schema and description, leaving the agent without clarity on its effect. The description is otherwise sufficient for a basic audit log, but the parameter gap lowers completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'lines' parameter or its meaning. An agent is left to guess that 'lines' controls the number of log entries returned. Since the description does not compensate for the undocumented parameter, this is a significant gap.
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 specific verb ('Show') and a clear resource ('what this tool has sent off the machine'), and specifies ordering ('most recent last'). This distinguishes it from sibling tools like lit_search or configure, which have unrelated purposes.
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 gives a clear context for when to use the tool: when you want to see what the tool has sent. It does not mention exclusions or alternatives, but since it is a unique audit function among the siblings, the usage is adequately implied. However, there is no explicit guidance on when not to use it or comparison to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the contact address, library location, or confidential mode.
The email goes to the polite pools of Crossref, Unpaywall, OpenAlex and NCBI. They ask for it, grant higher rate limits in return, and it is the only personal datum this tool sends anywhere.
confidential_mode 'on' blocks free-text queries from leaving the machine unless a call passes allow_external=true. Identifier lookups still work, since a DOI carries no unpublished reasoning.
| Name | Required | Description | Default |
|---|---|---|---|
| show | No | ||
| No | |||
| library | No | ||
| s2_api_key | No | ||
| core_api_key | No | ||
| confidential_mode | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses email privacy (sent to Crossref, etc.) and confidential_mode behavior, but omits side effects of other parameters like s2_api_key, core_api_key, and show, nor does it mention reversibility or immediate effects.
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 concise and front-loads the primary purpose. The narrative style is efficient, though the formatting could be more structured for quick scanning. No wasted words, but some information is buried in paragraphs.
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 6 parameters and no annotations, the description is incomplete. It fails to mention show, s2_api_key, and core_api_key, and provides only shallow detail on library. An agent cannot correctly set all options without additional knowledge, and the output schema is not explained.
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 explain all parameters. It covers email, library, and confidential_mode with some detail, but completely omits show, s2_api_key, and core_api_key, leaving those undocumented. The explanation for email and confidential_mode is helpful but incomplete for the full parameter set.
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: setting contact address, library location, or confidential mode. It distinguishes itself from sibling research tools by being a configuration tool, so an agent can immediately identify its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (for configuration) but provides no explicit when-to-use vs alternatives or exclusions. Since it's a unique config tool, the context is clear but not formally stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Index a directory of papers already on disk so lib_search can find them.
Handles PDF, JATS XML and text. limit of 0 means no cap; any other value
caps the scan and the result says so explicitly, because a capped scan
reported as a total is how an inventory lies.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| limit | No | ||
| recursive | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses supported formats (PDF, JATS XML, text) and the non-obvious `limit` behavior, including the explicit guarantee that capped scans are reported as capped. It does not cover side effects, permissions, or repeat-run behavior, but surfaces the most important caveats.
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 purpose is front-loaded, followed by format support and the critical `limit` caveat. Every sentence earns its place; there is no filler or redundant restatement of the schema.
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 description covers purpose, scope, supported formats, and the most error-prone edge case around `limit`. Since an output schema exists, return-value detail need not be repeated. The main missing piece is explicit `recursive` semantics, but overall the tool is well specified.
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 thoroughly explains `limit` (0 = uncapped; other values cap the scan and are disclosed in results) and implies `path` is a local directory. However, `recursive` behavior is left entirely to the schema, and supported formats are not tied to parameter semantics.
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 uses a specific verb ('Index') and resource ('a directory of papers already on disk'), and states the downstream purpose ('so lib_search can find them'). This clearly differentiates it from siblings like lib_search and lit_fetch, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: index local papers so they become discoverable by lib_search. The qualifier 'already on disk' implies it is not for fetching remote papers, but it does not explicitly enumerate when-not-to-use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a paper held locally, optionally one section of it.
section matches a heading case-insensitively, e.g. 'methods', 'surface
plasmon', 'results'. With no section, returns the abstract plus a list of
available headings, so a long paper can be read deliberately rather than
dumped into context.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | ||
| max_chars | No | ||
| identifier | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It explains non-obvious behavior: section matching is case-insensitive, and omitting section returns the abstract plus available headings. This is valuable transparency. It does not mention the effect of max_chars or error handling, but the core read behavior is well disclosed.
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 concise and front-loaded: the core purpose is in the first sentence, followed by just enough detail about section matching and the deliberate-reading fallback. Every sentence earns its place, and the examples are practical and clear.
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 output schema exists, so return values need not be explained. However, with three parameters and zero schema descriptions, the description should cover all parameters to be complete. It handles identifier and section well, but omits max_chars semantics, which could materially affect how the agent invokes the tool. Overall useful but not fully 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 thoroughly explains the 'section' parameter with examples and fallback behavior, and 'identifier' is clearly implied by 'Read a paper'. However, 'max_chars' is not described at all, leaving its truncation or output-limiting behavior undefined. Partial compensation, with one significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Read a paper held locally', with the optional scope of reading one section. It also distinguishes itself from sibling tools by emphasizing 'locally', which separates it from fetch/search/status tools. The purpose is immediately understandable and specific.
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 gives clear context that this tool is for locally held papershare, and it explains the recommended usage pattern: starting with no section to get abstract and headings, then reading a specific section. It does not explicitly name alternatives like lit_get or lit_fetch, but 'held locally' provides a useful discriminator.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across every paper already on this machine.
This is the tool to reach for FIRST. A paper on disk that nobody searched is invisible in exactly the way a paywalled one is, and the failure is quieter. Supports FTS5 syntax: phrases in "quotes", AND/OR/NOT, prefix*.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does most of the transparency work. It discloses the search scope (every local paper) and the supported FTS5 query syntax. It does not mention dependency on a local index or ordering/pagination behavior, but for a search tool this is reasonable.
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 with no fluff: the first states the core function, the second adds a memorable priority rationale, and the third gives essential syntax. The most important information is 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?
For a two-parameter tool with an output schema, the description covers purpose, scope, and query syntax well. It could mention that results depend on the local index or clarify `limit`, but an agent can still invoke the tool correctly from the provided information.
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 does for `query`, explaining phrase, boolean, and prefix syntax. The `limit` parameter is left to inference from its name and default, which is a minor but real gap.
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?
States a specific verb and resource: full-text search across every paper already on this machine. The local-machine scope clearly distinguishes it from lit_* tools and other library utilities without needing to open schemas.
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?
Explicitly says 'This is the tool to reach for FIRST' and explains the strategic reason: a paper on disk that nobody searched is as inaccessible as a paywalled one. It gives clear priority context but does not explicitly name alternatives or state 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.
What the local library holds, and the current configuration.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It implies a read-only status operation by saying 'what the library holds' and 'current configuration,' but it does not explicitly state that it has no side effects, whether it is expensive, or any access requirements. This is minimal but not misleading.
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 short, front-loaded sentence with no filler. Every word contributes to stating the tool's scope.
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 zero-parameter status tool with an output schema, the description identifies the two key aspects (holdings and configuration). It could add more context about what 'local library' means or what configuration details are included, but the presence of an output schema and absence of parameters keep it mostly 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?
The tool has no parameters, so the description cannot add parameter meaning. The empty schema is fully covered, and the baseline for a zero-parameter tool is 4.
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 names the resource ('local library') and the two things the tool reports: holdings and current configuration. It is not a tautology and is more specific than a generic 'status' title, though it lacks an explicit verb and does not contrast with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to call this tool versus alternatives like configure or lib_index. It only describes what information is returned; any usage context must be inferred from the name 'lib_status' and the word 'current'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Papers that cite this one. The route to the paper you did not know to search for: a keyword sweep only returns what you already thought to ask.
| Name | Required | Description | Default |
|---|---|---|---|
| doi | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of signaling safe behavior. It implies a read-only retrieval action by describing cited papers as a discovery routecompress, but it does not disclose limits, ordering, DOI resolution behavior, or missing-result handling. The output schema may cover return structure, but behavioral detail is thin.
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 definition is two sentences with no filler. The core purpose is front-loaded and the second sentence adds a memorable usage rationale, earning its 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?
The tool is a straightforward lookup with one required parameterchers, a default limit, and an output schema. The description gives enough context about purpose and use case. It does not enumerate sibling distinctions or edge cases, but for the tool's complexity this is nearly 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%, and the description does not explain the doi or limit parameters. 'This one' implicitly refers to the DOI, but the parameter's format and purpose are left to inference, and the optional limit is not mentioned at all. The schema provides only names and a default, so this is a meaningful gap.
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 identifies the resource: papers that cite a given paper ('Papers that cite this one'), which is a specific forward-citation lookup. It does not use an explicit verb like 'returns,' but the intended action is unambiguous and distinct from related tools like lit_references.
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 explains when this tool is valuable: when a keyword sweep cannot discover papers you did not already know to search for. This is practical guidance, though it does not explicitly name alternatives or state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download the best legal full text for a paper into the local library, extract its text, and index it. Prefers sectioned XML over PDF because XML preserves headings, which makes 'what did the Methods say' answerable.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | ||
| prefer_pdf | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It discloses side effects (downloads into the local library, extracts text, indexes) and the key format preference (sectioned XML over PDF, because headings matter). It does not discuss failure modes or authorization, but it is substantially more transparent than a minimal description.
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 wasted words. The core action is front-loaded, and the second sentence adds a purposeful rationale that helps the agent understand when XML matters.
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 description covers the main operational flow and rationale, and an output schema exists to describe return values. However, it is incomplete for correct invocation because it does not clarify the identifier format or the precise behavior of `prefer_pdf`, leaving the agent to guess critical parameter semantics.
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 needed to explain both `identifier` and `prefer_pdf`. It never mentions `identifier` at all, and `prefer_pdf` is only indirectly hinted at by the 'Prefers sectioned XML over PDF' sentence; the actual meaning of the boolean override is left unclear.
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 names a concrete action ('Download') and a concrete resource ('the best legal full text for a paper'), then clarifies the follow-up steps (extract and index it). This clearly distinguishes lit_fetch from the search, citation, and library-reading siblings by focusing on acquiring and indexing full text.
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 this tool is for when the full text of a paper is needed in the local library, especially when section structure matters for answering questions like 'what did the Methods say.' However, it never explicitly contrasts lit_fetch with lit_get, lit_request_copy, or lib_read, nor states 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.
Resolve a DOI, PMID, PMCID or title to full metadata plus every legal route to its full text. Does not download anything.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure. It states a key trait: 'Does not download anything', which implies a read-only operation, but it does not explicitly say the operation is read-only, nor does it mention potential network access, rate limits, or error behavior. The single behavioral note is helpful 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 a single, well-structured sentence that front-loads the core action and output, followed by a brief, important behavioral caveat. There is no redundancy or fluff; every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-oriented tool with an output schema present, the description covers the essential aspects: what the identifier can be, what it returns, and that it does not download. It omits edge-case behaviors (e.g., ambiguous titles, failure handling) but these are minor given the tool's simplicity and the existence of an output schema.
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 only defines a single 'identifier' parameter with no description (0% coverage). The description compensates fully by specifying that the identifier can be a DOI, PMID, PMCID, or title, giving the agent crucial information about accepted input formats that the schema lacks.
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 ('Resolve') and the resource (DOI, PMID, PMCID, or title) plus the output (full metadata and legal routes to full text). The phrase 'Does not download anything' helps distinguish it from likely siblings like lit_fetch or lit_request_copy, making its scope unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool by noting it does not download content, suggesting other tools for downloading, but it does not name any alternatives or provide explicit when-to-use vs. when-not-to-use guidance. The intent is inferable but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The bibliography of a paper, resolved to real records.
Reading a paper's reference list is how you find the work that nobody in your subfield cites. Accepts DOI:10.x, PMID:123, arXiv:1234.5678.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| identifier | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It discloses accepted input formats and the behavior that references are resolved to real records, which is useful. However, it does not mention read-only safety, pagination, errors, or whether the limit truncates results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and mostly front-loaded with the core definition. The second sentence adds motivational context rather than pure reference material, but it earns its place by clarifying why the tool matters. No filler or redundancy.
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 description is adequate for a simple lookup tool, especially with an output schema present. However, given no annotations and 0% schema coverage, it could further clarify limit semantics, read-only behavior, and how this relates to lit_cited_by or lit_get.
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 does specify the identifier formats (DOI:10.x, PMID:123, arXiv:1234.5678), which clarifies the main parameter. The 'limit' parameter is not explained, though its default of 40 is visible in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as a paper's bibliography/reference list and adds that the results are 'resolved to real records,' which meaningfully distinguishes it from simple citation extraction. It does not use an explicit imperative verb, but 'Reading a paper's reference list...' makes the action unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case: finding work outside your subfield by reading a paper's references. It does not explicitly state when to use this tool over lit_cited_by, lit_get, or lit_search, nor does it provide exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draft a reprint request to the corresponding author.
The pre-internet norm and still the highest-yield route for a genuinely unavailable paper. Authors may lawfully share their own work for scholarly correspondence. Returns the draft; it does not send anything.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states that the tool returns a draft and does not send anything, which is a key behavioral disclosure. It also notes that authors may lawfully share their own work, adding legal/scholarly context. No annotations are provided, so the description carries the burden well.
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 concise and well-structured, with the core action stated first, followed by context and a clear behavioral note. Every sentence adds value without 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?
The description covers the tool's purpose and key behavior, but lacks details about the input identifier and the output format. Since an output schema exists, return values may be documented there, but the identifier semantics remain unclear. For a simple one-parameter tool, this is adequate but not 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?
The schema has one parameter, 'identifier', with no description. The tool description does not explain what 'identifier' refers to (e.g., paper ID, DOI, URL). With 0% schema coverage, the description should compensate, but it doesn't clarify the identifier format or source.
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: drafting a reprint request to the corresponding author. It distinguishes itself from siblings by emphasizing it returns a draft and does not send anything, which is a unique behavior among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use this tool: for obtaining a genuinely unavailable paper via the author, which is the highest-yield route. It doesn't explicitly name alternatives or exclusions, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the open scholarly record across several indexes at once.
sources is a comma-separated list. Available:
openalex ~250M works, all disciplines, open catalogue
europepmc ~45M biomedical records, ~6M with open full text
semanticscholar citation graph, open-PDF pointer, one-line summaries
arxiv physics/quant-bio/CS preprints
doaj articles in fully open-access journals
openaire European repositories and funder outputs
core ~300M repository records (needs a free API key)
The repository sources matter for paywalled work: a closed paper very often has a legal author manuscript deposited under a funder mandate.
Results are merged and de-duplicated on DOI. Each carries open-access status, licence, and whether full text is retrievable.
allow_external exists because a free-text query leaves this machine. Set
confidential_mode in configure() to make that an explicit decision per call.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| sources | No | openalex,europepmc,semanticscholar | |
| year_to | No | ||
| year_from | No | ||
| allow_external | No | ||
| open_access_only | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: results are merged and de-duplicated on DOI, each result includes OA status/licence/full-text retrievability, and a free-text query leaves the machine. It also flags that core requires a free API key. It stops short of rate limits or auth specifics, but covers the main safety and data-handling traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, uses structured list formatting for sources, and includes only functional extras (repository value, allow_external behavior). It is longer than minimal, but the complexity of the tool and the need to explain sources justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 7 parameters, and 0% schema coverage, the description covers the non-obvious aspects (source choice, external data flow, de-duplication) and leaves clear parameter meanings to their names. An output schema exists, so return values are handled. Minor omissions like query syntax or pagination behavior prevent a 5.
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 meaningfully explains sources with per-index details and clarifies allow_external's purpose. The remaining parameters (query, limit, year_from, year_to, open_access_only) are self-explanatory by name, so this is adequate compensation for the ambiguous ones.
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 opens with 'Search the open scholarly record across several indexes at once', which is a specific verb, resource, and scope. It distinguishes itself from sibling tools like lit_get and lit_fetch by emphasizing multi-index search and lists the exact indexes available.
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 gives clear context for when to use repository sources for paywalled work and explains the purpose of allow_external in relation to confidential_mode. It does not explicitly name alternative tools or when-not-to-use, but the context strongly implies the tool's role compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Metadata and the PRIMARY CITATION for a PDB entry.
Coordinates do not carry the analysis. If a design rests on a structure it rests on the paper that deposited it, and that paper is one lookup away. Resolves the DOI by title when RCSB omits it, which it often does for older entries, i.e. exactly the ones nobody has read.
| Name | Required | Description | Default |
|---|---|---|---|
| pdb_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses a non-obvious behavior: resolving the DOI by title when RCSB omits it, and notes this is common for older entries. It does not mention failure modes or exact output structure, but the output schema covers the return shape and the disclosed fallback is genuinely useful.
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 short and front-loaded, with the core output stated first and the DOI-resolution behavior second. The rhetorical line about coordinates and papers is not strictly necessary but reinforces the usage context without bloating the definition.
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 one-parameter lookup tool with an output schema, the description covers the main behavior and a relevant edge case (older entries missing DOIs). It does not describe failure behavior such as unknown PDB IDs or unresolvable DOIs, but those are not needed for basic tool selection and invocation.
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 single required parameter, pdb_id, is self-descriptive and the description ties it to PDB/RCSB entries, so an agent knows what to pass. However, schema description coverage is 0% and the description provides no format, examples, or accepted values. This is a minor gap because the parameter is obvious and only one is required.
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 identifies the resource (PDB entry) and the two key outputs: metadata and the primary citation. It also adds a distinguishing behavior (DOI resolution by title when RCSB omits it), which helps separate this from the sibling literature and UniProt tools. The lack of an explicit verb is minor because the intent is immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a strong usage rationale: if a design relies on a structure, the underlying paper is the source of analysis, and this tool provides that paper in one lookup. It does not explicitly name sibling alternatives or state when not to use it, so it falls 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.
UniProt record: sequence, features, and cross-referenced PDB entries.
| Name | Required | Description | Default |
|---|---|---|---|
| accession | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only lists the content returned (sequence, features, PDB cross-references) and does not mention error handling, authentication, read-only nature, or any side effects. This is insufficient for a retrieval tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no unnecessary words, but it is under-specified. Conciseness is not achieved because critical information is missing; it is terse rather than 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?
While an output schema exists, the description fails to explain usage context or parameter semantics. It lacks guidance on when to use this tool and what the accession parameter requires. An agent cannot confidently invoke it based on this description alone.
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%, and the description does not mention the 'accession' parameter at all. There is no explanation of what an accession is, its format, or any constraints beyond the schema's string type. The description adds no value to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (UniProt record) and its content (sequence, features, cross-referenced PDB entries), distinguishing it from sibling tools like pdb_entry. It lacks an explicit verb but the intent to retrieve an entry is clear from the name and content description.
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 such as pdb_entry or lit_*. There is no mention of context, exclusions, or conditions that would route an agent to this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0audit_logconfigurelib_indexlib_readlib_searchlib_statuslit_cited_bylit_fetchlit_getlit_referenceslit_request_copylit_searchpdb_entryuniprot_entryScored across 14 tools
Every tool has a distinct role: lit_* handles external literature, lib_* handles the local library, pdb_entry/uniprot_entry are clearly separated database lookups, and configure/audit_log are system-level. Even similar actions like lit_get versus lit_fetch are cleanly differentiated by 'resolve routes' vs 'download and index'.
Names generally follow a clear snake_case convention with lit_ and lib_ prefixes, making the family relationships obvious. Minor deviations exist—lit_cited_by and lit_references are noun-like rather than verb-action, and pdb_entry/uniprot_entry/audit_log do not follow the verb_noun pattern—but the overall scheme remains highly predictable.
Fourteen tools is within the ideal range and each tool earns its place. The set covers external search, retrieval, citation analysis, local-library management, database lookups, configuration, and audit, without redundant or filler tools.
The scholarly workflow is well covered end-to-end: discover via lit_search, resolve via lit_get, obtain full text via lit_fetch, explore context via lit_cited_by/lit_references, and fall back to lit_request_copy. Local-library tools close the loop with lib_index, lib_search, and lib_read, while configure and audit_log provide necessary governance.
Federated search of books and papers, BibTeX/RIS citations, open-access retrieval and reading.
Multi-engine scholarly research server for search, traversal, full text, and reading lists.
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Academic paper search, scientific literature, citation analysis, arXiv & semantic related-work.
