Skip to main content
Glama
salwks

mcp-techTrend

trends_briefing

Read-only

Generate weekly newspaper-style briefings from academic, code, and regulatory sources. Optionally focus on a specific topic to get curated research, trending code, and FDA updates.

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
Behavior5/5

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.

Conciseness3/5

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.

Completeness3/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

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