Monitors PubMed for research papers matching configurable topics, retrieves paper metadata and abstracts via the E-utilities API, and stores results locally with deduplication by DOI.
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., "@radar-papers-mcp busque e resuma papers novos sobre multicalibração dos últimos 7 dias"
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.
Servidor MCP que monitora PubMed e medRxiv por tópicos de pesquisa configuráveis e resume os papers com um LLM local. Guarda o resultado numa base local, deduplicado por DOI.
Sobre o que esta ferramenta faz e não faz
O resumo sai do abstract, não do texto completo. Ele serve para triagem: decidir se vale abrir o paper. Não substitui a leitura.
O resumo é gerado por LLM e pode errar. Confira os números no abstract original — o link vem em toda resposta.
A cobertura depende das suas queries. O que não casa com a query configurada simplesmente não aparece; ausência de resultado não significa ausência de literatura.
O quê | Versão | Para quê |
Python | 3.12+ | runtime |
recente | dependências e venv | |
Um LLM local com API OpenAI-compatible | — | resumo dos papers |
Chave da NCBI (opcional) | — | eleva o rate limit de 3 para 10 req/s |
Related MCP server: kavi-research-assistant-mcp
git clone https://github.com/fabianofilho/radar-papers-mcp.git
cd radar-papers-mcp
uv sync
cp .env.example .envVariável | Padrão | Observação |
|
| llama.cpp. Ollama: |
|
| llama.cpp e LM Studio aceitam qualquer nome |
| vazio | |
|
| base local |
|
| tópicos monitorados |
|
| horário fixo do sync agendado |
Os tópicos ficam em config/topicos.yaml. Cada um tem duas configurações, porque as
fontes funcionam de forma diferente:
topicos:
- nome: multicalibração
pubmed: multicalibration[All Fields] # sintaxe das E-utilities
medrxiv: # palavras simples, filtradas localmente
- multicalibration
- multi-calibrationuv run papers-cli topicos
uv run papers-cli sync --dias 30
uv run papers-cli buscar "multicalibração"
uv run papers-cli resumir "10.1016/j.exemplo.2026.100217"claude mcp add radar-papers --scope user \
-e DUCKDB_PATH=/caminho/para/radar-papers-mcp/data/papers.duckdb \
-e TOPICOS_PATH=/caminho/para/radar-papers-mcp/config/topicos.yaml \
-e QWEN_ENDPOINT=http://127.0.0.1:8080/v1 \
-e QWEN_MODEL=local-model \
-- uv --directory /caminho/para/radar-papers-mcp run radar-papers-mcpbuscar_papers_novos(topico="", dias=7)Papers do período na base local, com a chave para usar no resumo e o link original.
resumir_paper(paper_id: str){
"titulo": "Mortality risk ranking after medical emergency team review…",
"url": "https://pubmed.ncbi.nlm.nih.gov/42761253/",
"origem": "llm",
"resumo": {
"problema": "Validação externa e redesenvolvimento de modelos preditivos de mortalidade após revisão da equipe de emergência.",
"metodo": "Coorte multicêntrica em quatro hospitais, 1.937 adultos.",
"achado_principal": "O modelo original discriminou bem (AUC 0,80) mas com estimativas variáveis entre hospitais; o novo modelo chegou a AUC 0,84 com menos variáveis.",
"relevancia": "Mostra que a discriminação pode ser robusta mesmo quando a calibração absoluta varia entre instituições."
}
}Esse é um retorno real. O resumo fica cacheado: o mesmo paper não é resumido duas vezes.
Fonte | API | Limite |
PubMed | E-utilities ( | 3 req/s sem chave, 10 com chave |
medRxiv |
| sem busca por termo; paginado de 100 em 100 |
O rate limit da NCBI é aplicado de verdade — a primeira tentativa de teste deste projeto
recebeu {"error": "API rate limit exceeded"}. O fetcher espaça as requisições conforme a
chave configurada.
O medRxiv não aceita busca por termo: a API é consultada uma vez por janela e o filtro por tópico é local, sobre título e abstract.
O mesmo paper casa com mais de um tópico, e um preprint do medRxiv pode sair depois num periódico indexado no PubMed com o mesmo DOI. A chave é o DOI (ou o id da fonte quando não há DOI), e um paper já conhecido ganha o novo tópico na lista em vez de virar uma segunda linha.
Sem abstract, não há resumo. Um paper sem abstract devolve erro explícito em vez de um resumo gerado a partir do título. Resumir texto vazio produz exatamente o tipo de invenção plausível que torna a ferramenta inútil para pesquisa.
A janela do medRxiv custa caro. Uma janela larga traz milhares de preprints que serão descartados no filtro local. O padrão é limitado a 5 páginas (500 preprints) por execução.
A query do PubMed é sua responsabilidade. Uma query mal formada devolve zero sem erro.
Teste no PubMed antes de colocar no YAML — na prática,
buscas muito específicas devolvem pouquíssimo (multicalibration retorna ~14 resultados
em toda a base).
O resumo não é verificado contra o abstract. Diferente do projeto de protocolos, aqui
não há conferência de citação literal: o campo achado_principal pode conter um número
que o modelo interpretou errado.
Só PubMed e medRxiv. Sem arXiv, bioRxiv, Scopus ou Web of Science.
Sai da máquina: requisições ao PubMed (NCBI) e ao medRxiv. Se você configurar uma chave da NCBI, ela vai junto nas requisições — é o funcionamento normal da API.
Não sai: seus tópicos de pesquisa ficam no arquivo local; as queries vão às APIs como qualquer busca.
O abstract vai para o seu LLM no resumo.
Sem telemetria, sem analytics.
Veja CONTRIBUTING.md. PubMed e medRxiv são serviços públicos: não rode sincronização em loop nem contorne o limitador de taxa.
MIT — este projeto é agregação de literatura e metadados abertos, sem contato com regulação, conduta clínica ou dado de paciente.
Construído no contexto do IA.med.
Papers novos do PubMed e do medRxiv sobre os tópicos monitorados.
Consulta a base local, que é sincronizada de madrugada. Cada resultado traz a chave para usar em resumir_paper e o link original.
Args: topico: filtra por um tópico configurado; vazio devolve todos. dias: tamanho da janela, em dias, a contar de hoje.
| Name | Required | Description | Default |
|---|---|---|---|
| dias | No | ||
| topico | No |
| Name | Required | Description |
|---|---|---|
| dias | Yes | |
| aviso | No | |
| total | Yes | |
| topico | Yes | |
| resultados | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the disclosure burden. It mentions that the local database is synced early morning, indicating potential staleness, and that results include a key and link. However, it does not disclose result limits, pagination, or whether the operation is read-only, which is a meaningful gap for a tool with no annotations.
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 compact paragraph followed by a clean argument list. The main purpose is front-loaded, and each sentence adds value—no fluff or repetition.
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 simple search with two parameters and an output schema exists (though not shown). The description covers the workflow with resumir_paper and the source, but it omits details like result count, sorting, or pagination. Given the output schema likely handles return structure, this is a minor gap, so a 4 is appropriate.
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 fully compensates. It clearly explains 'topico' as a filter (empty returns all) and 'dias' as a window in days from today. This adds meaning beyond the bare schema, which only shows types and defaults.
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 retrieves new papers from PubMed and medRxiv on monitored topics, and specifies that each result includes a key for resumir_paper and the original link. This is a specific verb–resource combination (implicit 'search' for papers) and distinguishes from the sibling tool by the workflow it feeds.
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 the tool is for finding new papers and that the returned key is meant for resumir_paper, establishing a clear usage context. It does not explicitly state when not to use it, but with only one sibling (a summarizer), the division of labor is obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resumo estruturado de um paper: problema, método, achado e relevância.
O resumo vem do abstract, não do texto completo, e é gerado pelo LLM local. Fica cacheado: o mesmo paper não é resumido duas vezes. Papers sem abstract devolvem erro claro em vez de um resumo inventado.
Args: paper_id: a chave devolvida por buscar_papers_novos (o DOI, em geral).
| Name | Required | Description | Default |
|---|---|---|---|
| paper_id | Yes |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| aviso | No | |
| chave | Yes | |
| origem | Yes | llm, cache ou indisponivel |
| resumo | No | |
| titulo | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with no annotations, the description discloses key behaviors: the summary is based only on the abstract, it is generated by a local LLM, results are cached so the same paper is not summarized twice, and papers without an abstract yield a clear error rather than an invented summary. This gives the agent a reliable model of the tool's side effects and edge cases.
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 dense sentences plus a one-line parameter note. Every sentence earns its place: output structure, input source, caching behavior, error handling, and parameter provenance. There is 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?
For a one-parameter tool with an output schema present, the description covers what is produced, where the input comes from, how the tool behaves, and what happens in the failure case. The presence of an output schema means the description does not need to detail the return shape, and nothing else needed for correct invocation is missing.
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 only lists paper_id as a string with no description, so schema description coverage is 0%. The description compensates by explaining that paper_id is the key returned by buscar_papers_novos and is generally a DOI, which provides essential provenance and format semantics beyond the bare 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 opens with 'Resumo estruturado de um paper: problema, método, achado e relevância', which names the resource (a paper) and the specific structured output. This clearly distinguishes the tool from the sibling buscar_papers_novos, which is about finding new papers rather than summarizing one.
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 Args section states that paper_id is 'a chave devolvida por buscar_papers_novos', which tells an agent this tool should be invoked on results from the sibling search tool. It does not explicitly state when not to use it, but the single-sibling context and clear input provenance make the usage situation clear enough.
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.0buscar_papers_novosresumir_paperScored across 2 tools
The two tools have clearly distinct purposes: one discovers new papers, the other summarizes a specific paper. There is no overlap or ambiguity about which tool to use.
Both tool names follow the same verb_noun pattern in Portuguese: buscar_papers_novos and resumir_paper. This is highly predictable and consistent.
With only two tools, the server feels minimal but not unreasonable for its narrow scope. It covers a simple search-and-summarize workflow, though it is borderline thin.
The core workflows are covered: discovering papers and summarizing them. A minor gap is the lack of a way to list configured topics used by the search filter, but the server's stated purpose is otherwise satisfied.
Search PubMed/Europe PMC, fetch articles and full text (PMC/EPMC/Unpaywall), citations, MeSH terms.
Extract papers from ArXiv — titles, abstracts, authors, categories & PDF links. Monitor new AI, phys
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Extract structured data points from research papers and other documents with an LLM.
