Skip to main content
Glama

Gate News MCP

by io.github.gateio-dev

news_events_get_latest_events

Read-onlyIdempotent

[Read] Filtered event list or timeline; each row includes event_id and persisted impact_direction/impact_direction_reason. Optional direction filter. One event_id detail -> get_event_detail. Headline/news feed -> search_news. Read-only public research data. No account access, no order placement or fund transfers. Not investment advice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
coinNoOptional comma-separated tickers e.g. BTC,ETH for digest items; not the same as search_news tickers-only heat mode.
limitNoPage size; default 20, max 100.
cursorNoOptional pagination cursor.
end_timeNoAbsolute end (ISO8601 or Unix sec/ms). Mutually exclusive with time_range.
directionNoOptional filter on persisted impact_direction: positive / negative / neutral / mixed / unknown / all (default all, no filter). MCP does not re-judge direction.
event_typeNoOptional filter on structured digest event_type. Not search_news headline similarity/heat.
start_timeNoAbsolute start (ISO8601 or Unix sec/ms). Mutually exclusive with time_range; pair with end_time or let server fill the other bound.
time_rangeNoRelative window for event digest list: 1h / 24h / 7d. Mutually exclusive with start_time/end_time; omit all for last 24h or server default when time filter disabled. Not CPI/Fed macro series—use macro indicator tools.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
coinNo
countYes
itemsYes
limitYes
totalYes
end_timeNo
directionNo
event_typeNo
start_timeNo
time_rangeNo
duration_msYes

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds that data is public research, not investment advice, and that direction is persisted and not re-judged by MCP, which are valuable behavioral disclosures 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.

Conciseness4/5

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

The description is dense but each sentence adds value, from core purpose to alternatives and caveats. It is front-loaded with the primary function and well-structured, though slightly longer than strictly necessary.

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

Completeness5/5

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

Given the complexity of 8 optional parameters, an output schema, and 17 siblings, the description provides sufficient context for correct selection and invocation. It covers purpose, alternatives, behavioral constraints, and parameter nuances, leaving no critical gap.

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

Parameters4/5

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

Schema covers all parameters at 100%, so baseline is 3. The description adds disambiguation for 'coin' (different from search_news) and 'time_range' (not macro series), plus clarifies mutual exclusivity and defaults, enhancing understanding beyond the schema.

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 returns a filtered list of events with event_id and impact fields, and explicitly differentiates from get_event_detail (single event) and search_news (headline feed). The verb and resource are specific and unambiguous.

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

Usage Guidelines5/5

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

Providers explicit routing: 'One event_id detail -> get_event_detail' and 'Headline/news feed -> search_news', plus clarifies it is read-only and not for trading. This gives an agent clear when-to-use and when-not-to-use guidance.

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

All Gate News MCP toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct resource or action: event lists vs details, news index vs open web vs X vs multi-platform UGC, prediction event signals vs orderbooks vs rankings. Descriptions cross-reference alternatives, so an agent can reliably choose the right tool.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with domain prefixes (news_events, news_feed, news_prediction). Verbs are get, search, list, explain, and nouns clearly describe the resource. No mixed conventions or vague names.

Tool Count5/5

18 tools is well-scoped for the server's broad read-only purpose covering news, social sentiment, prediction markets, and market-move reports. Each tool covers a distinct function without redundancy or bloat.

Completeness5/5

The tool surface covers the full read-only lifecycle: searching and filtering events, retrieving details, aggregating social signals, searching various sources, and accessing prediction market data. No obvious gaps for the stated domain; all necessary operations are present.

Resources