Skip to main content
Glama

Gate News MCP

by io.github.gateio-dev

news_prediction_get_market_orderbook

Read-onlyIdempotent

[Read] Live current order book only (mode=current). depth 1-20 (default 20). polymarket: market_id=venue_market_id; needs opensearch.predictionMarketIndex for token lookup (else not_implemented); yes/no CLOB /book in parallel—partial if one side fails, tool error only if both fail. predict_fun: official numeric market_id (not polymarket ids); needs predictFunAPIKey—empty/missing config returns partial_not_configured (no HTTP); API/parse errors return partial (not internal); 404 resource_not_found. Rejects history/granularity/time/page_token. snapshot_time/book_levels/best_* may be null when partial. Event list/signal -> search_events / get_event_signal. Read-only public research data. No account access, no order placement or fund transfers. Not investment advice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoEmpty or current only (default current). history and other values rejected.
depthNoyes_bids/yes_asks top-N levels; default 20; allowed 1-20 inclusive; out of range invalid_param.
venueYesRequired. polymarket or predict_fun. polymarket needs predictionMarketIndex; predict_fun needs predictFunAPIKey (else partial_not_configured, not a tool error).
end_timeNoUnsupported; if set, request is rejected.
market_idYesRequired. polymarket: venue_market_id in dws_prediction_market_hf (token lookup). predict_fun: official numeric id (e.g. 356640), not polymarket venue_market_id.
page_tokenNoUnsupported; if set, request is rejected.
start_timeNoUnsupported; if set, request is rejected.
granularityNoUnsupported; if set, request is rejected.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYes
venueYes
partialYes
market_idYes
source_apiYes
book_levelsYesnullable
duration_msYes
snapshot_timeYesnullable
missing_sourcesYes
source_data_statusYes

TDQS

A4.4/5.0
Behavior5/5

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

Annotations cover read-only/idempotent/destructive hints, but the description adds substantial behavior: partial failure modes (one side of CLOB fails), configuration dependencies (opensearch.predictionMarketIndex, predictFunAPIKey), error codes (partial_not_configured, resource_not_found), null fields when partial, and rejection of unsupported params. 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.

Conciseness4/5

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

The description is long but every sentence carries operational information. It front-loads the core purpose and then methodically covers venue specifics, errors, and safety. No fluff, but the density might overwhelm some agents; still appropriately sized for the tool's complexity.

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?

Covers purpose, venue-specific prerequisites, error handling, rejected parameters, alternative tools, and safety disclaimers. With an output schema present, nothing an agent needs to invoke and interpret the tool correctly is missing.

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 coverage is 100% with each parameter already well-documented (mode defaults, depth range, venue requirements, market_id types). The description mostly reiterates these points (e.g., 'predict_fun needs predictFunAPIKey') rather than adding new parameter-level insight. It meets the baseline but doesn't elevate above it.

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 opens with '[Read] Live current order book only' — a specific verb, resource, and scope. It differentiates itself from event/signal tools by naming alternatives ('Event list/signal -> search_events / get_event_signal') and clarifies it is read-only. No ambiguity about what it does.

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?

It explicitly says when NOT to use it (history/granularity/time rejected) and points to alternatives for event list/signal. However, it doesn't name a specific tool for historical order book data, leaving a small gap for that use case. Overall 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.

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