med-lit-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NCBI_EMAIL | Yes | Required for PubMed/PMC search and for fetching. Also sent to Unpaywall, which requires a contact email. Use a real address. | |
| S2_API_KEY | No | Alternative name for SEMANTIC_SCHOLAR_API_KEY. Enables Semantic Scholar by default. Without a key it shares a public rate limit that usually answers HTTP 429, so it is skipped unless requested. | |
| NCBI_API_KEY | No | Optional; raises NCBI rate limits. | |
| MED_LIT_STAGES | No | Optional, for advanced users. Exposes only the tools up to a stage: `search`, `screening`, `fetch` or `wiki` (default: all). For example, `fetch` hides the 11 wiki tools. Clients that load tools on demand rarely need this; it helps with clients that load every tool up front. Project, status and guide tools are always available. | |
| OPENALEX_API_KEY | No | Optional OpenAlex key. | |
| MED_LIT_STATE_DIR | No | Where the list of known projects is kept. Default: `$XDG_DATA_HOME/med-lit-mcp` or `~/.local/share/med-lit-mcp`. | |
| MED_LIT_PROJECTS_DIR | No | Where new projects are created when no path is given. Default: `~/med-lit`. | |
| SEMANTIC_SCHOLAR_API_KEY | No | Enables Semantic Scholar by default. Without a key it shares a public rate limit that usually answers HTTP 429, so it is skipped unless requested. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_projectB | Create a project: one folder per review, holding its wiki and (hidden) its data. |
| project_settingsA | Show or change a project's settings (med-lit.settings.json): search years, records per source, preprints, fetch limit and mode, pages per article, and more. Change them only as the researcher asks. |
| list_projectsA | List known projects with their folders. available=false means the folder moved or is missing. |
| open_projectA | Register an existing project folder, for example after it was moved or copied from elsewhere. |
| guideB | Rules and how-to for a stage: workflow, question, screening, fetch, wiki, extraction, duplicates, synthesis or ontology. |
| validate_questionB | Check a drafted PICO/PCC search question against the project's settings and return a question_id for start_search. Show the result, including settings, to the researcher and wait for approval. Rules: guide("question"). |
| start_searchA | Search the literature databases with an approved question; creates a run in the project. If search_status is 'running', call resume_search(run_id). |
| resume_searchA | Check a running search, retry a failed one, or retry just the failed sources of a completed run. |
| add_skipped_articlesA | Add articles that were skipped for having no DOI, PMID or PMCID. Use only when the researcher asks for them by name; they then need screening. |
| set_screening_criteriaB | Save the researcher's inclusion and exclusion criteria for screening. Rules: guide("screening"). |
| next_triage_batchA | Get untriaged titles with the question and criteria, to score 0-3 before screening. |
| record_triage_scoresC | Record the 0-3 title scores that decide which articles each session screens. |
| next_screening_batchC | Get the next titles/abstracts of this session (20 best-triaged articles) with the criteria. |
| record_screening_decisionsB | Record screening decisions; include/exclude need a verbatim quote as evidence. |
| review_articleB | Record the researcher's own include/exclude decision and reason for one article. |
| fetch_articlesB | Fetch full text of included articles (PMC, Unpaywall open access, else abstract); repeat while remaining > 0. Rules: guide("fetch"). |
| wiki_tasksB | Start here to build or update the wiki: the current step as self-contained tasks, each sized for one fresh subagent. Rules: guide("wiki"). |
| next_wiki_articleA | Get the next unextracted page of article text (a JSON header plus the page); it repeats until record_extraction records it. An article whose text changed loses its old extraction first. |
| get_article_pageA | Re-read one page of a fetched article, e.g. to check a quote; next_wiki_article serves the pages still to extract. Reads only (may create the project database). |
| record_extractionB | Record the entities and relationships extracted from one page (re-recording replaces it). Rules: guide("extraction"). |
| find_entitiesA | Search a project's wiki entities by name, alias, acronym, or spelling variant, e.g. to reuse an entity's id while extracting. Reads only (may create the project database). |
| list_duplicate_candidatesA | List pending entity pairs that may be the same thing, with an example mention of each; decide them with resolve_duplicates. Reads only (may create the project database). |
| resolve_duplicatesA | Decide pairs from list_duplicate_candidates: merge (irreversible; keep picks the survivor) or distinct (not suggested again). Rules: guide("duplicates"). |
| merge_entitiesA | Merge entities into one (irreversible), and/or rename or retype an entity, by id. For pairs from list_duplicate_candidates use resolve_duplicates. |
| next_synthesisB | Get the next entity whose wiki page needs writing or updating, with its evidence; it repeats until record_synthesis saves it. Rules: guide("synthesis"). |
| record_synthesisA | Save an entity page from next_synthesis, replacing the stored one: a new page, or only the changed sections of an update. Rules: guide("synthesis"). |
| export_wikiB | Rewrite every Markdown page of a project's wiki (entities, sources, index, log) from its database. |
| list_runsA | List a project's searches (runs), newest first. |
| get_run_statusA | Show a run's progress in every stage and the available next steps; check it rather than chat history. Reads only (may create the project database). |
| list_articlesB | List a run's articles with their screening, fetch, and wiki status. |
| bot_startA | Begin a scheduled bot run: lock the project and search its look-back window for new articles. |
| bot_nextA | Advance a bot run after bot_start: returns the next step (wait, triage, screen, fetch, wiki or
finish) with a |
| bot_finishA | End a bot run: refresh the wiki, write the update report, and return the message to reply with. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| plan_search | Draft and validate a structured search for a research question. |
| screen_run | Screen a run's search results against criteria. |
| build_wiki | Build the evidence-linked wiki for a run's fetched articles. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 33 tools
Descriptions are detailed and mostly stage-scoped, clearly separating triage, screening, fetching, extraction, wiki, synthesis, and duplicate resolution. Some boundaries blur between record_screening_decisions and review_article, and between the manual next_*/record_* workflow and the bot_start/bot_next/bot_finish orchestration.
All tool names use snake_case, which keeps the set readable and predictable at a high level. However, it mixes verb_noun forms like start_search and record_extraction with noun/prefixed forms like guide, project_settings, next_synthesis, and bot_start.
33 tools is heavy, though the broad literature-review lifecycle gives some justification for a large surface. There is likely redundancy between the bot orchestration tools and the many manual next_*/record_* stage tools.
The surface covers project setup, question validation, search, triage, screening, fetching, extraction, wiki/synthesis, duplicate resolution, export, and bot runs, leaving few dead ends. Minor gaps remain, such as no explicit delete/archive project or remove-article operation.