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. |
| list_projectsA | List known projects with their folders. available=false means the folder moved or is missing. |
| open_projectB | Register an existing project folder, for example after it was moved or copied from elsewhere. |
| guideC | Rules and how-to for a stage: workflow, question, screening, fetch, wiki, extraction, duplicates, synthesis or ontology. |
| validate_questionA | Check a drafted PICO/PCC search question and return a question_id for start_search. Show the result 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_searchB | Check a running search, retry a failed one, or retry just the failed sources of a completed run. |
| set_screening_criteriaC | Save the researcher's inclusion and exclusion criteria for screening. Rules: guide("screening"). |
| next_screening_batchB | Get the next unscreened titles/abstracts with the criteria to judge them against. |
| record_screening_decisionsB | Record screening decisions; include/exclude need a verbatim quote as evidence. |
| review_articleC | Record the researcher's own include/exclude decision and reason for one article. |
| fetch_articlesA | 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_articleB | Get the next page of article text to extract wiki entities from (a JSON header plus the page). |
| get_article_pageA | Re-read one page of a fetched article (pages are numbered from 0). |
| record_extractionB | Record the entities and relationships extracted from one page (re-recording replaces it). Rules: guide("extraction"). |
| find_entitiesB | Search a project's wiki entities by name, alias, acronym, or spelling variant. |
| list_duplicate_candidatesB | List entity pairs that may be the same thing, with an example mention of each. |
| resolve_duplicatesC | Merge or keep distinct pairs of possible duplicate entities. Rules: guide("duplicates"). |
| merge_entitiesC | Merge entities into one, and/or rename or retype an entity. |
| next_synthesisC | Get the next entity whose wiki page needs writing, with its evidence from the project. |
| record_synthesisB | Save an entity page written only from next_synthesis evidence. Rules: guide("synthesis"). |
| export_wikiB | Rewrite every Markdown page of a project's wiki (entities, sources, index, log) from its database. |
| list_runsB | List a project's searches (runs), newest first. |
| get_run_statusA | Show a run's progress in every stage and the available next steps. |
| list_articlesC | List a run's articles with their screening, fetch, and wiki status. |
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 26 tools
Most tools target distinct workflow stages (project setup, search, screening, fetching, wiki extraction, synthesis), so an agent can usually tell them apart. A few boundaries are fuzzy, especially between record_screening_decisions and review_article, and between resolve_duplicates and merge_entities, but descriptions provide enough guidance.
Nearly all tools use snake_case with a predictable verb-led pattern such as list_articles, create_project, record_extraction, and resolve_duplicates. Minor deviations like guide and wiki_tasks are readable but slightly break the strict verb_noun convention.
26 tools is heavy for a single MCP server, and several stage-specific helpers could likely be consolidated. The complex systematic-review pipeline justifies more tools than a simple CRUD server, but the count is still at the borderline-heavy end.
The surface covers the core review lifecycle: projects, question validation, search, screening, fetching, extraction, wiki curation, synthesis, and export. Minor gaps like project deletion/renaming or criteria updates are workable around, but not every lifecycle operation is exposed.