Skip to main content
Glama
fabianofilho

radar-papers-mcp

by fabianofilho
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

buscar_papers_novos

Search newly added papers in PubMed and medRxiv by monitored topic, date window, and result limit. Get paper keys and original links to proceed with summarization.

Instructions

Papers que entraram no PubMed ou no medRxiv nos últimos dias, por tópico monitorado.

Consulta a base local, alimentada pelo sync (papers-cli sync, em geral agendado por um timer diário). "Novo" é pela data de entrada na fonte (Entrez no PubMed, postagem no medRxiv), não pela data da edição da revista. Cada resultado traz a chave para usar em resumir_paper e o link original. 'total' conta todos os papers do período; se passar de 'limite', o aviso diz.

Args: topico: nome de um tópico configurado; vazio devolve todos. Caixa e acento não importam, e basta um trecho com palavras inteiras do nome ("fairness"). Se não corresponder a um único tópico, a resposta traz a lista dos tópicos válidos no aviso. dias: tamanho da janela, de 1 a 365, a contar de hoje. limite: máximo de resultados devolvidos, de 1 a 200. Os mais recentes vêm primeiro.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
diasNo
limiteNo
topicoNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
diasYes
avisoNo
totalYesQuantos papers o período tem, mesmo além do limite
topicoYes
resultadosYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / limite
      Added value: +{
+  "default": 50,
+  "title": "Limite",
+  "type": "integer"
+}
    • addedOutput schema / $defs / PaperEncontrado / properties / data_entrada
      Added value: +{
+  "anyOf": [
+    {
+      "format": "date",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Data em que o paper entrou na fonte; é a que define 'novo'",
+  "title": "Data Entrada"
+}
    • addedOutput schema / $defs / PaperEncontrado / properties / data_publicacao / description
      Added value: +"Data da edição da revista (ou da postagem do preprint)"
    • addedOutput schema / properties / total / description
      Added value: +"Quantos papers o período tem, mesmo além do limite"
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does so thoroughly: it defines 'new' by source entry date, explains the local database sync, specifies that results include the key and link, describes the total/warning behavior when exceeding the limit, and details topic-matching nuances such as case/accent insensitivity and ambiguous-topic handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well structured: a one-sentence summary, followed by behavioral context, then a clear Args list. It is front-loaded with the essential purpose and contains no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read/search tool with an output schema, the description covers everything needed to invoke it correctly: source, freshness definition, parameter semantics, output content, warnings, and the link to the sibling tool. Very little is left to guesswork.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

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. The Args block fully documents all three parameters: topico's matching and failure behavior, dias' 1-365 window counted from today, and limite's 1-200 cap with newest-first ordering. This is substantial value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as a search/lookup operation for papers newly entered in PubMed or medRxiv, scoped by monitored topic. It also differentiates from the only sibling, resumir_paper, by stating each result carries the key to use in that summarization tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context for use: consult a local database fed by a scheduled sync, filter by topic, time window, and result limit, and then use the resulting key with resumir_paper. It does not explicitly list when-not-to-use or alternative conditions, but the workflow context is unambiguous enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools