my-lit-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MY_LIT_DB | No | Optional override for the database file path. | |
| NCBI_API_KEY | No | Free NCBI API key for PubMed E-utilities; increases rate limit from ~3 req/s to ~10 req/s. | |
| MY_LIT_CONFIG | No | Optional override for the config file path. | |
| MY_LIT_PDF_DIR | No | Optional override for the PDF cache directory path. | |
| MY_LIT_DATA_DIR | No | Project data directory. Set to the absolute path passed to `my-lit init` (e.g. `…/my-lit-mcp/.my-lit`). Resolution order: MY_LIT_DATA_DIR → .my-lit-path → conventional ./.my-lit if it already has config.yaml. | |
| UNPAYWALL_EMAIL | No | Email address for Unpaywall; required for OA PDF resolution. | |
| OPENALEX_API_KEY | No | Free API key for OpenAlex; only needed if an OpenAlex query is enabled. | |
| SEMANTIC_SCHOLAR_API_KEY | No | Free API key for Semantic Scholar; avoids shared-pool 429s and increases rate limits. |
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 |
|---|---|
| ensure_workspaceA | Create project-scoped .my-lit (config, DB, PDFs) if missing. Call this first in a new project. Pass project_root as the absolute path of the workspace/repo using this MCP. Defaults to /.my-lit unless data_dir or MY_LIT_DATA_DIR is set. Idempotent: safe when already initialized. |
| list_queriesB | List configured ingest queries. |
| list_seedsB | List seed papers stored in the local DB (preferred over config.yaml). |
| resolve_seedB | Look up seed candidate metadata without saving. Use before add_seed if unsure. |
| add_seedC | Add or update a seed paper in the DB. Prefer s2_id or doi; title_query returns candidates. |
| remove_seedB | Delete a seed by local seed_id or Semantic Scholar s2_id. |
| set_seed_enabledB | Enable or disable a seed without deleting it. |
| search_localC | Search title/abstract/fulltext in the local corpus. |
| search_fulltextC | Search only parsed PDF body text. |
| get_paperB | Fetch one paper with feedback and parse status. |
| get_fulltextC | Return stored full text (truncated). |
| new_sinceC | Papers ingested after an ISO timestamp. |
| must_readD | High-score or must_read-labeled papers. |
| similar_toD | Local title-keyword similarity. |
| mark_feedbackC | Upsert feedback: relevant | not_relevant | must_read. |
| pipeline_statusC | Last run, OpenAlex daily calls, PDF parse counts, seed count. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 16 tools
Most tools target distinct resources or actions: seed CRUD, feedback, workspace setup, and retrieval are clearly separated. The main overlap is between search_local (which includes fulltext) and search_fulltext, plus similar_to may be confused with local search, though descriptions clarify the intended scope.
Tool names consistently use snake_case and are readable, with many following verb_noun patterns like list_seeds, add_seed, get_paper, and search_local. A few names such as new_since, must_read, and similar_to deviate from verb_noun but remain understandable and stylistically consistent.
The 16 tools are just above the typical 3-15 range, but each appears to serve a specific function across workspace setup, seed management, search, retrieval, feedback, and status reporting. The set is slightly heavy but not bloated for a local literature management server.
Core seed CRUD, search, fulltext retrieval, feedback, and corpus status are covered well. However, query management is only partially exposed via list_queries with no add/remove/update tools, and there is no explicit ingestion or PDF parsing trigger, which are notable gaps for the literature workflow.