日本語ドキュメント: README.md
学術・コード・医療機器規制のトレンドデータを7つのソースから収集し、ドメインごとの調整機能を備えた新聞形式のブリーフィングを作成する単一のMCPサーバーです。
ソース | ツール | 備考 |
arXiv |
| 小規模カテゴリが大規模カテゴリに埋もれないようカテゴリごとのラウンドロビンを実施 |
PubMed |
|
|
HF Daily Papers |
| コミュニティの投票数でソート（PwC APIの終了に伴う代替） |
GitHub |
| トレンドページのスクレイピング + |
Hugging Face |
| モデル / データセット / スペース、トレンドまたは最新 |
openFDA 510(k) |
| 医療機器の承認情報 |
openFDA Recalls |
| クラスフィルター付きのリコールイベント |
(アグリゲーター) |
| 複数ソースの並列呼び出し |
trends_briefingは主要ツールです。「weekly news」や「週刊ニュース」と呼びかけると、有効な全ソースから新聞形式のブリーフィングを取得し、LLMがユーザーの会話言語に自動翻訳します。
ほとんどの学術・コード・規制関連のMCPサーバーは単一ソースです。本サーバーは複数ソースに対応し、ドメインを認識します。医療画像AIを追跡する研究者、ML論文を追うMLエンジニア、CVEやトレンドリポジトリを監視するセキュリティアナリストなど、全員がpython configure.pyで一度設定すれば、trends_briefingが彼らのドメインにとっての「月曜朝の新聞」となります。
便利な点:
翻訳ヒント付きの新聞形式 — LLMがソーステキスト（論文アブストラクト、リコール理由など）を会話言語に自動翻訳しつつ、識別子、URL、指標値はそのまま保持します。
arXivのカテゴリ別ラウンドロビン — cs.HC（週約50本）がcs.LG（週約1500本）に埋もれることなく、両方を同時に追跡できます。
TTLキャッシュ + 並列リクエストの統合 — 繰り返し呼び出しや並列ブリーフィングがアップストリームAPIに負荷をかけません。
トークン不要 — 7つのソースすべてが匿名で動作します。トークンはソースごとのレート制限の上限を引き上げるためにのみ使用します。
サンドボックスセーフなPythonランチャー — claude_desktop_config.jsonのenvブロック（macOSの一部ビルドで空白を含む値を切り詰める問題）を回避し、サーバーに渡す前にPythonで環境変数を設定します。
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.txt~/Library/Application Support/Claude/claude_desktop_config.jsonを編集してClaude Desktopに接続します：
{
"mcpServers": {
"trends": {
"command": "/path/to/trends-mcp/.venv/bin/python",
"args": ["/path/to/trends-mcp/run.py"]
}
}
}⚠️
argsはtrends_mcp.pyではなく、run.py（ランチャー）を指すようにしてください。 ランチャーはサーバー起動前にドメイン固有の環境変数を設定します。
Claude Desktopを再起動します。trendsサーバーが11個のツールと共に表示されるはずです。
唯一の真実のソース: run.py。編集方法は2つあります：
configure.py（推奨）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 saving数字でソースを切り替え、set 1 7でarXivの重みを設定し、preset medical-imagingでプリセットを適用し、[6]で保存します。保存アクションはrun.py.bakにバックアップを作成し、新しいSETTINGSブロックを書き込み（ASTベースのため非設定コードには触れません）、pkill -f trends_mcpを実行して、次回の呼び出し時にClaude Desktopが新しい設定でサーバーを再起動するようにします。
TUIメニューのラベルは韓国語ですが、コマンドとプリセットは英語です。 TUI自体の国際化（i18n）はv0.2のロードマップに含まれています。
シングルショットモード：
python configure.py --show # print current config
python configure.py --restart # pkill stale MCP processesrun.pyのSETTINGSブロックTRENDS_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/day保存後、Claude Desktopを再起動してください（または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"一般的なarXivカテゴリ（完全なリファレンス: ARXIV_CATEGORIES.md）：
コード | 分野 | 週刊論文数（概算） |
| 人工知能 | 500–800 |
| 機械学習 | 1,500–2,000 (最大) |
| コンピュータビジョン | 1,000–1,500 |
| 自然言語処理 | 500–800 |
| HCI / UX | 50–100 |
| ロボット工学 | 100–200 |
| セキュリティ | ~200 |
| 画像/映像処理（医療画像） | 100–200 |
| 定量的生物学 | 50–100 |
TRENDS_ENABLED_SOURCES = "arxiv,github,huggingface,paperswithcode"
# → fda_510k, fda_recalls, pubmed tools won't appear in the tool list at all空 / "*" / "all" = すべて有効。無効なソースはツールを登録しないため、チャットのツールリスト自体が短縮されます。trends_digestとtrends_briefingは登録されたまま、無効なソースを適切にスキップします。
ツール | 目的 |
| 投稿日順の特定カテゴリの最新論文 |
| キーワード / フィールド構文検索 ( |
| PubMed検索（MeSH用語、フィールドタグ） — efetch経由のアブストラクト |
| コミュニティの投票数でソートされたHF Daily Papers |
| github.com/trendingの閲覧（HTMLスクレイピング） |
| GitHub検索API; |
| HF Hubのモデル / データセット / スペース |
| 最近のFDA 510(k)承認情報 |
| 最近のFDA医療機器リコール（クラスフィルター） |
| トピックを指定した複数ソースの箇条書きダイジェスト |
| 複数ソースの新聞形式ブリーフィング（トピックは任意） |
すべての検索ツールは、直近N日間のフィルタリングのためにdays=Nを受け付けます。trends_briefingは結果を 🎓研究 / 💻コード＆モデル / 🏥規制 セクションにグループ化します。
trends_digest vs trends_briefing
|
| |
トピック | 必須 | 任意（「最新情報」モード） |
ソース範囲 | 設定可能なサブセット（デフォルト4） | 有効な全ソース |
形式 | 箇条書きダイジェスト | グループ化された新聞形式 |
ユースケース | トピックの深掘り | 定期的な週刊ブリーフィング |
プロセスごとのメモリ内TTLキャッシュがすべてのHTTPレスポンスをラップします。同一の同時リクエストはasyncio.Lock経由で統合され、N個の並列呼び出しが1つのアップストリームリクエストを発行します。
TTLグループ | 期間 | ツール |
トレンド | 5分 |
|
デフォルト | 10分 |
|
静的 | 1時間 |
|
最大256エントリまで保持し、満杯になると古いものから削除されます。無効化はできません。TTLは短いため、陳腐化は限定的です。
GitHub Trending はHTMLスクレイピングであり、公式APIは存在しません。レイアウト変更により壊れる可能性があります。安定した代替手段: days=7とsort=starsを指定したgithub_search。
HF trendingScore は非公開です。API仕様が変更される可能性があります。
HF Daily Papers は厳選された1日約50本の論文をカバーしており、arXivのすべてではありません。「話題になったもの」のフィードであり、網羅的ではありません。
arXiv にはネイティブなトレンド機能がないため、カテゴリバランスを考慮した最新投稿フィードで近似しています。
openFDA classification フィールド は、最近分類されたリコールであってもNoneを返すことがあります（アップストリームデータの遅延）。検索インデックスも遅延します。
v0.2: TUIメニューとブリーフィングセクション見出しの国際化（i18n）
RSS経由のbioRxiv / medRxiv対応
Semantic Scholar（引用グラフ）
openFDA有害事象（MAUDE）
EU EUDAMEDスクレイピング
PMDA（日本の医療機器）
MFDS（韓国の医療機器）
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
