Documentación en coreano: README.ko.md
A single MCP server that pulls academic + code + medical-device-regulatory trend data from seven sources and renders newspaper-style briefings — with per-domain tuning baked in.
Fuente | Herramientas | Notas |
arXiv |
| Round-robin por categoría para que las categorías pequeñas no sean eclipsadas por las grandes |
PubMed |
| Resúmenes completos vía |
HF Daily Papers |
| Ordenado por votos de la comunidad (reemplaza la API de PwC que dejó de funcionar) |
GitHub |
| Scraping de la página de tendencias + API de búsqueda con filtro de fecha |
Hugging Face |
| Modelos / datasets / spaces, en tendencia o recientes |
openFDA 510(k) |
| Autorizaciones de dispositivos |
openFDA Recalls |
| Eventos de retirada con filtro de clase |
(agregadores) |
| Llamadas paralelas a múltiples fuentes |
trends_briefing es la herramienta principal: invoca "weekly news" / "주간 뉴스" y
obtén un resumen con formato de periódico de todas las fuentes habilitadas, traducido automáticamente
al idioma de conversación del usuario por el LLM.
La mayoría de los servidores MCP académicos / de código / regulatorios son de una sola fuente. Este es
multifuente y consciente del dominio: un investigador que rastrea IA de imágenes médicas,
un ingeniero de ML que sigue artículos de ML, un analista de seguridad que observa CVEs y
repositorios en tendencia — todos configuran una vez vía python configure.py, luego
trends_briefing se convierte en el "periódico del lunes por la mañana" para su dominio.
Lo que lo hace útil:
Formato de periódico con sugerencia de traducción — el LLM traduce automáticamente el texto fuente (resúmenes de artículos, razones de retiradas, etc.) al idioma de tu conversación mientras preserva identificadores, URLs y valores métricos literalmente.
Round-robin por categoría para arXiv — cs.HC (~50 artículos/sem) no
se ve eclipsado por cs.LG (~1500/sem) cuando ambos se rastrean juntos.
Caché TTL + coalescencia de solicitudes concurrentes — las llamadas repetidas y los resúmenes paralelos no saturan las APIs upstream.
No se requieren tokens. Las siete fuentes funcionan de forma anónima; los tokens solo aumentan el límite de tasa por fuente.
Lanzador de Python seguro en sandbox. Evita el bloque env de claude_desktop_config.json
(que trunca valores con espacios en algunas compilaciones de macOS)
configurando variables de entorno en Python antes de pasarlas al servidor.
Related MCP server: mcp-ai-news-server
git clone https://github.com/salwks/mcp-techTrend.git
cd mcp-techTrend
python3 -m venv .venv
.venv/bin/pip install -r requirements.txtConéctate a Claude Desktop editando
~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"trends": {
"command": "/path/to/trends-mcp/.venv/bin/python",
"args": ["/path/to/trends-mcp/run.py"]
}
}
}⚠️
argsapunta arun.py(el lanzador), no atrends_mcp.py. El lanzador establece variables de entorno específicas del dominio antes de que se inicie el servidor.
Reinicia Claude Desktop. El servidor trends debería aparecer con 11 herramientas.
Una única fuente de verdad: run.py. Dos formas de editarlo:
configure.py (recomendado)python configure.py═══ trends-mcp 설정 ═══
[1] Active sources (7/7 enabled)
[2] arXiv categories (4 entries · 13 papers/wk)
[3] PubMed query
[4] API tokens (0/4 set)
[5] Show current config
[6] Save and restart
[7] Quit without savingAlterna fuentes con números, establece pesos de arXiv con set 1 7, aplica preajustes
con preset medical-imaging, guarda con [6]. La acción de guardar crea una copia de seguridad en
run.py.bak, escribe el nuevo bloque SETTINGS (basado en AST — nunca toca código que no sea de configuración),
y ejecuta pkill -f trends_mcp para que Claude Desktop reinicie
el servidor con la nueva configuración en la siguiente llamada.
Las etiquetas del menú TUI están en coreano; los comandos y preajustes están en inglés. La internacionalización (i18n) de la propia TUI está en la hoja de ruta de la v0.2.
Modos de disparo único:
python configure.py --show # print current config
python configure.py --restart # pkill stale MCP processesrun.pyTRENDS_ENABLED_SOURCES = "" # "" = all
TRENDS_ARXIV_CATEGORIES = "cs.LG:5,cs.CV:3,cs.CL:3,cs.AI:2"
TRENDS_DEFAULT_PUBMED_QUERY = "(deep learning OR AI) AND (medical OR clinical)"
# GITHUB_TOKEN = "ghp_..." # raises 60 → 5,000 req/h
# HF_TOKEN = "hf_..."
# NCBI_API_KEY = "..." # raises 3 → 10 req/s for PubMed
# OPENFDA_API_KEY = "..." # raises 240 → 120,000 req/dayReinicia Claude Desktop después de guardar (o pkill -f trends_mcp).
# AI/ML researcher (default)
TRENDS_ARXIV_CATEGORIES = "cs.LG:5,cs.CV:3,cs.CL:3,cs.AI:2"
# Medical imaging / clinical AI
TRENDS_ARXIV_CATEGORIES = "eess.IV:5,cs.CV:3,cs.HC:2,q-bio.QM:2"
# Robotics
TRENDS_ARXIV_CATEGORIES = "cs.RO:5,cs.AI:3,cs.LG:2,cs.CV:2"
# HCI / UX
TRENDS_ARXIV_CATEGORIES = "cs.HC:5,cs.CY:3,cs.AI:2,cs.SI:2"
# Security
TRENDS_ARXIV_CATEGORIES = "cs.CR:5,cs.LG:2,cs.NI:2"
# Computational biology
TRENDS_ARXIV_CATEGORIES = "q-bio.QM:4,q-bio.GN:3,q-bio.BM:3,stat.AP:2"Categorías comunes de arXiv (referencia completa: ARXIV_CATEGORIES.md):
Código | Campo | Artículos semanales (aprox) |
| Inteligencia Artificial | 500–800 |
| Aprendizaje Automático | 1,500–2,000 (el más grande) |
| Visión por Computador | 1,000–1,500 |
| PLN | 500–800 |
| HCI / UX | 50–100 |
| Robótica | 100–200 |
| Seguridad | ~200 |
| Procesamiento de Imagen/Video (imágenes médicas) | 100–200 |
| Biología cuantitativa | 50–100 |
TRENDS_ENABLED_SOURCES = "arxiv,github,huggingface,paperswithcode"
# → fda_510k, fda_recalls, pubmed tools won't appear in the tool list at allVacío / "*" / "all" = habilitar todo. Las fuentes deshabilitadas no registran
sus herramientas, por lo que la lista de herramientas de chat se reduce. trends_digest y
trends_briefing permanecen registrados y omiten las fuentes deshabilitadas correctamente.
Herramienta | Propósito |
| Artículos recientes en una categoría, por fecha de envío |
| Búsqueda por palabra clave / sintaxis de campo ( |
| Búsqueda en PubMed (términos MeSH, etiquetas de campo) — resúmenes vía efetch |
| HF Daily Papers, ordenado por votos de la comunidad |
| Explorar github.com/trending (scraping HTML) |
| API de búsqueda de GitHub; |
| Modelos / datasets / spaces de HF Hub |
| Autorizaciones recientes de la FDA 510(k) |
| Retiradas recientes de dispositivos médicos de la FDA (filtro de clase) |
| Resumen en lista de viñetas multifuente, dado un tema |
| Resumen de periódico multifuente; tema opcional |
Todas las herramientas de búsqueda aceptan days=N para filtrar por los últimos N días. trends_briefing
agrupa los resultados en secciones de 🎓 Investigación / 💻 Código y Modelos / 🏥 Regulatorio.
trends_digest vs trends_briefing
|
| |
Tema | requerido | opcional (modo "qué hay de nuevo") |
Rango de fuentes | subconjunto configurable (predeterminado 4) | todas las fuentes habilitadas |
Formato | resumen en lista de viñetas | formato de periódico agrupado |
Caso de uso | inmersión profunda en un tema | resumen semanal regular |
La caché TTL en memoria por proceso envuelve cada respuesta HTTP. Las solicitudes concurrentes
identes se fusionan mediante asyncio.Lock por clave — N llamadores paralelos disparan una solicitud upstream.
Grupo TTL | Duración | Herramientas |
Tendencias | 5 min |
|
Predeterminado | 10 min |
|
Estático | 1 hora |
|
Hasta 256 entradas; las más antiguas se eliminan cuando está lleno. No hay forma de deshabilitar — los TTL son lo suficientemente cortos como para que la obsolescencia esté limitada.
GitHub Trending es scraping HTML — no existe una API oficial. Los cambios de diseño
pueden romperlo. Sustituto de tendencias estable: github_search con
days=7 y sort=stars.
trendingScore de HF no está documentado. La superficie de la API puede cambiar.
HF Daily Papers cubre ~50 artículos seleccionados al día, no todo arXiv. Es un feed de "de qué se habló", no exhaustivo.
arXiv no tiene tendencias nativas — las aproximamos mediante feeds de envíos recientes equilibrados por categoría.
El campo classification de openFDA a veces devuelve None incluso en
retiradas clasificadas recientemente (retraso de datos upstream). El índice de búsqueda también tiene retraso.
v0.2: i18n para el menú TUI y los encabezados de sección del resumen
bioRxiv / medRxiv vía RSS
Semantic Scholar (grafo de citas)
Eventos adversos de openFDA (MAUDE)
Scraping de EUDAMED de la UE
PMDA (dispositivos médicos de Japón)
MFDS (dispositivos médicos de Corea)
Suite de pruebas basada en mocks para CI
Fetch recent arXiv papers in a category, sorted by submission date (newest first). days filters by published date.
Common categories: cs.AI (general AI), cs.LG (machine learning), cs.CV (computer vision), cs.CL (NLP), cs.HC (HCI / UX), cs.RO (robotics), cs.NE (neural networks), stat.ML (statistical ML), eess.IV (image/video processing — medical imaging lives here), eess.SP (signal processing), q-bio.QM (quantitative biology).
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | ||
| days | No | ||
| max_results | No | ||
| response_format | No | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds behavioral context by stating the sorting order ('newest first') and that 'days filters by published date', which goes beyond the annotations. There is no contradiction between the description and 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 concise: two sentences plus a helpful list of common categories. The first sentence clearly states the primary function, and the list adds value without superfluous text. Every sentence serves a purpose.
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?
Given the tool has 4 parameters, 1 required, and an output schema (present but not shown), the description covers the main use case but omits details on result format, pagination, or rate limits. The lack of parameter explanations for most parameters reduces completeness, but the overall scope is clear for a simple read-only tool.
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 description only explains the 'days' parameter, noting it filters by 'published' date. It provides common category examples but does not explain the meaning or constraints of 'category', 'max_results', or 'response_format'. With 0% schema description coverage, the description fails to compensate for the lack of parameter documentation in the schema, leaving three out of four parameters undocumented.
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's purpose: 'Fetch recent arXiv papers in a category, sorted by submission date (newest first).' This provides a specific verb ('fetch'), resource ('recent arXiv papers'), and scope ('in a category'), differentiating it from the sibling tool 'arxiv_search' which focuses on specific search queries.
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 usage for browsing recent papers by category, but lacks explicit guidance on when to use this tool versus alternatives like 'arxiv_search'. It does not specify any conditions or exclusions, and does not mention that for specific keyword queries the user should use 'arxiv_search' instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search arXiv. Plain keywords work (auto-prefixed all:); for advanced queries use arXiv field syntax: ti: (title), au: (author), abs: (abstract), cat: (category, e.g. cat:eess.IV). days cuts off results older than N days (published field). When days is set, results are sorted by submission date instead of relevance.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| days | No | ||
| max_results | No | ||
| sort_by | No | relevance | |
| response_format | No | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and idempotent. The description adds behavioral details: auto-prefixing `all:`, the `days` parameter cutting off older results and changing sort order to submission date. No contradictions.
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 two sentences, front-loaded with purpose, and efficiently uses a semicolon to separate basic and advanced usage. Every sentence adds value with no 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?
Given the tool's complexity and the presence of an output schema, the description covers key aspects: query syntax, days behavior, and sorting. It lacks details on pagination or error handling, but for most searches it is sufficient.
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?
With 0% schema coverage, the description compensates by explaining `query` (plain vs advanced syntax) and `days` (age cutoff and sort order). `max_results` and `response_format` are self-explanatory or covered by schema/enum, so the description adds sufficient meaning.
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 'Search arXiv' and provides specific details: plain keywords auto-prefix `all:`, advanced syntax for field-specific queries, and the `days` parameter. This distinguishes it from siblings like arxiv_recent.
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 explains when to use plain keywords vs advanced syntax and the effect of `days` on sorting. It does not explicitly state alternatives, but the context is sufficient for an agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent FDA 510(k) clearances via openFDA. Date filter is always applied. openFDA uses token-exact matching on string fields — for partial name matches use wildcards (e.g. device_name:mammo* not device_name:mammography).
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| days | No | ||
| max_results | No | ||
| response_format | No | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description discloses that a date filter is always applied and explains the token-exact matching behavior, which is critical for correct query construction. This adds valuable behavioral context.
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 two sentences long, immediately stating the purpose and then a critical usage detail. Every sentence provides value, and it is front-loaded with the tool's function.
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?
Given the existence of an output schema and the tool's simplicity, the description adequately covers the essential behavior (date filter, string matching). It does not need to detail return format, but could mention pagination or result limits for completeness.
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?
With 0% schema description coverage, the description partially compensates by explaining the 'query' parameter's wildcard usage and implying the 'days' parameter via the date filter. However, 'max_results' and 'response_format' are not mentioned, leaving gaps.
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 it provides recent FDA 510(k) clearances via openFDA, specifying the verb (list) and resource (clearances). While the name itself is informative, it does not explicitly distinguish from sibling fda_recalls_recent, but the content is unambiguous.
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 includes a crucial usage tip about token-exact matching and wildcard syntax for partial name searches. However, it does not provide guidance on when to prefer this tool over siblings or mention any prerequisites or context for using the date filter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent FDA medical device recalls via openFDA. Optionally filter by class (1=most serious, 3=least). Note: openFDA query syntax uses token-exact matching on string fields — for partial matches use wildcards (e.g. product_description:mammog*).
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| days | No | ||
| class_level | No | ||
| max_results | No | ||
| response_format | No | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context beyond annotations, such as that it queries openFDA and the specifics of token-exact matching with wildcard syntax. No contradictions with 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 two sentences, efficient and front-loaded. The first sentence states purpose and optional filter, the second provides a critical usage note. No wasted words.
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?
Given 5 parameters, no schema descriptions, and an output schema, the description covers only the general purpose and one filter. It omits details for query (free text), days, max_results, and response_format, making it incomplete for full usage.
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?
With 0% schema description coverage, the description only explains one parameter (class_level) and briefly mentions query syntax. The parameters query, days, max_results, and response_format are not described, leaving significant gaps.
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 it retrieves recent FDA medical device recalls via openFDA, with optional filtering by class. This distinguishes it from sibling tools like fda_510k_recent and arxiv_recent.
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 explains when to use the class filter and provides a note on openFDA query syntax with wildcards, but does not explicitly state when not to use the tool or compare it to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search GitHub repositories by keyword via the official Search API. USE THIS WHEN: user has a specific topic ('medical imaging 리포', 'mammography GitHub'). days filters by repository created_at (treats it as 'repos created in the last N days') — pair with sort=stars for a stable trending-substitute. USE github_trending INSTEAD WHEN: no specific topic, just browsing.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| language | No | ||
| days | No | ||
| sort | No | stars | |
| max_results | No | ||
| response_format | No | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, non-destructive, idempotent behavior. Description confirms it uses the official Search API and explains that 'days' filters by created_at. No contradictions, but lacks details on rate limits or pagination.
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?
Description is concise with three sentences, front-loads the purpose, and uses bullet-like structure for usage guidelines. No unnecessary words.
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?
Given the tool has 6 parameters and an output schema, the description covers when to use and key parameter behavior. Missing some parameter explanations, but overall sufficient for decision-making.
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 description must compensate. It adds meaning for 'days' (filters by created_at) and 'sort' (pair with stars), but does not explain 'query', 'language', 'max_results', or 'response_format'. Partially helpful but not comprehensive.
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?
Description clearly states 'Search GitHub repositories by keyword via the official Search API,' which is a specific verb and resource. It also differentiates from sibling github_trending by specifying when to use each.
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?
Explicitly states when to use this tool (user has specific topic) and when to use github_trending instead (no specific topic, just browsing). Also provides guidance on the 'days' parameter and pairing with 'sort=stars'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse github.com/trending — the public 'what's hot now' feed. USE THIS WHEN: user wants to browse trending repos with no specific topic in mind ('파이썬 트렌딩 보여줘', 'GitHub 핫한 거'). USE github_search INSTEAD WHEN: user has a specific topic/keyword. Note: this is HTML scraping (no official API), so layout changes can break it.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | ||
| since | No | daily | |
| max_results | No | ||
| response_format | No | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds critical behavioral context: the tool uses HTML scraping (no official API) and layout changes can break it. No contradiction with 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?
Three sentences, front-loaded with purpose, no wasted words. Every sentence earns its place: what, when, and a behavioral caveat.
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?
Given the tool's simplicity (read-only, optional parameters, output schema exists), the description covers purpose, usage, and a warning. It could mention parameter defaults or output format, but overall is fairly complete.
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% (no parameter descriptions in schema). The description does not explain any of the 4 parameters (language, since, max_results, response_format) and adds no meaning beyond the schema. Baseline is low due to high coverage gap.
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 browses github.com/trending, the public 'what's hot now' feed, and gives a specific use case (user wants to browse trending repos with no specific topic). It also distinguishes from the sibling github_search tool.
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 explicitly provides 'USE THIS WHEN' and 'USE github_search INSTEAD WHEN' conditions, giving clear guidance on when to use this tool versus an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse Hugging Face Hub. kind selects models / datasets / spaces (default models). sort: trending / downloads / likes / recent. days filters by lastModified — CAUTION: this catches old entries with recent edits, not just newly published ones. For 'truly new' discovery prefer sort='recent' + days=N.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | models | |
| sort | No | trending | |
| query | No | ||
| tag | No | ||
| days | No | ||
| max_results | No | ||
| response_format | No | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it's safe. The description adds valuable behavioral nuance: the days parameter filters by lastModified, not publication date, which could cause unexpected results. This goes beyond annotations by explaining a potential pitfall, though it doesn't detail all aspects like pagination or result structure.
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 extremely concise—three sentences with no redundancy. It front-loads the primary purpose, then provides parameter details, and ends with a caution and alternative. Every sentence earns its place, making it easy for an agent to parse quickly.
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 has an output schema (ResponseFormat enum) but the description does not mention return values or structure. Additionally, four parameters are left unexplained. For a 7-parameter tool with 0% schema coverage, the description should provide more context to be fully self-contained, though the core browsing functionality is adequately covered.
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 has 0% description coverage (no parameter descriptions), so the description must compensate. It explains kind, sort, and days with valid values and nuances, but ignores query, tag, max_results, and response_format. While parameter names are somewhat self-explanatory, the description should cover all seven to fully compensate for missing schema details.
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 'Browse Hugging Face Hub' as the purpose, specifying the resource (Hugging Face Hub) and the action (browse). It differentiates from sibling tools like github_trending by explicitly naming Hugging Face and detailing the kind, sort, and days parameters that define the tool's scope.
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 provides explicit guidance on when to use different parameters: kind defaults to models, sort offers trending/downloads/likes/recent, and days filters by lastModified with a caution about catching old entries. It even suggests an alternative approach for 'truly new' discovery using sort='recent' + days=N, which helps agents choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily curated AI papers feed (now backed by Hugging Face's daily_papers — Papers with Code API was sunset after the 2024 HF acquisition). Empty query returns the newest curated papers. Search is client-side filtering over the daily-papers stream.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| days | No | ||
| sort_by | No | upvotes | |
| max_results | No | ||
| response_format | No | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that results are daily curated, client-side filtered, and empty query returns newest. It does not contradict annotations and provides useful behavioral context beyond the 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 two sentences, front-loaded with purpose. Every sentence adds value: first sentence gives source and context, second explains behavior. No wasted words.
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?
Given an output schema exists, the description explains the data source and filtering mechanism. It could detail what 'days' means, but the tool is simple enough. Overall, it provides enough context for effective use.
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%, and the description does not explain most parameters explicitly. It only implies that 'query' is for client-side filtering and 'empty query' returns newest. Without parameter details, agents may misinterpret optional parameters like 'days' or 'sort_by'. This is insufficient for a 5-parameter tool.
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 it provides a daily curated feed of AI papers, specifies the data source (Hugging Face daily_papers), and explains the behavior (client-side filtering). It distinguishes from sibling trending tools like github_trending and huggingface_trending by focusing on AI papers.
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?
It explains when to use (to get newest curated papers) and that search is client-side filtering. It does not explicitly list alternatives or when not to use, but the context from siblings is sufficient. The mention of API sunset provides historical context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search PubMed for biomedical publications. Plain keywords work; for advanced queries use MeSH and field tags: mammography[MeSH], smith[Author], 2025[PDat]. Combine with AND/OR. days filters by publication date (PDat field).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| days | No | ||
| max_results | No | ||
| response_format | No | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds behavioral context about query syntax (MeSH, field tags) and the effect of 'days' on the PDat field, without contradicting annotations. It does not detail pagination or rate limits, but annotations suffice.
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?
Three sentences, front-loaded with the core purpose. Every sentence adds value: purpose, syntax guidance, and parameter explanation. No wasted words.
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?
An output schema exists, so return values are documented. The description covers the main use case and key parameters, but omits details on max_results and response_format. For a tool with 4 parameters and annotations, it is nearly complete.
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 must add meaning. It explains 'query' (plain vs advanced) and 'days' (filters by PDat), but does not document 'max_results' (default 20) or 'response_format' (markdown/json). This is a gap, though defaults are visible in 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 clearly states 'Search PubMed for biomedical publications', which is a specific verb and resource. It distinguishes from sibling tools by providing PubMed-specific query syntax, making the purpose unmistakable.
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 provides explicit guidance on when to use plain keywords vs advanced MeSH/field tags, and explains the 'days' parameter for date filtering. It does not explicitly state when not to use this tool, but the context of sibling tools (arXiv, FDA, etc.) implies this is for PubMed-specific searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Newspaper-style weekly briefing across all enabled sources. Topic is optional — without it, each source shows its 'what's new' feed. Use this when the user asks for '주간 뉴스' / '주간 트렌드' / 'weekly news' / 'briefing' style output.
PRESENTATION RULES — follow strictly:
PRESERVE STRUCTURE EXACTLY. The output is already organized into three groups (🎓 연구 동향 / 💻 코드 / 모델 / 🏥 규제 / 의료기기) and seven distinct source sections (arXiv, PubMed, Papers with Code, GitHub, Hugging Face, FDA 510(k), FDA Recalls). Do NOT merge sections (e.g. don't combine arXiv + PubMed into one 'papers' list). Do NOT reorder sections or items within a section. Do NOT change emoji or section headers.
TRANSLATE INLINE TEXT ONLY. Translate paper titles, abstracts, descriptions, and recall reasons into the user's current conversation language. Keep section headers, group titles, emoji, and metadata labels in their original form.
PRESERVE VERBATIM: proper nouns, author names, journal names, repository names (e.g. 'mattpocock/skills'), arXiv IDs, PMIDs, k_numbers, URLs, dates, and metric values (stars, downloads, etc.).
NO SUMMARIZATION at the briefing level. Render every item the tool returned. The user wants the full feed, not your synthesis.
ITEM-LEVEL DEPTH. For each paper, repo, model, or recall, preserve enough of the upstream abstract/description to convey what's new and why it matters — typically 2–4 sentences (around 150–300 chars of translated content per item). Do NOT collapse to a single headline-length sentence; the user wants to grasp each item without clicking through. Carry the problem → method → result/contribution structure when present in the source abstract.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| per_source_limit | No | ||
| topic | No | ||
| arxiv_categories | No | ||
| pubmed_query | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides extensive behavioral details beyond annotations, such as strict presentation rules (preserve structure, translate inline, no summarization, item-level depth). This helps the agent understand the expected output behavior and avoids annotation contradictions.
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 front-loaded with purpose and usage, but the presentation rules take up a lot of text. While important, they could be more concise without losing meaning. Overall, it's adequate but somewhat verbose.
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 description thoroughly covers output presentation and use cases, but lacks explanation of parameters and how they affect output. Since an output schema exists, return values are not needed, but parameter semantics are 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?
Schema description coverage is 0%, yet the description only vaguely mentions that 'Topic is optional'. It does not explain the meaning or constraints of 'days', 'per_source_limit', 'arxiv_categories', or 'pubmed_query', leaving the agent without parameter guidance.
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 'Newspaper-style weekly briefing across all enabled sources' and gives specific user query examples ('주간 뉴스', 'weekly news'), distinguishing it from sibling tools that operate on individual sources or return different formats.
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?
Explicitly says 'Use this when the user asks for...' and provides Korean and English triggers. Does not mention when not to use or alternatives, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-shot multi-source digest for a topic. Calls sources in parallel; partial failures don't break the report.
PRESENTATION RULES — follow strictly:
PRESERVE SECTION STRUCTURE. The output has separate per-source sections (📌 arXiv, 📌 PubMed, 📌 GitHub, etc.). Do NOT merge them.
TRANSLATE INLINE TEXT into the user's conversation language; keep section headers and emoji as-is.
PRESERVE VERBATIM: proper nouns, IDs (PMID, k_number, arXiv IDs), URLs, repository names, metric values.
Render every item — no summarization at the digest level.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| sources | No | ||
| per_source_limit | No | ||
| days | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: parallel calls, partial failure tolerance ('partial failures don't break the report'), and strict presentation rules for output format. Annotations already indicate readOnlyHint=true and destructiveHint=false, aligning with the description.
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 front-loaded with the main purpose and behavior in two sentences, followed by necessary presentation rules. The rules are detailed but essential for correct output handling. No excessive verbosity.
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?
Covers the core multi-source aggregation and failure resilience, but omits details on the 'sources' parameter (valid values, defaults), which is a gap given low schema coverage. Output schema exists but is not referenced in description; completeness is adequate for a read-only digest tool but not fully comprehensive.
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?
With 0% schema description coverage, the description must compensate but does not explain any parameters (topic, sources, per_source_limit, days). The parameter names and defaults are self-explanatory to some extent, but the description adds no additional meaning or constraints.
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 it is a 'one-shot multi-source digest for a topic', with parallel calls across sources. This distinguishes it from sibling single-source tools like arxiv_search and pubmed_search, and from other trends tools like trends_briefing which likely serve a different purpose.
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 use when a broad multi-source overview is needed but does not explicitly state when to use vs alternatives or when not to use. No exclusion criteria or context for switching from individual searches is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show current trends-mcp configuration: enabled sources, arXiv categories, PubMed default query, and which optional rate-limit tokens are set. Token VALUES are never returned (only whether they are configured). Use this to confirm state before or after a trends_set_* call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that token values are never returned (only whether configured), which is important behavioral context beyond annotations. No contradiction.
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?
Two sentences, no wasted words. Front-loaded with the main purpose. Every sentence adds value.
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?
Given zero parameters, comprehensive annotations, and an output schema (present), the description fully covers what the tool does, including what it does NOT return. Complete for a config retrieval tool.
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?
No parameters exist (input schema is empty). Baseline for 0 parameters is 4. Description adds no parameter info since there are none, which is appropriate.
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 it shows current configuration (enabled sources, arXiv categories, PubMed default query, token configuration status) and distinguishes itself from sibling `trends_set_*` tools. The verb 'show' and resource 'trends-mcp configuration' are specific.
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?
Explicitly says 'Use this to confirm state before or after a trends_set_* call', giving clear context for when to use this tool versus the set alternatives. No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the default arXiv categories used by trends_briefing. Pass a list of entries; each entry is 'code' (e.g. 'cs.HC') or 'code:weight' (e.g. 'cs.HC:5'). Weight = papers per briefing per category (default 3). Example: ['cs.LG:5', 'cs.CV:3', 'cs.CL:2']. See ARXIV_CATEGORIES.md for the full list of valid codes.
| Name | Required | Description | Default |
|---|---|---|---|
| categories | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false, consistent with a configuration setter. The description adds behavioral details: weight default of 3 if omitted, and the format of entries. It does not detail overwrite behavior (e.g., whether it replaces all previous categories), but the idempotent hint implies repeated calls yield the same result. Overall, it adds value beyond the 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?
Two concise sentences with an example. The purpose is front-loaded, and every sentence adds meaningful information. No wasted words.
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 simple configuration tool with one parameter, the description covers the input format, defaults, and where to find valid codes. Since an output schema exists, return values need not be explained. The description is sufficiently complete for correct use.
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 defines an array of strings with no description (0% coverage). The description thoroughly explains the parameter: each entry can be a code or code:weight, clarifies weight meaning, default value, and references valid codes. This compensates fully for the schema gap.
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 it sets default arXiv categories used by trends_briefing. The verb 'set' combined with resource 'arXiv categories' specifies the action and object. Among sibling tools, this uniquely handles arXiv category configuration, distinguishing it from general configuration tools like trends_set_enabled_sources.
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 indicates when to use (to configure arXiv categories for trends_briefing) and provides an example and reference to valid codes. However, it does not explicitly state when not to use or suggest alternatives, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set which sources are enabled. Pass a list like ['arxiv', 'github']. Valid: arxiv, github, huggingface, paperswithcode, pubmed, fda_510k, fda_recalls. Pass ['*'] or ['all'] to enable all. Disabled sources' tools won't appear in the tool list at all (requires restart to take effect).
| Name | Required | Description | Default |
|---|---|---|---|
| sources | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that disabling sources removes their tools from the list and requires restart. Annotations only indicate idempotence; description adds crucial behavioral context beyond 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?
Two sentences efficiently communicate purpose, format, valid inputs, and side effects. No waste, front-loaded with key information.
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?
Covers purpose, usage, input, and consequences completely for this simple configuration tool. Output schema exists but description still explains effect on tool list and restart requirement.
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 has 0% description coverage, but description fully compensates by listing all valid values, special tokens, and effect. Gives complete meaning to the 'sources' parameter.
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?
Clearly states the tool sets enabled sources, lists valid values, and explains the effect on tool visibility. Distinguishes from sibling source-specific tools by being a global configuration.
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?
Provides explicit syntax and valid values, including special tokens. Implicitly tells when to use (to configure sources) but does not mention when not to use or refer to alternative tools for individual source interactions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the default PubMed query used by trends_briefing when no topic is provided. Use PubMed syntax: MeSH terms, [Title/Abstract] tags, AND/OR/NOT. [Title/Abstract] tags keep matches precise. Example: '(deep learning) AND (radiology[Title/Abstract])'.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds context about query syntax but no additional behavioral traits beyond what annotations provide. No contradiction.
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?
Two sentences: first states purpose, second gives syntax details and example. No wasted words, front-loaded with key info.
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?
Given the simplicity (one parameter, output schema exists), the description is complete. It covers purpose, parameter usage, and provides an example, meeting all necessary context for an agent to use the tool correctly.
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 single parameter 'query' has no schema description (0% coverage), but the description fully compensates by explaining PubMed syntax, tags, and providing an example. This adds significant meaning 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 clearly states it sets the default PubMed query for trends_briefing, using a specific verb 'Set' and resource. It distinguishes from siblings like pubmed_search and trends_briefing by specifying its role as a configuration tool.
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 explains when to use the tool (to set default query for trends_briefing) and provides syntax guidance (MeSH terms, tags, operators). It does not explicitly state when not to use it or list alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set or clear an optional rate-limit booster token. trends-mcp ONLY needs read access — when creating these tokens use the MINIMAL scope:
github: NO scope at all (just authentication for rate limit). Do NOT use a token with 'repo' scope here.
hf: read access only.
ncbi / openfda: API keys (no scope concept). Pass empty string for value to remove a token. Provider must be one of: github, hf, ncbi, openfda.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | ||
| value | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the idempotentHint annotation, the description adds critical behavioral details: scope warnings (e.g., 'Do NOT use a token with repo scope here'), provider-specific access needs, and the effect of empty string. This exceeds what annotations provide.
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 well-structured and front-loaded with the core purpose. While every sentence adds value, a slight redundancy exists in the scope instructions. Overall, it is appropriately sized for the complexity.
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 description covers purpose, usage, provider enumeration, removal behavior, and scope warnings. Given that an output schema exists, return values need not be explained. The description is fully complete for correct tool invocation.
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?
With 0% schema description coverage, the description fully compensates by explaining valid providers ('github, hf, ncbi, openfda'), the meaning of value (set or clear via empty string), and provider-specific scope requirements. This adds significant meaning beyond the 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 clearly states the tool's purpose: 'Set or clear an optional rate-limit booster token.' It specifies the providers and distinguishes the tool from siblings (e.g., trends_get_config, trends_set_enabled_sources).
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 provides clear context for when to use the tool, including minimal scope requirements for each provider and how to remove a token. However, it does not explicitly state when not to use it or mention alternatives, though the tool is unique among siblings.
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.2.0trends_get_configtrends_set_arxiv_categoriestrends_set_enabled_sourcestrends_set_pubmed_querytrends_set_tokenv0.1.0arxiv_recentarxiv_searchfda_510k_recentfda_recalls_recentgithub_searchgithub_trendinghuggingface_trendingpaperswithcode_trendingpubmed_searchtrends_briefingtrends_digestScored across 16 tools
Each tool targets a distinct source or operation (e.g., arXiv search vs. recent, FDA 510k vs. recalls, GitHub search vs. trending). Even config tools are clearly separated. No ambiguity between tools.
All tools follow a consistent pattern: source_action (e.g., arxiv_recent, github_search) for data tools, and trends_verb for configuration tools. Lowercase with underscores throughout.
16 tools is well-scoped for a multi-source trend aggregation server. Each tool covers a specific need across multiple sources and configuration, without bloat.
The tool set covers all necessary operations for the domain: retrieval (recent, search, trending) per source, aggregation (briefing, digest), and full configuration (sources, categories, tokens). No obvious gaps.
MCP server for VC pitch-deck scoring, thesis-fit matching, and deal-flow management.
MCP server for Altmetric APIs - track research attention across news, policy, social media, and more
Personal knowledge base MCP server with semantic search, auto-categorization, metadata extraction
