Koreanische Dokumentation: 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.
Quelle | Tools | Hinweise |
arXiv |
| Round-Robin pro Kategorie, damit kleine Kategorien nicht von großen überlagert werden |
PubMed |
| Vollständige Abstracts via |
HF Daily Papers |
| Sortiert nach Community-Upvotes (ersetzt die eingestellte PwC-API) |
GitHub |
| Trending-Page-Scrape + Search API mit |
Hugging Face |
| Modelle / Datensätze / Spaces, trendig oder aktuell |
openFDA 510(k) |
| Zulassungen von Medizinprodukten |
openFDA Recalls |
| Rückrufereignisse mit Klassenfilter |
(Aggregatoren) |
| Parallele Aufrufe mehrerer Quellen |
trends_briefing ist das Haupt-Tool: Rufen Sie "weekly news" / "주간 뉴스" auf und
erhalten Sie ein im Zeitungsformat aufbereitetes Briefing über alle aktivierten Quellen,
das vom LLM automatisch in die Konversationssprache des Benutzers übersetzt wird.
Die meisten MCP-Server für akademische/Code-/regulatorische Daten sind auf eine einzige Quelle beschränkt. Dieser Server ist
multi-quellenfähig und domänenbewusst: Ein Forscher, der medizinische Bildgebungs-KI verfolgt, ein ML-Ingenieur, der ML-Paper liest, ein Sicherheitsanalyst, der CVEs und trendige Repos beobachtet — alle konfigurieren dies einmal über python configure.py, und dann wird trends_briefing zur "Montagmorgen-Zeitung" für ihre Domäne.
Was es nützlich macht:
Zeitungsformat mit Übersetzungshinweis — das LLM übersetzt Quelltexte automatisch (Paper-Abstracts, Rückrufgründe usw.) in Ihre Konversationssprache, während Identifikatoren, URLs und metrische Werte wortgetreu beibehalten werden.
Round-Robin pro Kategorie für arXiv — cs.HC (~50 Paper/Woche) wird nicht von cs.LG (~1500/Woche) überlagert, wenn beide zusammen verfolgt werden.
TTL-Cache + Zusammenführung gleichzeitiger Anfragen — wiederholte Aufrufe und parallele Briefings belasten die Upstream-APIs nicht.
Keine erforderlichen Token. Alle sieben Quellen funktionieren anonym; Token erhöhen lediglich das Ratenlimit pro Quelle.
Sandbox-sicherer Python-Launcher. Umgeht den env-Block in der claude_desktop_config.json (der bei einigen macOS-Builds Werte mit Leerzeichen abschneidet), indem Umgebungsvariablen in Python gesetzt werden, bevor sie an den Server übergeben werden.
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.txtVerbinden Sie sich mit Claude Desktop, indem Sie ~/Library/Application Support/Claude/claude_desktop_config.json bearbeiten:
{
"mcpServers": {
"trends": {
"command": "/path/to/trends-mcp/.venv/bin/python",
"args": ["/path/to/trends-mcp/run.py"]
}
}
}⚠️
argsverweist aufrun.py(den Launcher), nicht auftrends_mcp.py. Der Launcher setzt domänenspezifische Umgebungsvariablen, bevor der Server startet.
Starten Sie Claude Desktop neu. Der trends-Server sollte mit 11 Tools erscheinen.
Eine Quelle der Wahrheit: run.py. Zwei Möglichkeiten, sie zu bearbeiten:
configure.py (empfohlen)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 savingSchalten Sie Quellen mit Nummern um, setzen Sie arXiv-Gewichtungen mit set 1 7, wenden Sie Presets mit preset medical-imaging an, speichern Sie mit [6]. Die Speicheraktion erstellt ein Backup in run.py.bak, schreibt den neuen SETTINGS-Block (AST-basiert — berührt niemals Nicht-Konfigurationscode) und führt pkill -f trends_mcp aus, damit Claude Desktop den Server beim nächsten Aufruf mit der neuen Konfiguration neu startet.
Die TUI-Menübeschriftungen sind auf Koreanisch; Befehle und Presets sind auf Englisch. Die Internationalisierung (i18n) der TUI selbst steht auf der Roadmap für v0.2.
Single-Shot-Modi:
python configure.py --show # print current config
python configure.py --restart # pkill stale MCP processesrun.py SETTINGS-BlockTRENDS_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/dayStarten Sie Claude Desktop nach dem Speichern neu (oder 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"Allgemeine arXiv-Kategorien (vollständige Referenz: ARXIV_CATEGORIES.md):
Code | Fachbereich | Wöchentliche Paper (ca.) |
| Künstliche Intelligenz | 500–800 |
| Maschinelles Lernen | 1.500–2.000 (größte) |
| Computer Vision | 1.000–1.500 |
| NLP | 500–800 |
| HCI / UX | 50–100 |
| Robotik | 100–200 |
| Sicherheit | ~200 |
| Bild-/Videoverarbeitung (medizinische Bildgebung) | 100–200 |
| Quantitative Biologie | 50–100 |
TRENDS_ENABLED_SOURCES = "arxiv,github,huggingface,paperswithcode"
# → fda_510k, fda_recalls, pubmed tools won't appear in the tool list at allLeer / "*" / "all" = alles aktivieren. Deaktivierte Quellen registrieren ihre Tools nicht, sodass die Liste der Chat-Tools selbst schrumpft. trends_digest und trends_briefing bleiben registriert und überspringen deaktivierte Quellen elegant.
Tool | Zweck |
| Aktuelle Paper in einer Kategorie, nach Einreichungsdatum |
| Stichwort- / Feldsyntax-Suche ( |
| PubMed-Suche (MeSH-Begriffe, Feld-Tags) — Abstracts via efetch |
| HF Daily Papers, sortiert nach Community-Upvotes |
| Durchsuchen von github.com/trending (HTML-Scrape) |
| GitHub Search API; |
| HF Hub Modelle / Datensätze / Spaces |
| Aktuelle FDA 510(k)-Zulassungen |
| Aktuelle Rückrufe von Medizinprodukten der FDA (Klassenfilter) |
| Zusammenfassung als Aufzählung aus mehreren Quellen zu einem Thema |
| Zeitungs-Briefing aus mehreren Quellen; Thema optional |
Alle Such-Tools akzeptieren days=N für die Filterung der letzten N Tage. trends_briefing gruppiert Ergebnisse in die Abschnitte 🎓 Forschung / 💻 Code & Modelle / 🏥 Regulatorisches.
trends_digest vs trends_briefing
|
| |
Thema | erforderlich | optional ("Was gibt es Neues"-Modus) |
Quellenbereich | konfigurierbare Teilmenge (Standard 4) | alle aktivierten Quellen |
Format | Aufzählungs-Zusammenfassung | gruppiertes Zeitungsformat |
Anwendungsfall | Deep-Dive zu einem Thema | regelmäßiges wöchentliches Briefing |
Ein prozessinterner In-Memory-TTL-Cache umschließt jede HTTP-Antwort. Gleichzeitige identische Anfragen werden über ein asyncio.Lock pro Schlüssel zusammengeführt — N parallele Aufrufer lösen eine Upstream-Anfrage aus.
TTL-Gruppe | Dauer | Tools |
Trending | 5 Min |
|
Standard | 10 Min |
|
Statisch | 1 Stunde |
|
Bis zu 256 Einträge; die ältesten werden bei Vollbelegung entfernt. Keine Deaktivierung möglich — die TTLs sind kurz genug, dass die Veralterung begrenzt ist.
GitHub Trending ist HTML-Scraping — es gibt keine offizielle API. Layout-Änderungen können es beschädigen. Stabiler Trending-Ersatz: github_search mit days=7 und sort=stars.
HF trendingScore ist nicht dokumentiert. Die API-Oberfläche kann sich ändern.
HF Daily Papers deckt ca. 50 kuratierte Paper/Tag ab, nicht das gesamte arXiv. Es ist ein "Worüber wurde gesprochen"-Feed, nicht erschöpfend.
arXiv hat kein natives Trending — wir approximieren dies über kategorien-ausbalancierte Feeds aktueller Einreichungen.
openFDA classification-Feld gibt manchmal None zurück, selbst bei kürzlich klassifizierten Rückrufen (Upstream-Datenverzögerung). Der Suchindex hinkt ebenfalls hinterher.
v0.2: i18n für das TUI-Menü und die Überschriften der Briefing-Abschnitte
bioRxiv / medRxiv via RSS
Semantic Scholar (Zitationsgraph)
openFDA Adverse Events (MAUDE)
EU EUDAMED Scraping
PMDA (Japanische Medizinprodukte)
MFDS (Koreanische Medizinprodukte)
Mock-basierte Test-Suite für 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
