mcp-techTrend is a multi-source technology trend aggregator that fetches academic papers, code repositories, and medical-device regulatory data from seven sources, delivering newspaper-style briefings.
π Research & Academic
arxiv_recent β Latest arXiv papers by category, sorted by submission date
arxiv_search β Search arXiv by keyword or advanced field syntax (ti:, au:, abs:, cat:)
pubmed_search β Search PubMed biomedical literature using MeSH terms and field tags
paperswithcode_trending β Hugging Face Daily Papers (curated AI papers) sorted by community upvotes
π» Code & Models
github_trending β Browse GitHub trending repositories
github_search β Search GitHub repositories by keyword with stars, date, and language filters
huggingface_trending β Browse Hugging Face models, datasets, or spaces by trending score, downloads, likes, or recency
π₯ Regulatory (FDA)
fda_510k_recent β Recent FDA 510(k) medical device clearances via openFDA
fda_recalls_recent β Recent FDA medical device recalls, with optional severity class filter
π° Aggregated Briefings
trends_digest β Multi-source bullet-list digest on a specific topic, fetched in parallel
trends_briefing β Full newspaper-style weekly briefing across all enabled sources, grouped into Research / Code & Models / Regulatory sections, with automatic translation to the user's language
βοΈ Configuration
trends_get_config β View current settings (enabled sources, arXiv categories, PubMed query, token status)
trends_set_enabled_sources β Enable or disable specific data sources
trends_set_arxiv_categories β Set arXiv categories with per-category weights
trends_set_pubmed_query β Set the default PubMed query for briefings
trends_set_token β Set or clear rate-limit booster tokens for GitHub, Hugging Face, NCBI, or openFDA
Additional notes: All sources work anonymously (tokens optional for higher rate limits). Requests are cached with TTL-based invalidation and concurrent-request coalescing to avoid hammering upstream APIs. Configuration can be done via chat commands, an interactive TUI, or by editing run.py.
Provides tools for searching and retrieving recent academic papers from arXiv across various categories.
Provides tools for browsing trending repositories and searching GitHub repositories with date filters.
Provides tools for accessing trending models, datasets, and spaces from the Hugging Face Hub.
Provides tools for searching PubMed and retrieving full abstracts of biomedical literature.
νκ΅μ΄ λ¬Έμ: 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.
Source | Tools | Notes |
arXiv |
| Per-category round-robin so small categories aren't drowned by big ones |
PubMed |
| Full abstracts via |
HF Daily Papers |
| Sorted by community upvotes (replaces sunset PwC API) |
GitHub |
| Trending page scrape + Search API with |
Hugging Face |
| Models / datasets / spaces, trending or recent |
openFDA 510(k) |
| Device clearances |
openFDA Recalls |
| Recall events with class filter |
(aggregators) |
| Multi-source parallel calls |
trends_briefing is the headline tool: invoke "weekly news" / "μ£Όκ° λ΄μ€" and
get a newspaper-formatted briefing across all enabled sources, automatically
translated into the user's conversation language by the LLM.
Most academic / code / regulatory MCP servers are single-source. This one is
multi-source and domain-aware: a researcher tracking medical-imaging AI,
an ML engineer following ML papers, a security analyst watching CVEs and
trending repos β all configure once via python configure.py, then
trends_briefing becomes the "Monday morning newspaper" for their domain.
What makes it useful:
Newspaper format with translation hint β the LLM auto-translates source text (paper abstracts, recall reasons, etc.) to your conversation language while preserving identifiers, URLs, and metric values verbatim.
Per-category round-robin for arXiv β cs.HC (~50 papers/wk) doesn't
get drowned by cs.LG (~1500/wk) when both are tracked together.
TTL cache + concurrent-request coalescing β repeat calls and parallel briefings don't hammer upstream APIs.
No required tokens. All seven sources work anonymously; tokens just raise the per-source rate limit ceiling.
Sandbox-safe Python launcher. Bypasses the claude_desktop_config.json
env block (which truncates whitespace-containing values on some macOS
builds) by setting environment variables in Python before handing off to
the server.
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.txtConnect to Claude Desktop by editing
~/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"]
}
}
}β οΈ
argspoints atrun.py(the launcher), nottrends_mcp.py. The launcher sets domain-specific env vars before the server starts.
Restart Claude Desktop. The trends server should appear with the tools
listed below (count depends on your enabled sources).
One source of truth: run.py. Two ways to edit it:
configure.py (recommended)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 savingToggle sources with numbers, set arXiv weights with set 1 7, apply presets
with preset medical-imaging, save with [6]. The save action backs up to
run.py.bak, writes the new SETTINGS block (AST-based β never touches
non-config code), and runs pkill -f trends_mcp so Claude Desktop respawns
the server with the new config on next call.
The TUI menu labels are in Korean; commands and presets are in English. i18n of the TUI itself is on the v0.2 roadmap.
Single-shot modes:
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/dayRestart Claude Desktop after saving (or pkill -f trends_mcp).
trends_set_* toolsSame SETTINGS block, edited via MCP tool calls. The chat path and configure.py
read & write the same run.py (single source of truth), so changes from either
side are visible to the other.
Just say it in chat:
"νΈλ λμμ PubMed 쿼리λ₯Ό cardiology μͺ½μΌλ‘ λ°κΏμ€" "githubμ arxivλ§ μΌλ¬" "GitHub ν ν° λ±λ‘ν κ²: ghp_..."
The host Claude picks the right trends_set_* tool and confirms what changed.
After any change, restart Claude Desktop (or run pkill -f trends_mcp in
a terminal) β the MCP server reads the SETTINGS block at spawn time.
Tool | Purpose |
| Show current sources, categories, query, and which tokens are set (values never returned) |
| Enable a subset; |
|
|
| PubMed syntax (MeSH, |
|
|
Tokens: trends-mcp only does read operations, so create tokens with minimal scope β for GitHub, no scope at all (just authentication for rate limit). Don't put a
repo-scoped PAT here; it'd be over-permission.
# 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"Common arXiv categories (full reference: ARXIV_CATEGORIES.md):
Code | Field | Weekly papers (approx) |
| Artificial Intelligence | 500β800 |
| Machine Learning | 1,500β2,000 (largest) |
| Computer Vision | 1,000β1,500 |
| NLP | 500β800 |
| HCI / UX | 50β100 |
| Robotics | 100β200 |
| Security | ~200 |
| Image/Video Processing (medical imaging) | 100β200 |
| Quantitative biology | 50β100 |
TRENDS_ENABLED_SOURCES = "arxiv,github,huggingface,paperswithcode"
# β fda_510k, fda_recalls, pubmed tools won't appear in the tool list at allEmpty / "*" / "all" = enable everything. Disabled sources don't register
their tools, so the chat tool list itself shrinks. trends_digest and
trends_briefing remain registered and skip disabled sources gracefully.
Tool | Purpose |
| Recent papers in one category, by submission date |
| Keyword / field-syntax search ( |
| PubMed search (MeSH terms, field tags) β abstracts via efetch |
| HF Daily Papers, sorted by community upvotes |
| Browse github.com/trending (HTML scrape) |
| GitHub Search API; |
| HF Hub models / datasets / spaces |
| Recent FDA 510(k) clearances |
| Recent FDA medical-device recalls (class filter) |
| Multi-source bullet-list digest, given a topic |
| Multi-source newspaper briefing; topic optional |
| Show current settings (token values never returned) |
| Toggle which sources are active |
| Set arXiv categories + per-category weights |
| Set the default PubMed query |
| Set / clear a rate-limit booster token |
All search tools accept days=N for recent-N-days filtering. trends_briefing
groups results into π Research / π» Code & Models / π₯ Regulatory sections.
The five trends_*_config / trends_set_* tools are configuration mirrors
of configure.py β see Configuration Β§ C.
trends_digest vs trends_briefing
|
| |
Topic | required | optional ("what's new" mode) |
Source range | configurable subset (default 4) | all enabled sources |
Format | bullet-list digest | grouped newspaper format |
Use case | topic deep-dive | regular weekly briefing |
Per-process in-memory TTL cache wraps every HTTP response. Concurrent
identical requests are coalesced via per-key asyncio.Lock β N parallel
callers fire one upstream request.
TTL group | Length | Tools |
Trending | 5 min |
|
Default | 10 min |
|
Static | 1 hour |
|
Up to 256 entries; oldest evicted when full. No way to disable β TTLs are short enough that staleness is bounded.
GitHub Trending is HTML scraping β no official API exists. Layout
changes can break it. Stable trending substitute: github_search with
days=7 and sort=stars.
HF trendingScore is undocumented. API surface may change.
HF Daily Papers covers ~50 curated papers/day, not all of arXiv. It's a "what was talked about" feed, not exhaustive.
arXiv has no native trending β we approximate via category-balanced recent-submissions feeds.
openFDA classification field sometimes returns None even on
recently classified recalls (upstream data lag). Search index lags too.
v0.2: i18n for the TUI menu and briefing section headers
bioRxiv / medRxiv via RSS
Semantic Scholar (citation graph)
openFDA Adverse Events (MAUDE)
EU EUDAMED scraping
PMDA (Japan medical devices)
MFDS (Korea medical devices)
Mock-based test suite for 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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for VC pitch-deck scoring, thesis-fit matching, and deal-flow management.
Dive into the latest and greatest from the tech world with our Hacker News MCP server.
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
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/salwks/mcp-techTrend'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
