Skip to main content
Glama
salwks

mcp-techTrend

trends_briefing

Read-only

Aggregates academic papers, code repositories, and medical device regulatory updates into a weekly briefing. Optionally filter by topic for targeted trend analysis.

Instructions

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:

  1. 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.

  2. 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.

  3. 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.).

  4. NO SUMMARIZATION at the briefing level. Render every item the tool returned. The user wants the full feed, not your synthesis.

  5. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysNo
per_source_limitNo
topicNo
arxiv_categoriesNo
pubmed_queryNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds substantial behavioral context: strict presentation rules (no merging sections, inline translation only, no summarization, item-level depth). This goes beyond what annotations provide, making the tool's behavior transparent.

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

Conciseness4/5

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

The description is front-loaded with purpose and usage, followed by structured presentation rules. While lengthy, the rules are essential for correct output formatting. It is well-organized and avoids unnecessary repetition.

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

Completeness2/5

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

Given the tool's complexity (5 parameters, many siblings) and the presence of an output schema, the description covers purpose and usage well but fails to document parameters. The output schema may describe the structure, but parameter semantics are missing, making the tool difficult to invoke correctly.

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

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters. It only mentions that topic is optional, but fails to explain days, per_source_limit, arxiv_categories, and pubmed_query. This is a significant gap, leaving the agent to guess parameter meanings.

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

Purpose5/5

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

The description clearly states it provides a 'newspaper-style weekly briefing across all enabled sources' with an optional topic. It gives specific user query examples ('주간 뉴스', 'weekly news') that trigger this tool. The presentation rules further solidify its purpose.

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

Usage Guidelines3/5

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

It explicitly says 'Use this when the user asks for ... briefing style output.' However, it does not mention when NOT to use it or point to alternative sibling tools (e.g., arxiv_recent for single-source queries). The guidance is clear but lacks exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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