Skip to main content
Glama
poqopo

crypto_news_research_mcp

by poqopo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Crypto News Research Agent

기사 본문을 읽고 문단별 근거·해석 초안·반대 설명·확인할 지표를 다른 에이전트에 전달하는 독립 실행형 MCP 서버입니다.

등록용 이름: crypto_news_research_mcp. 라이선스: MIT.

시작하기

Python 3.11 이상과 uv가 필요합니다.

git clone https://github.com/poqopo/crypto-news-research.git
cd crypto-news-research
uv sync --python 3.12
uv run python agent.py

서버는 stdio MCP를 사용합니다. stdout은 프로토콜 전용이므로 터미널에서 바로 실행하면 입력을 기다립니다.

MCP 클라이언트 설정 예:

{
  "mcpServers": {
    "crypto_news_research": {
      "command": "uv",
      "args": ["--directory", "/ABSOLUTE/PATH/crypto-news-research", "run", "python", "agent.py"]
    }
  }
}

Related MCP server: cryptopolitan-mcp

역할과 도구

Tool

역할

fetch_today_crypto_news

Asia/Seoul 날짜 기준으로 CoinDesk·Cointelegraph RSS 뉴스 수집

collect_article_evidence

공개 기사 HTML/JSON-LD에서 본문을 읽고 원문 URL·문단 ID 보존

summarize_crypto_news

제목·RSS 발췌·출처·관련 코인 정리

analyze_crypto_insights

본문 관측·해석 초안·반대 설명·확인 지표를 근거 문단과 연결

워크플로: fetch_today_crypto_news → collect_article_evidence → summarize_crypto_news → analyze_crypto_insights.

처음 도구 호출 예:

{"mode": "demo"}

실시간 모드는 mode=live(기본)이며 선택적으로 date=YYYY-MM-DD를 지정할 수 있습니다. 로그인·페이월·JavaScript 실행으로 제한을 우회하지 않습니다. 읽히지 않는 본문은 상태로 남기고 본문 기반 인사이트를 생성하지 않습니다.

데모는 2026-09-19로 고정된 가상 뉴스 4개와 각 3개 문단의 가상 본문입니다. 실제 뉴스가 아닙니다.

인사이트는 주제별 규칙 기반 초안입니다. LLM 추론이나 독립적 사실 검증은 수행하지 않습니다. 추가 분석을 원하는 MCP 호스트는 본문·프롬프트·근거를 사용할 수 있습니다.

Contents

  • AGENTS.md: 리서치 행동 규칙

  • skills/news_review/SKILL.md: 근거 검토 스킬

  • prompts/daily_news.md: 일일 리서치 프롬프트

  • docs/output_contract.md: 다음 에이전트에 전달할 JSON 계약

  • data/sources.json: 발행사 RSS 목록

  • data/demo_*.json: 가상 데모 데이터

MCP Prompt: crypto_news_brief(date). MCP Resource: news://sources.

다음 에이전트에 전달하기

analyze_crypto_insights 결과를 Crypto Market HTML Agent의 build_crypto_market_html에 news_digest로 전달합니다. 뉴스 에이전트는 HTML 디자인이나 시세 수집을 하지 않습니다.

테스트

uv run python -m unittest discover -s tests -v

실제 stdio MCP 서버를 실행하고 가상 본문·인사이트·출처 문단의 연결을 확인합니다.

Available Tools

4 tools
analyze_crypto_insightsB

Build paragraph-grounded insight drafts separating reported observations, interpretations, counterpoints, and watch metrics. Uses explicit topic rules, not an LLM.

ParametersJSON Schema
NameRequiredDescriptionDefault
news_digestYes
enriched_newsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3/5.0
Behavior3/5

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

With no annotations, the description must carry the behavioral disclosure burden. It does disclose that the tool builds paragraph-grounded drafts, separates multiple analysis categories, and uses rule-based logic rather than an LLM. However, it does not mention error behavior, input quality expectations, or side effects, so coverage is partial.

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

Conciseness5/5

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

The description is two sentences with no filler. The main action is front-loaded, and the second sentence adds a valuable behavioral distinction between rule-based behavior and LLM-based alternatives.

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?

Despite having an output schema, the tool takes two undocumented nested objects and has no annotations. The description gives high-level intent but omits input structure, parameter interplay, and any call-level requirements needed for correct invocation.

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 does not explain what news_digest or enriched_news should contain or how they relate. The parameter names are mildly suggestive, but not sufficient to define required structure or usage, especially since both are open, nested objects.

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

Purpose4/5

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

The description states a specific verb (Build) and resource (paragraph-grounded insight drafts), and enumerates the output categories: reported observations, interpretations, counterpoints, and watch metrics. This clearly differentiates the tool from the sibling fetch, summarize, and evidence-collection tools even though siblings aren't named.

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

Usage Guidelines2/5

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

No explicit guidance is given about when to choose analyze_crypto_insights over fetch_today_crypto_news, summarize_crypto_news, or collect_article_evidence. The phrase 'Uses explicit topic rules, not an LLM' hints at a deterministic use case, but there are no conditions, prerequisites, or exclusions stated.

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

collect_article_evidenceC

Read public article bodies into source-linked paragraph evidence; keep failures explicit and demo bodies separate.

ParametersJSON Schema
NameRequiredDescriptionDefault
newsYes
max_articlesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.7/5.0
Behavior3/5

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

With no annotations, the description must carry behavioral disclosure. It does add some behavioral expectations: it reads public bodies, keeps failures explicit, and separates demo bodies. However, it omits network side effects, what 'demo bodies' means, and how failures are represented.

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 one concise sentence with the primary action front-loadedcars and no wasted words. The second clause is cryptic but still contributes behavioral caveats.

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?

An output schema exists, but the description still leaves key invocation details ambiguous: what shape 'news' must take, how max_articles applies, and why demo bodies must be kept separate. An agent would likely need to inspect sibling tool outputs to call this correctly.

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

Parameters1/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 compensate. It does not explain the required 'news' object shape or that max_articles limits how many article bodies are processed. The description adds little beyond what the parameter names already imply.

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

Purpose4/5

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

The description states a concrete operation ('Read public article bodies into source-linked paragraph evidence') and distinguishes this from sibling tools that fetch, summarize, or analyze crypto news. It is somewhat jargon-heavy, but the core purpose is identifiable.

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

Usage Guidelines2/5

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

There is no explicit guidance on when to use this tool versus fetch_today_crypto_news, summarize_crypto_news, or analyze_crypto_insights. The phrase about failures and demo bodies reads like behavior notes, not usage direction.

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

fetch_today_crypto_newsA

Collect crypto news for a YYYY-MM-DD date in Asia/Seoul; live RSS or explicit demo fixtures.

ParametersJSON Schema
NameRequiredDescriptionDefault
dateNo
modeNolive
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure. It usefully reveals that data comes from a live RSS feed or explicit demo fixtures, and it clarifies the timezone. However, it does not mention behavior for a null date, whether the operation is read-only, limits/pagination, or failure modes.

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

Conciseness5/5

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

The description is a single dense sentence with no filler. It front-loads the core action and date scope, then adds mode detail compactly. Every phrase adds information.

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 tool is relatively simple and an output schema exists, so return format is not the main gap. Still, with no annotations, the description should clarify what a null date means (presumably 'today'), how limit behaves, and what demo mode returns. The current description is viable but leaves those invocation-relevant details to inference.

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

Parameters3/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 compensate. It provides useful semantics for date (YYYY-MM-DD, Asia/Seoul) and mode (live RSS vs demo fixtures), mapping onto two parameters. The limit parameter and the meaning of the default null date are left undocumented, so compensation is only partial.

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 states a clear verb and resource: collect crypto news for a specified date. It also adds the important Asia/Seoul timezone qualifier, making the tool's behavior unambiguous. The contrast with sibling names (summarize, evidence, insights) makes it easy to distinguish this as the raw news-fetching step.

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

Usage Guidelines2/5

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

The description points out the live vs. demo mode, but it gives no guidance on when to choose this tool over siblings such as summarize_crypto_news or analyze_crypto_insights. An agent must infer from context that this is the first-stage fetcher rather than being told when to prefer it or when not to use it.

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

summarize_crypto_newsB

Create an extractive news digest with short feed excerpts, source links, and detected coin mentions.

ParametersJSON Schema
NameRequiredDescriptionDefault
newsYes
max_itemsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations, the description carries the behavioral burden. It usefully states that the digest is 'extractive' and enumerates output components, but it does not clarify side effects, input constraints, or behavior around malformed/empty news data.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with no filler. Every element—extractive, short feed excerpts, source links, coin mentions—earns its place and quickly communicates the core deliverable.

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?

Despite having an output schema, the description omits the input contract for the 'news' object and the meaning of 'max_items'. Combined with the lack of usage guidance and parameter semantics, the description is not sufficient for correct invocation.

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

Parameters1/5

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 what the 'news' object should contain or how 'max_items' influences the digest. The agent is left without the parameter-level details needed to construct a valid call.

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 the verb 'Create' with the specific resource 'an extractive news digest', and details what the digest contains: feed excerpts, source links, and detected coin mentions. This makes it distinguishable from sibling tools like fetch_today_crypto_news and analyze_crypto_insights.

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

Usage Guidelines2/5

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

The description gives no guidance on when to use this tool versus the siblings. It does not mention alternatives, exclusions, or prerequisites such as needing fetched/stored news first, so an agent must infer usage context from the tool name alone.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.1.0
    • First observedanalyze_crypto_insights
    • First observedcollect_article_evidence
    • First observedfetch_today_crypto_news
    • First observedsummarize_crypto_news
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose in the news research pipeline: fetching raw news, creating an extractive summary, collecting article-body evidence, and building insight drafts. The descriptions reinforce these boundaries with specific outputs and methods, leaving little room for misselection.

Naming Consistency5/5

All tool names follow a uniform verb_noun snake_case pattern (fetch_today_crypto_news, summarize_crypto_news, collect_article_evidence, analyze_crypto_insights). The verbs and objects are semantically aligned with each tool's function, making the naming predictable and readable.

Tool Count5/5

With four tools, the server is well-scoped for a focused crypto news research workflow. Each tool represents a necessary step in the pipeline without redundancy, fitting comfortably within the ideal 3-15 tool range.

Completeness4/5

The tool set forms a coherent pipeline from fetching news to generating insight drafts, covering all core research steps. A minor gap is the absence of a dedicated search or filter tool, but agents can work around this by fetching specific dates, so no major dead ends exist.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • cryptopolitan-mcp

    4dmrkey
    A
    license
    B
    quality
    F
    maintenance
    Real-time cryptocurrency news, analysis, and price predictions for AI agents. 5 tools to search 50,000+ articles across 12 categories, filter by 120+ asset tickers, and access content with built-in attribution. Free with attribution. SSE and Streamable HTTP transport.
    4
    MIT

  • AI News MCP

    ArgusOnline01
    F
    license
    Not graded
    quality
    D
    maintenance
    Local MCP server that ingests and normalizes recent AI, tech, and research news from multiple sources, exposing tools for media agents to query and retrieve article content on demand.
    -