Gate News MCP
Server Details
Gate news MCP for crypto news, structured events, announcements, and social sentiment.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- gate/gate-mcp
- GitHub Stars
- 27
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 14 of 14 tools scored. Lowest: 3.8/5.
Each tool has a clearly distinct purpose grouped by domain (events, feeds, predictions). Even multiple search tools are differentiated by source (news, social media, UGC, web), so agents can easily select the correct one.
All tool names follow a consistent verb_noun pattern with underscores, such as get_latest_events, search_news, or search_ugc. The naming convention is uniform and predictable across the entire set.
With 14 tools, the count fits the well-scoped range. The tools cover news events, news feeds, and prediction markets without being excessive or too sparse for the server's purpose.
The server covers reading operations comprehensively: event lists, details, feeds from multiple sources, and prediction data including signals, order books, and rankings. No obvious gaps for its read-only domain.
Available Tools
14 toolsnews_events_explain_market_moveARead-onlyIdempotentInspect
[Read] Explain what drove a crypto asset's price move in a given time window. Returns a concise summary (from real-time Tavily search), the latest high-priority real-time events, and supporting internal event pool items, plus data-completeness status. This tool is a data aggregator; the downstream agent performs the final attribution reasoning.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes | Target coin, e.g. BTC, ETH. Required at the Tool layer. | |
| lang | No | zh / en. Default zh. | |
| mode | No | auto / price_move / event_impact. Default auto. | |
| query | Yes | User's original question, e.g. 'Why did BTC surge?' | |
| time_range | No | Time window: 30m/1h/2h/4h/24h. Default 2h. |
Output Schema
| Name | Required | Description |
|---|---|---|
| coin | Yes | |
| query | Yes | |
| summary | Yes | |
| time_range | Yes | |
| data_status | Yes | |
| duration_ms | Yes | |
| latest_news | Yes | |
| supporting_events | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show readOnlyHint, idempotentHint, and destructiveHint, so the tool is safe. The description adds value by detailing return components (summary, events, internal pool, completeness status) and its aggregator role, without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-loaded with purpose, then return details and role. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and the tool is a data aggregator, the description provides sufficient context about inputs and returns. Minor gap: doesn't mention default values for time_range and mode, but schema covers them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and descriptions in schema are adequate. The tool description does not add substantive meaning beyond the schema for parameters like query, coin, lang, mode, time_range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('explain') and resource ('crypto asset price move in a given time window'), and clearly differentiates from siblings like news_events_get_latest_events by stating it returns a summary, events, and internal items for attribution reasoning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is a data aggregator and the downstream agent performs final reasoning, implying when to use it. However, it does not explicitly exclude alternatives or provide comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
news_events_get_event_detailARead-onlyIdempotentInspect
[Read] Full detail for one event_id only. Filtered event list or timeline -> get_latest_events. Unknown id returns not found.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | Required event_id from get_latest_events items—opaque digest id, not a trading pair slug or headline hash. |
Output Schema
| Name | Required | Description |
|---|---|---|
| title | No | |
| content | No | |
| summary | No | |
| symbols | No | |
| event_id | Yes | |
| strength | No | |
| direction | No | |
| duration_ms | Yes | |
| occurred_at | No | |
| news_coverage | No | |
| impact_analysis | No | |
| community_reaction | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, etc. The description adds the important behavior that unknown IDs return 'not found', which helps agent handle errors. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with verb, no wasted words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with output schema and clear annotations, the description covers source of ID, error handling, and purpose. Complete and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage and description provides additional context: event_id comes from get_latest_events items, is an opaque digest ID, and is not a trading pair slug or headline hash. Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with '[Read]' and clearly states the tool retrieves full details for a single event ID. It distinguishes from sibling 'get_latest_events' by specifying that tool provides a filtered list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use 'get_latest_events' instead, and notes behavior for unknown IDs ('returns not found'). However, it doesn't guide against other related siblings like explain_market_move.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
news_events_get_latest_eventsARead-onlyIdempotentInspect
[Read] Filtered event list or timeline; each row includes event_id. One event_id detail -> get_event_detail. Headline/news feed -> search_news.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | No | Optional comma-separated tickers e.g. BTC,ETH for digest items; not the same as search_news tickers-only heat mode. | |
| limit | No | Page size; default 20, max 100. | |
| cursor | No | Optional pagination cursor. | |
| end_time | No | Absolute end (ISO8601 or Unix sec/ms). Mutually exclusive with time_range. | |
| event_type | No | Optional filter on structured digest event_type. Not search_news headline similarity/heat. | |
| start_time | No | Absolute start (ISO8601 or Unix sec/ms). Mutually exclusive with time_range; pair with end_time or let server fill the other bound. | |
| time_range | No | Relative 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
| Name | Required | Description |
|---|---|---|
| coin | No | |
| count | Yes | |
| items | Yes | |
| limit | Yes | |
| total | Yes | |
| end_time | No | |
| event_type | No | |
| start_time | No | |
| time_range | No | |
| duration_ms | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds behavioral context: returns event rows with event_id and links to detail tool. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single line with front-loaded '[Read]'. No wasted words, effectively links to sibling tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 optional params and output schema, description sufficiently explains purpose and behavior. References to sibling tools fill any gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, description adds extra meaning: e.g., coin not same as search_news, time_range mutual exclusivity, and explicit exclusion of macro series.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it's a read operation for a filtered event list/timeline with event_id. Distinguishes from siblings: get_event_detail for detail, search_news for headline/news feed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (filtered event list) and when not (use get_event_detail or search_news). Provides parameter guidance on coin and event_type, clarifying differences from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
news_feed_get_exchange_announcementsARead-onlyIdempotentInspect
[Read] Venue-published exchange notices: listings, delistings, maintenance. Media rumors or general crypto headlines -> search_news.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Window end Unix sec inclusive; forwarded downstream and filtered locally. | |
| coin | No | Comma-separated tickers; omit if empty. | |
| from | No | Window start Unix sec; omit if <= 0; MCP also filters locally after fetch. | |
| limit | No | Max rows; omit if unset or <= 0; cap 100 when set. | |
| query | No | Optional text filter on official venue notices; omit if empty. For general crypto media headlines use search_news—not a substitute for venue-published listing API. | |
| exchange | No | Venue id for API platform; used when platform is empty; not merged with query. | |
| platform | No | URL param platform; wins over exchange; if empty falls back to exchange. | |
| announcement_type | No | listing / delisting / maintenance / all. Omit or unknown value is treated as all (no type filter). |
Output Schema
| Name | Required | Description |
|---|---|---|
| to | No | |
| coin | No | |
| from | No | |
| count | Yes | |
| items | Yes | |
| limit | No | |
| query | No | |
| total | Yes | |
| exchange | No | |
| platform | No | |
| duration_ms | Yes | |
| announcement_type | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With strong annotations (readOnlyHint, idempotentHint, destructiveHint false), the description adds value by specifying the content types (listings, delistings, maintenance). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that is front-loaded with the purpose and an immediate alternative. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 optional parameters fully described in the schema and an output schema present, the description adequately covers the tool's context and purpose, though it could elaborate on return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description adds minimal extra semantic value beyond the schema, but it provides context for the query parameter regarding search_news.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves venue-published exchange notices (listings, delistings, maintenance). It uses the verb 'Read' and distinguishes from sibling tools like search_news for media rumors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (exchange notices) and when not to (media rumors -> search_news). The input schema's query parameter also reiterates this guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
news_feed_get_social_sentimentARead-onlyIdempotentInspect
[Read] Aggregate per-coin social sentiment for a time range: overall sentiment, positive/negative split, mention count, and sample tweets. X/Twitter post search or tweet-level evidence -> search_x. Multi-platform social thread search -> search_ugc.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | No | Tickers e.g. BTC or BTC,ETH for per-coin aggregates: overall sentiment, positive/negative split, mention count, sample tweets (top_tweets order); omit defaults to BTC server-side. X/Twitter post search or tweet-level evidence -> search_x. Multi-platform social thread search -> search_ugc. | |
| time_range | No | 1h / 24h (default) / 7d window for per-coin sentiment aggregation (overall sentiment, positive/negative split, mention count). |
Output Schema
| Name | Required | Description |
|---|---|---|
| coin | No | |
| time_range | No | |
| top_tweets | Yes | |
| duration_ms | Yes | |
| mention_count | Yes | |
| sentiment_label | Yes | |
| overall_sentiment | Yes | |
| sentiment_label_raw | No | |
| sentiment_distribution | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds behavioral details: returns overall sentiment, positive/negative split, mention count, sample tweets, and aggregates per-coin over time range. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states core purpose, second provides sibling guidance. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema descriptions, annotations for safety, and output schema presence, the description is complete. It covers inputs, outputs, and usage context. Only minor omission: no explicit mention of aggregation over time, but that's implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds examples (e.g., 'BTC or BTC,ETH' for coin, '1h / 24h / 7d' for time_range) and default values, going beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb '[Read]' and resource 'aggregate per-coin social sentiment', listing specific outputs. It also distinguishes from siblings by directing tweet-level search to search_x and multi-platform threads to search_ugc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use alternatives: 'X/Twitter post search or tweet-level evidence -> search_x. Multi-platform social thread search -> search_ugc.' This tells the agent when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
news_feed_search_newsARead-onlyIdempotentInspect
[Read] Search the platform news index for headlines, news items, and briefing-style result lists. Open-web research with synthesized answers and cited external pages -> web_search. Event catalog with event_id -> get_latest_events.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | No | Comma-separated tickers mapped to API tickers; sent only when query is empty (omitted when query is set). Heat mode supports news-item / briefing-style lists on the platform index—not open-web synthesis (web_search). | |
| lang | No | MCP-only filter on metadata.lang or top-level lang; not sent to upstream API. | |
| page | No | Page number mapped to API page; default 1. | |
| limit | No | Page size mapped to API page_size; default 10, max 100. | |
| query | No | Non-empty: similarity mode (no tickers; default similarity_score 0.6). Empty: heat mode (top_total_score 1; optional coin/tickers). Platform news index for headlines, news items, and briefing-style result lists—not open-web research with synthesized answers and cited external pages (web_search) or event catalog with event_id (get_latest_events). | |
| sort_by | No | e.g. time (default); similarity mode with top_total_score 0 may still apply MCP local time sort. | |
| end_time | No | End time mapped to API to (Unix sec). Ignored when time_range is set. End-only defaults start to 24h before end. | |
| platform | No | Source platform name for API platform (e.g. panews, theblock). | |
| start_time | No | Start time (ISO8601 or Unix sec/ms) mapped to API from. Ignored when time_range is set. Start-only defaults end to now; both empty defaults last 7d when time_range is also empty. | |
| time_range | No | Optional preset window: 1h / 24h (default when preset value invalid) / 7d / 30d. When non-empty, overrides start_time/end_time and maps to API from/to (Unix epoch seconds). Omit to use start_time/end_time or implicit last-7d when both are empty. | |
| platform_type | No | Legacy: maps to API platform when platform is omitted; omit platform when value is all. | |
| top_total_score | No | Only when query empty (0 or 1); non-empty query forces similarity mode. | |
| similarity_score | No | Similarity threshold; default 0.6 when query set; when query empty only sent if explicitly set. |
Output Schema
| Name | Required | Description |
|---|---|---|
| to | Yes | |
| coin | No | |
| from | Yes | |
| lang | No | |
| page | No | |
| count | Yes | |
| items | Yes | |
| limit | No | |
| query | No | |
| total | Yes | |
| sort_by | No | |
| end_time | No | |
| platform | No | |
| page_size | No | |
| start_time | No | |
| time_range | No | |
| duration_ms | Yes | |
| platform_type | No | |
| top_total_score | Yes | |
| similarity_score | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds '[Read]' which aligns with these annotations but does not disclose additional behavioral traits such as rate limits, result pagination, or the fact that it only searches the platform index (no external web). No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with two arrow-notation links to alternative tools. It is front-loaded with purpose but the links could be more neatly integrated. Still efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, two modes: heat vs similarity), the description is too sparse. It does not summarize the two operational modes or explain how parameter choices affect behavior. The existence of an output schema partially compensates, but the description should provide a high-level overview of the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 13 parameters have detailed descriptions in the input schema (100% coverage). The tool description itself does not add parameter-specific meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with '[Read] Search the platform news index for headlines, news items, and briefing-style result lists.' This clearly states the verb (Search) and resource (platform news index). It also explicitly distinguishes from two sibling tools: web_search and get_latest_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit alternatives for open-web research (web_search) and event catalog (get_latest_events). However, it does not differentiate from other news_feed siblings like news_feed_search_x or news_feed_search_ugc, leaving the agent without clear guidance on when to prefer this tool over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
news_feed_search_ugcARead-onlyIdempotentInspect
[Read] Reddit/Discord/Telegram/YouTube-style UGC: non-empty query uses vector API; coin without query uses OpenSearch. Both empty invalid. X/Twitter narrative -> search_x; headlines -> search_news. Not macro economic statistics; not structured event list -> get_latest_events.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | No | Ticker filter; with query filters results; without query required with index for OpenSearch list mode. | |
| limit | No | Max items; default 10, max 50. | |
| query | No | Optional NL query; non-empty uses vector search. May combine with coin; both empty is invalid. | |
| domain | No | UGC topical bucket: crypto / defi / finance / macro / ai_agent / web3_dev / all (default all). macro = social discussion about macro themes, not CPI/Fed/unemployment statistics (use macro data tools) or get_latest_events. | |
| channel | No | Optional source channel e.g. r/ethereum or handle. | |
| sort_by | No | relevance (default) / upvotes / recent. | |
| platform | No | reddit / discord / telegram / youtube / all (default all). | |
| time_range | No | 1h / 24h / 7d (default) / 30d / all. | |
| quality_tier | No | A (default, high quality) / B / all. |
Output Schema
| Name | Required | Description |
|---|---|---|
| coin | No | |
| count | Yes | |
| items | Yes | |
| limit | No | |
| query | No | |
| total | Yes | |
| domain | No | |
| channel | No | |
| sort_by | No | |
| platform | No | |
| time_range | No | |
| duration_ms | Yes | |
| quality_tier | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. Description adds behavioral details: uses vector search with query, OpenSearch without, and clarifies it is not macro statistics or structured events. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is dense but packs key information in a few sentences. Front-loaded with purpose. Could be slightly more structured, but no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters with dependencies, the description explains the core logic (query vs no query) and boundaries. Output schema exists, so return format is covered. Sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds context on query/coin interaction (vector vs OpenSearch), domain bucket meaning, and invalid combinations, going beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches UGC from Reddit, Discord, Telegram, YouTube, and explicitly differentiates from siblings like search_x (X/Twitter) and search_news (headlines). It also mentions the vector API vs OpenSearch distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use (UGC), when not (X, headlines, macro stats, events), and alternative tools (search_x, search_news, get_latest_events). Also explains valid and invalid query/coin combinations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
news_feed_search_xARead-onlyIdempotentInspect
[Read] Search and analyze X/Twitter discussions for a topic, with tweet-level evidence and cited posts. Aggregate social mood, sentiment score, or positive/negative split -> get_social_sentiment. Open-web pages -> web_search. Multi-platform social search -> search_ugc.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | No | Platform fallback: maps to tickers for feed-style items when xAI path is unused—tweet-level X evidence remains the primary tool goal; per-coin sentiment KPIs -> get_social_sentiment. | |
| days | No | xAI only: lookback days when time_range omitted; omitted or <=0 treated as 1 (24h); min 1 when explicitly set. | |
| lang | No | Answer language: zh (default) / en / auto. Also used by platform fallback as MCP local lang filter. | |
| page | No | Platform fallback: page number. | |
| limit | No | Platform fallback: page_size, default 10. | |
| model | No | xAI only: override configured Grok model id. | |
| query | No | X/Twitter topic for tweet-level evidence and cited posts; English recommended. xAI: empty returns no results. Aggregate social mood, sentiment score, or positive/negative split -> get_social_sentiment. Open-web pages -> web_search. Multi-platform social search -> search_ugc. Platform fallback matches search_news.query semantics. | |
| sort_by | No | Platform fallback: sort field. | |
| end_time | No | Platform fallback: maps to to. | |
| platform | No | Platform fallback: platform. | |
| start_time | No | Platform fallback: maps to from (Unix sec). | |
| time_range | No | Preferred recency window for search_x: 1h / 24h (default) / 7d. Takes precedence over days when set. | |
| platform_type | No | Platform fallback: maps when platform omitted. | |
| allowed_handles | No | xAI only: include these X handles without @, max 10; mutually exclusive with excluded_handles. | |
| top_total_score | No | Platform fallback: heat vs similarity. | |
| excluded_handles | No | xAI only: exclude these handles, max 10. | |
| similarity_score | No | Platform fallback: similarity threshold. | |
| enable_image_understanding | No | xAI only: analyze images in posts. | |
| enable_video_understanding | No | xAI only: analyze video in posts. |
Output Schema
| Name | Required | Description |
|---|---|---|
| coin | No | |
| days | No | |
| lang | No | |
| count | Yes | |
| items | Yes | |
| model | No | |
| query | No | |
| total | Yes | |
| source | No | |
| content | Yes | Same as summary for legacy clients; tweet-level X/Twitter evidence—not headline index (search_news). |
| summary | Yes | xAI: synthesized narrative from X/Twitter discussions with tweet-level evidence (same as content; always present). Not open-web synthesis with cited external pages (web_search). Not per-coin sentiment KPIs over a time range (get_social_sentiment). |
| to_date | No | |
| platform | No | |
| from_date | No | |
| disclaimer | No | Fixed disclaimer on xAI success; empty on platform fallback. |
| key_points | Yes | xAI: bullet points from cited posts; empty array if none. Not briefing-style platform news lists (search_news). |
| duration_ms | Yes | |
| cited_tweets | Yes | xAI: tweet-level evidence and cited posts; fields depend on model and citations. |
| platform_type | No | |
| allowed_handles | No | |
| sentiment_label | Yes | xAI: bullish / bearish / neutral for the discussion; empty if unknown. Not per-coin sentiment label KPIs (get_social_sentiment). |
| sentiment_score | No | |
| excluded_handles | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it provides 'tweet-level evidence and cited posts' and mentions internal routing (xAI vs platform fallback), which is useful context. No contradiction with annotations. However, it could detail the dual-mode behavior more explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences front-loaded with key purpose, then routing guidance) with no wasted words. Every sentence earns its place: the first states the core function, the second provides routing alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (19 parameters, dual-modes, output schema exists), the description covers the essential purpose and routing. It could mention the output type (tweet-level evidence with cited posts) more explicitly, but overall it is sufficient for an agent to decide when to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning the input schema already describes all 19 parameters. The description does not add significant parameter-level detail beyond mentioning 'query' implicitly. Baseline 3 is appropriate since the description adds minimal parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with '[Read]' indicating it's a read operation, then clearly states 'Search and analyze X/Twitter discussions for a topic, with tweet-level evidence and cited posts.' This specifies the verb (search and analyze), resource (X/Twitter discussions), and scope (tweet-level evidence), distinguishing it from siblings like web_search (open-web) and search_ugc (multi-platform).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when to use this tool vs. alternatives: 'Aggregate social mood, sentiment score, or positive/negative split -> get_social_sentiment. Open-web pages -> web_search. Multi-platform social search -> search_ugc.' This gives clear guidance on when to choose another tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
news_feed_web_searchARead-onlyIdempotentInspect
[Read] Search the open web and return a synthesized answer with cited external pages. Built-in headline lookup, news-item search, or briefing-style news list -> search_news. X/Twitter-only discussion or tweet evidence -> search_x.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | No | Optional ticker or project (e.g. BTC, ETH) to focus the open-web synthesized answer—not platform news index tickers (search_news). | |
| lang | No | Answer language: zh (default) / en / auto. | |
| mode | No | Answer length: analysis (default, fuller synthesized text) or brief (~100 chars). Not chart/indicator technical analysis (RSI/MACD). | |
| limit | No | Max cited external pages in the answer; default 5, max 10. | |
| query | No | Required NL question: search the open web and return a synthesized answer with cited external pages—not built-in headline lookup, news-item search, or briefing-style news list (search_news), nor X/Twitter-only discussion or tweet-level evidence (search_x). | |
| time_range | No | Recency window for open-web synthesis with cited external pages: 1h / 24h (default) / 7d / 30d. Not DeFi/TVL dashboard metrics (use platform-metrics tools). |
Output Schema
| Name | Required | Description |
|---|---|---|
| coin | No | |
| lang | No | |
| mode | No | |
| count | Yes | |
| items | Yes | |
| model | No | |
| query | No | |
| total | Yes | |
| source | No | |
| summary | Yes | |
| disclaimer | No | |
| key_points | Yes | |
| time_range | No | |
| duration_ms | Yes | |
| cited_sources | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the tool returns a 'synthesized answer with cited external pages,' which implies generation and aggregation, a behavioral trait not captured by annotations. It does not contradict annotations, and the added context is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core purpose, and the second provides usage alternatives. It is front-loaded, contains no fluff, and every sentence serves a distinct purpose (definition and differentiation).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameter count (6), presence of output schema, and many siblings, the description covers the essential: what the tool does, when to use it, and when to use alternatives. It could briefly mention the output schema or rate limits, but the existing content is sufficient for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so baseline is 3. The tool description itself does not add new parameter-level information beyond what the schema descriptions already provide (e.g., coin being optional, query being required). The schema descriptions are thorough, limiting the additional value from the main description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with '[Read]' indicating read-only operation, then clearly states 'Search the open web and return a synthesized answer with cited external pages,' which specifies a concrete verb, resource, and output format. It explicitly distinguishes from siblings by directing to search_news and search_x for specific use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when NOT to use the tool: 'Built-in headline lookup, news-item search, or briefing-style news list → search_news. X/Twitter-only discussion or tweet evidence → search_x.' This provides clear exclusions and alternatives, guiding the agent effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
news_prediction_get_event_signalARead-onlyIdempotentInspect
[Read] Single event signal from dws_external_event_signal_hf by event_ref (venue:venue_event_id). window 1h/24h/7d (default 24h). Returns outcome_probabilities, volume_flow, directional_context, optional markets[] (default include_markets=true). depth_summary always null—use get_market_orderbook for live depth. daily_ranking when rank index configured. Discover event_ref -> search_events. include_orderbook_summary ignored.
| Name | Required | Description | Default |
|---|---|---|---|
| venue | No | Optional; each non-empty value must equal event_ref venue or invalid_param. | |
| window | No | Recency filter on part_hour; default 24h. Allowed: 1h, 24h, 7d (case-insensitive). | |
| event_ref | Yes | Required. venue:venue_event_id (split on first colon; id may contain more colons). Discover via search_events. | |
| include_markets | No | Omitted or null defaults true. false omits markets[]; true parses embedded markets or enriches from predictionMarketIndex. | |
| include_orderbook_summary | No | Deprecated and ignored; depth_summary is always null—use get_market_orderbook. |
Output Schema
| Name | Required | Description |
|---|---|---|
| window | No | |
| markets | No | |
| partial | Yes | |
| duration_ms | Yes | |
| signal_time | Yes | |
| volume_flow | Yes | |
| daily_ranking | No | |
| depth_summary | Yes | |
| event_identity | Yes | |
| missing_sources | Yes | |
| source_data_status | Yes | |
| directional_context | Yes | |
| outcome_probabilities | Yes | |
| cross_venue_divergence | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds behavioral details: include_orderbook_summary is ignored, depth_summary always null, daily_ranking conditionally available, and include_markets behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but each sentence adds value; front-loaded with purpose. Slight room for structuring but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description covers all essential: source, key parameters, data fields returned, conditionally available fields, and explicit alternative tools. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaning: explains venue constraint, window allowed values, event_ref format, include_markets default and behavior, and include_orderbook_summary deprecated status. Significantly enriches understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description begins with '[Read] Single event signal from dws_external_event_signal_hf by event_ref', clearly stating verb and resource. It differentiates from siblings by noting that for live depth one should use get_market_orderbook and to discover event_ref use search_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use alternative tools: 'depth_summary always null—use get_market_orderbook for live depth' and 'Discover event_ref -> search_events'. Also provides default values and allowed options for window.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
news_prediction_get_fastest_rising_rankingARead-onlyIdempotentInspect
[Read] Daily venue/overall ranking by probability rise (UTC rank_date). Optional venue[], category, status (same as volume_delta ranking). Drops rows missing open_mid_probability_utc or probability_delta_today. Requires predictionRankIndex.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size; default 20, max 100. | |
| venue | No | Optional venue filter. Allowed: polymarket, predict_fun. | |
| status | No | Optional status filter on rank index. Allowed: active, closed, resolved, all. Defaults to active. | |
| category | No | Optional category filter: exact term on rank index field category; omit or all to disable. | |
| date_utc | No | UTC date in YYYY-MM-DD. Defaults to today_utc. |
Output Schema
| Name | Required | Description |
|---|---|---|
| overall | Yes | |
| partial | Yes | |
| by_venue | Yes | |
| duration_ms | Yes | |
| generated_at | Yes | |
| rank_date_utc | Yes | |
| missing_sources | Yes | |
| excluded_reasons | Yes | |
| source_data_status | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral details: it drops rows missing specific fields and requires predictionRankIndex, providing context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a single sentence plus two brief notes. It front-loads the main action with a '[Read]' tag. Could be more structured, but it is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description adequately covers the tool's purpose, filtering options, data quality notes, and prerequisites. It could explicitly state sort order (fastest rising implies descending probability rise) and handle missing indices, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the relationship with the sibling tool (same filters) and the data dropping condition, enriching parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a daily ranking by probability rise, with optional venue, category, and status filters. It differentiates from the sibling volume_delta ranking by implying a different metric, but does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that filters are the same as volume_delta ranking, but does not provide explicit guidance on when to use this tool versus that sibling. It mentions a prerequisite (predictionRankIndex) and data dropping behavior, which helps context but lacks explicit when-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
news_prediction_get_market_orderbookARead-onlyIdempotentInspect
[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.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Empty or current only (default current). history and other values rejected. | |
| depth | No | yes_bids/yes_asks top-N levels; default 20; allowed 1-20 inclusive; out of range invalid_param. | |
| venue | Yes | Required. polymarket or predict_fun. polymarket needs predictionMarketIndex; predict_fun needs predictFunAPIKey (else partial_not_configured, not a tool error). | |
| end_time | No | Unsupported; if set, request is rejected. | |
| market_id | Yes | Required. 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_token | No | Unsupported; if set, request is rejected. | |
| start_time | No | Unsupported; if set, request is rejected. | |
| granularity | No | Unsupported; if set, request is rejected. |
Output Schema
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| venue | Yes | |
| partial | Yes | |
| market_id | Yes | |
| source_api | Yes | |
| book_levels | Yes | |
| duration_ms | Yes | |
| snapshot_time | Yes | |
| missing_sources | Yes | |
| source_data_status | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses beyond annotations: partial results on side failure, tool error only if both fail, null fields in partial state, and specific error returns (partial_not_configured, resource_not_found). Aligns with readOnlyHint and idempotentHint, adding meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense with information, but front-loaded with the core purpose. Though slightly cluttered with multiple conditions, every sentence serves a purpose. Could be more structured, but remains efficient for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two venues, multiple error modes, partial results), the description addresses all critical behavioral aspects. Output schema exists, so return value explanation is unnecessary. Covers parameter constraints, error states, and inter-tool hints (e.g., search_events).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, description still adds significant value: explains venue-specific ID formats, depth range and default, mode constraints, and rejection of unsupported parameters. This enriches the schema by providing concrete usage rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the live current order book, specifying the mode and depth. It distinguishes from sibling tools like search_events and get_event_signal by focusing on order book data, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (live order book only), what parameters are rejected (history, granularity, etc.), and prerequisites for each venue (opensearch.predictionMarketIndex for polymarket, predictFunAPIKey for predict_fun). Also explains error handling and partial results, enabling correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
news_prediction_get_volume_delta_rankingARead-onlyIdempotentInspect
[Read] Daily venue/overall ranking by volume delta (UTC rank_date). Optional venue[], category (exact term on rank index), status (active/closed/resolved/all; default active). Requires opensearch.predictionRankIndex.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size; default 20, max 100. | |
| venue | No | Optional venue filter. Allowed: polymarket, predict_fun. | |
| status | No | Optional status filter on rank index. Allowed: active, closed, resolved, all. Defaults to active. | |
| category | No | Optional category filter: exact term on rank index field category; omit or all to disable. | |
| date_utc | No | UTC date in YYYY-MM-DD. Defaults to today_utc. |
Output Schema
| Name | Required | Description |
|---|---|---|
| overall | Yes | |
| partial | Yes | |
| by_venue | Yes | |
| duration_ms | Yes | |
| generated_at | Yes | |
| rank_date_utc | Yes | |
| missing_sources | Yes | |
| excluded_reasons | Yes | |
| source_data_status | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by specifying the ranking is daily, based on UTC rank_date, and requires the system index 'opensearch.predictionRankIndex'. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states core purpose and constraint, second lists optional filters and a system dependency. Concise, front-loaded, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5 parameters with 100% schema coverage, rich annotations, and an existing output schema, the description covers behavior (read, daily, filtered), dependencies (index), and constraints (UTC date). No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description echoes parameter intent (venue, category, status filters, date_utc) but does not add meaningful detail beyond the schema. For example, category is described as 'exact term on rank index field category', which is also in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a read operation for daily ranking by volume delta, with specific filters. The name and verb 'get_volume_delta_ranking' plus the description make the tool's purpose clear and distinguishable from siblings like 'get_fastest_rising_ranking'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving volume delta rankings but does not explicitly state when to use this tool over alternatives. No guidance on exclusions or conditions is provided, though the context of sibling tools offers some differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
news_prediction_search_eventsARead-onlyIdempotentInspect
[Read] Search prediction events on opensearch.predictionEventSignalIndex (dws_prediction_event_signal_hf alias, hourly UNIQUE part_hour+venue+venue_event_id). query/coin/category optional; coin-only unsupported_filter. status filters event_status; status_tags from status_json_array. sort recently_listed uses create_time (first_seen); volume_delta_today uses total_volume_usd_24h (no volume_delta column). category filter: event_category_primary or lead_market_category_primary; excludes empty event_category_primary. Collapse venue_event_id. with_markets: source_markets_json or predictionMarketIndex. Detail -> get_event_signal (external); orderbook -> get_market_orderbook.
| Name | Required | Description | Default |
|---|---|---|---|
| coin | No | Optional coin ticker; cannot be used alone without query or category (unsupported_filter). With query/category expands text recall only (best_effort). | |
| limit | No | Page size; default 20, max 100. | |
| query | No | Optional full-text query; all of query, coin, category are optional. | |
| venue | No | Optional venue filter. Allowed: polymarket, predict_fun. | |
| status | No | Filter by ES event_status; default active. Allowed: active, closed, resolved, all. Response status_tags comes from status_json_array. | |
| sort_by | No | Sort key; default attention. Allowed: attention, volume, liquidity, recently_listed, probability_change, volume_delta_today (maps to total_volume_usd_24h on signal index). | |
| category | No | Optional primary category enum (crypto_price, sports, elections, …). Matches event_category_primary or lead_market_category_primary. | |
| page_token | No | Base64URL page token from prior next_page_token; filters must match first page. | |
| with_markets | No | When true, attach market summaries from source_markets_json or predictionMarketIndex. |
Output Schema
| Name | Required | Description |
|---|---|---|
| events | Yes | |
| partial | Yes | |
| duration_ms | Yes | |
| missing_sources | No | |
| next_page_token | No | |
| coin_filter_mode | No | |
| effective_sort_by | No | Actual sort applied (equals sort_by unless ES sort fallback). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Builds on readOnlyHint and idempotentHint annotations by detailing collapse on venue_event_id, sort field mappings, and behavior of filters. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but concise single paragraph capturing essential details. Slightly heavy due to technical terms, but front-loaded with purpose. No unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 optional parameters, no required ones, and an output schema, the description covers search behavior, filtering, sorting, pagination, and relationship to other tools. Complete for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions; the description adds value by explaining edge cases (coin unsupported alone, sort_by mapping to actual columns, category behavior, with_markets source).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches prediction events on a specific OpenSearch index, with the verb 'Search' implied and resource specified. It distinguishes from siblings like news_prediction_get_event_signal (detail) and news_prediction_get_market_orderbook (orderbook) by noting they are external.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides some usage constraints (coin cannot be used alone, sort mapping, category behavior) but does not explicitly contrast with other search tools like news_feed_search_news or news_events_get_latest_events. Lacks explicit when-to-use or 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!