Gate News MCP

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the bar is low. The description adds meaningful behavior: it is a data aggregator with real-time Tavily search plus internal event pool, returns data-completeness status, 'No account access, no order placement or fund transfers,' and 'Not investment advice.' These disclose boundaries beyond the annotations. No contradiction; the 'Read-only' claim aligns with readOnlyHint=true.

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?

Roughly four sentences with the core purpose front-loaded, followed by role clarification ('data aggregator... downstream agent performs final attribution'), then safety disclaimers. Every sentence earns its place; the '[Read]' prefix is slightly redundant with readOnlyHint but harmless. Efficient and well-ordered.

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 and safety annotations covering read/order/account boundaries, the description covers the essential operational facts: data sources, aggregator role, completeness status, and the non-advice caveat. The only notable gap is no explicit distinction from get_market_move_report/list_market_move_reports, but for a read-only aggregator with a rich output schema this is largely complete.

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 description coverage is 100%, with each parameter (coin, lang, mode, query, time_range) well-documented in the schema including defaults and example values. The description does not add parameter-specific meaning beyond the schema — it only contextualizes the return structure. Per the calibration baseline, 3 is appropriate when the schema carries the load.

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 states a specific verb+resource: 'Explain what drove a crypto asset's price move in a given time window.' It clarifies its role as a data aggregator whose downstream agent performs attribution reasoning, which loosely distinguishes it from report-generating siblings like news_events_get_market_move_report. However, it never explicitly names a sibling to contrast with, and the verb 'Explain' slightly conflicts with the disclosure that the tool only aggregates data rather than producing the explanation. Clear but not fully differentiated.

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 when to use it ('Explain what drove a crypto asset's price move') and describes its output (summary, high-priority events, event pool items, completeness status). Yet it offers no explicit exclusions or named alternatives among the many news_events_/news_feed_/news_prediction_ siblings, leaving an agent to infer the boundary between this aggregator and get_market_move_report or web_search. Usable context, but no routing guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context beyond that: persisted impact_direction and reason, not-found behavior, and disclaimers about no account access, no order placement, and not being investment advice. 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 compact, front-loaded with the core purpose ('Full detail for one event_id only'), and every sentence adds necessary context: scoping, alternative, error behavior, and safety disclaimers. No redundancy or filler.

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 read tool with an existing output schema, the description covers purpose, usage, error handling, and safety. It doesn't explicitly route to other siblings (like explain_market_move) but that's not critical given the clear event_id context. Overall adequate and complete for correct 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 description already fully documents the event_id parameter (100% coverage) with details like 'opaque digest id, not a trading pair slug'. The description only reinforces that the ID comes from get_latest_events, adding marginal meaning beyond the schema. Baseline 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?

Description clearly states the tool returns 'Full detail for one event_id only' and explicitly contrasts with get_latest_events ('Filtered event list or timeline -> get_latest_events'). This distinguishes it from the primary sibling while naming the exact resource and operation.

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: use get_latest_events for filtered lists/timelines, and implies this tool is for full detail on a specific event_id. Mentions 'Unknown id returns not found' which sets expectations. Does not exhaustively list all sibling alternatives, but the main one is covered clearly.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, but the description adds meaningful behavioral context: it never triggers report regeneration, does not expose is_make_new, follows a UTC0 timestamp convention for field names not ending in _utc8, and explicitly states it is read-only public research data with no account access or order placement. This goes well beyond the annotations and fully discloses the tool's operational behavior.

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 and well-structured: starts with the primary action, then details the lookup priority, timestamp convention, constraints, and disclaimers. Each sentence serves a purpose, and the most critical information (query and priority) is front-loaded. No filler or redundancy.

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 a rich output schema and full parameter documentation, the description covers all necessary operational details: lookup priority, timezone handling, non-regeneration, and safety constraints. An agent has everything needed to call this tool correctly without missing information about parameter interactions or side effects.

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 all parameters are documented. The description adds value by clarifying the interaction between the optional params: the lookup priority and the fallback to the latest report when both are omitted. It also notes that symbol is normalized to uppercase (already in schema) but confirms the required nature. The description meaningfully supplements the schema's static descriptions with dynamic behavior.

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's purpose: 'Query a stored market-move attribution report by symbol, optional report_id, or optional event_id.' It names the specific resource and the lookup priority, distinguishing it from sibling tools like list_market_move_reports or explain_market_move. The verb 'Query' and the resource 'market-move attribution report' leave no ambiguity.

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 explains its own lookup priority (report_id > event_id > latest) and states it never requests regeneration, but it does not explicitly contrast this tool with siblings like news_events_list_market_move_reports or explain_market_move. When to use this versus alternatives is only implied by the naming and the behavior, not stated outright.

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

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

Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), the description discloses key behaviors: 'Reports may be updated after their market event, so updated_at can be later than event_time,' timezone handling ('Timezone-less inputs are UTC0; inputs with an explicit offset are converted to UTC0'), and the read-only public nature. These details are not captured in the schema or annotations and meaningfully inform the agent about side effects and data semantics.

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 despite covering multiple aspects: purpose, filtering, sorting, timezone behavior, update-after-event nuance, and safety disclaimers. It is front-loaded with the core action and immediately followed by important edge-case behavior. Every sentence contributes value; there is no redundancy or fluff.

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 output schema is present (so return structure is covered) and annotations cover safety/idempotency, the description fills all remaining gaps: it explains timezone conversion, inclusive bounds, sorting, the relationship between updated_at and event_time, and the read-only nature. An agent has everything needed to correctly invoke the tool without ambiguity.

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 the baseline is 3. The description adds contextual meaning about the parameters (e.g., inclusive range, updated_at semantics) but repeats what the schema already states for start_time and end_time. It does not add new parameter-level information beyond what the schema provides, so no higher score is warranted.

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 states a specific verb and resource: 'List stored market-move attribution reports for one symbol, filtering by an inclusive UTC0 updated_at range and sorting results by event_time descending.' This precisely distinguishes it from sibling tools like news_events_get_market_move_report (which fetches a single report) and news_events_explain_market_move (which explains events). The scope, filter, and sort behavior are 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?

The description provides clear context about what the tool does and its read-only, non-advice nature, but it does not explicitly name alternative tools or state when to use this vs. a sibling like news_events_get_market_move_report. The guidance is implied by the name and purpose, but no explicit when/when-not guidance is present.

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

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 stating 'Read-only public research data', 'No account access, no order placement or fund transfers', and 'Not investment advice'. These disclosures go beyond the boolean hints and give the agent concrete behavioral boundaries.

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 concise sentences with no filler. The primary purpose is front-loaded, followed by the exclusion for search_news and then safety disclaimers. Every clause earns its place, and the description avoids redundancy with the annotations.

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 read-only tool with a complete output schema and full parameter descriptions, the description covers everything an agent needs to know: what it does, when to use it, alternatives, and behavioral constraints. The presence of an output schema means return format details are already structured, so nothing critical is missing.

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 description coverage is 100%, so each of the 8 parameters is well-documented in the schema itself. The description does not add extra parameter semantics beyond what the schema provides, but it does reinforce the query parameter's distinction from search_news indirectly. Baseline 3 is appropriate since the schema handles parameter meaning.

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 specific resource (venue-published exchange notices) and lists the types (listings, delistings, maintenance). It explicitly differentiates from search_news, naming the alternative for media rumors or general headlines. This distinguishes it from the sibling tools without ambiguity.

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 guidance: for venue-published notices, and when not to use it (for media rumors/general crypto headlines, use search_news). Also clarifies the tool's read-only nature and that it cannot place orders or transfer funds, which is essential decision-making context for an agent.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds beyond that: 'Unknown or no-data tickers may return an empty result with hide_reason=no_data' and 'leading and trailing whitespace is removed...normalized to uppercase.' It also discloses 'No account access, no order placement or fund transfers.' This adds meaningful behavioral context not present in 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 well-structured and front-loaded with the primary action, then alternatives, then annotations-aligned caveats. It is slightly longer than strictly necessary (additional disclaimers like 'Not investment advice'), but each sentence serves a purpose. No redundant filler.

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?

The output schema exists, so return values are covered there. The description covers purpose, scope, alternatives, safety (read-only), and edge-case behavior (no-data handling). For a tool with rich annotations and complete parameter documentation, nothing essential is missing for correct 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 description coverage is 100%, so all parameters are thoroughly documented in the schema. The tool description does not add parameter-specific meaning beyond what the schema provides (e.g., it mentions 'one coin' and '4h' but these are already in schema). Per the baseline rule, score 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 states a specific verb ('Get') and resource ('top 2-4 social discussion themes for one coin over the latest 4h') with clear scope and output contents. It explicitly names sibling alternatives (search_ugc, search_x) and explains when to use them instead, making differentiation immediate.

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 alternatives: 'For arbitrary social search use search_ugc; for X/Twitter-only narrative research use search_x.' This clearly tells the agent when NOT to use this tool and points to the correct sibling. It also adds context about read-only nature, which reinforces appropriate use.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description reinforces this with 'Read-only public research data' and adds safety context not present in annotations: 'No account access, no order placement or fund transfers. Not investment advice.' This is extra value beyond what annotations provide. It does not contradict any annotation.

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?

Four sentences, zero filler. The purpose is front-loaded, alternatives are given next, and safety disclaimers finish. Every sentence earns its place. The structure is logical: what → when else → safety. Perfectly sized.

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?

The description covers the main function, the specific output facets, clear routing to siblings, and safety boundaries. An output schema is present, so return structure is handled there. The mention of 'display eligibility' and 'platform breakdown' gives agents a preview of the response without overpromising. Nothing an agent needs to decide whether to call this tool is missing.

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 description coverage is 100%, so every parameter (coin, window, platforms) has a thorough, standalone description. The tool description itself does not add parameter-level detail, but with full schema coverage the baseline is 3 and no compensation is required. The description's mention of 'platform breakdown' implicitly ties to the platforms parameter, but that's not substantial added 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 opens with a specific verb and resource: 'Get a coin's 24h multi-platform social mention burst signal, growth, sentiment direction, platform breakdown, and display eligibility.' It clearly lists the distinct outputs, and the sibling tools it names (get_social_sentiment, search_ugc) make the differentiation obvious. An agent can immediately tell this is the mention-burst tool, not a general sentiment or discussion search.

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?

Explicit guidance is given: 'For general sentiment ratios and sample tweets use get_social_sentiment; for individual social discussions use search_ugc.' This tells the agent when to pick an alternative. It also frames the query context ('24h multi-platform social mention burst') and includes caveats like 'No account access, no order placement or fund transfers,' which sets clear boundaries on legitimate use. No inference is required.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the core safety profile is known. The description adds useful context beyond annotations: 'No account access, no order placement or fund transfers' and 'Not investment advice', which prevents misuse. It also states 'Read-only public research data', reinforcing and extending the annotation. No contradictions; the description complements annotations well.

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 front-loads the core function and outputs, then provides routing guidance, then disclaimers. It is moderately concise with no wasted sentences, though it duplicates the routing guidance from the schema (which is acceptable but slightly redundant). Structure is logical and an agent can grasp the purpose quickly.

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 simple read-only query with two optional parameters and an output schema, the description is complete from an agent's perspective: it states what it does, what it returns, when to use alternatives, and safety constraints. It even disclaims investment advice. Nothing an agent needs to invoke it correctly is missing.

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 description coverage is 100%, so both parameters (coin and time_range) already have thorough descriptions in the input schema, including examples (BTC or BTC,ETH) and default values. The description itself adds little new parameter semantics—it repeats the routing statement already present in the coin parameter description. Baseline 3 is appropriate because the schema does the heavy lifting and the description does not conflict or add meaningful additional detail.

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 aggregates per-coin social sentiment for a time range and lists the specific outputs (overall sentiment, positive/negative split, mention count, sample tweets). It also distinguishes itself from sibling tools by explicitly routing X/Twitter post search to search_x and multi-platform thread search to search_ugc, so an agent can immediately tell them apart without opening schemas.

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 when-to-use guidance: it names sibling tools (search_x, search_ugc) and the specific conditions (tweet-level evidence vs. multi-platform threads). It also states that it is read-only public research data and disclaims investment advice, which clarifies appropriate contexts. No ambiguity remains about when to select this tool over alternatives.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds value by stating there is no account access, no order placement or fund transfers, and that it is not investment advice. This goes beyond what annotations provide, though it doesn't detail response format—which is covered by the output schema.

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—and front-loads the core purpose, then adds routing and warnings. No wasted words; every sentence earns its place, making it efficient for an agent 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?

For a tool with 13 parameters and an output schema, the description covers purpose, sibling differentiation, and behavioral constraints. It doesn't need to explain parameters because the schema does that, and the output schema covers return values. It is complete for the description's role.

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 parameter descriptions are very detailed (e.g., query explains similarity vs heat mode, coin explains when it is sent). The description itself doesn't add parameter-level semantics but relies on the schema, so baseline 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 clearly states it searches the platform news index for headlines, news items, and briefing-style result lists. It uses a specific verb and resource, and explicitly differentiates from web_search and get_latest_events, so an agent can tell them apart without inspecting schemas.

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 names alternatives and the conditions that route to them: open-web research with synthesized answers goes to web_search, and event catalog with event_id goes to get_latest_events. Also clarifies it's read-only research with no account access or orders, setting clear context for when to invoke.

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

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

Annotations already claim readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only public research data. No account access, no order placement or fund transfers.' It adds the dual-API behavior (vector vs OpenSearch) and the 'Not investment advice' disclaimer beyond what annotations provide. Effortless consistency with annotations, adding context rather than repeating them.

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 dense paragraph, but every sentence earns its place: operation type, modes, routing rules, exclusions, and safety notes. It's front-loaded with the [Read] tag and purpose. Slightly heavy as one block, but information density-to-length ratio is high and there is zero filler.

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, return values need no explanation. The description covers the core operational modes, exclusions, sibling routing, and safety posture. For a 9-parameter tool with a rich schema, this is reasonably complete; the only minor gap is that it doesn't spell out behavior when query is empty with no coin, but the schema notes 'both empty is invalid'.

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 description coverage is 100%, so the schema carries the burden of documenting all 9 parameters. The description complements by explaining the query/coin interaction modes but doesn't detail individual parameter syntax; that's left to a fully-covered schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb (search) and resource (UGC: Reddit/Discord/Telegram/YouTube-style). It distinguishes itself from siblings explicitly: 'X/Twitter narrative -> search_x; headlines -> search_news', making the boundary clear without needing to open other schemas. The [Read] prefix reinforces the operation type.

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?

Exceptionally explicit. It describes the two operational modes ('non-empty query uses vector API; coin without query uses OpenSearch'), states invalid states ('Both empty invalid'), and gives routing guidance to alternatives ('search_x', 'search_news', 'get_latest_events'). No ambiguity about when or 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.

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds critical behavioral context beyond these: it clarifies the tool accesses public research data only, does not involve account access or trading, and explicitly disclaims investment advice. This goes beyond the annotations and sets clear expectations for the agent.

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 (about 4 sentences), front-loads the core purpose, and then efficiently lists alternatives and safety constraints. Every sentence earns its place without redundancy or fluff, making it easy for an agent to parse quickly.

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 tool with 9 optional parameters, an output schema, and rich annotations, the description is complete. It clearly states what the tool does, its scope, its exclusions, and how it differs from siblings. The output schema covers return values, and the annotations cover safety/read-only aspects, so nothing essential is missing for correct 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 description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description adds minimal parameter-level meaning—it mentions the query is 'for a topic' and aggregates sentiment, but these are largely redundant with the schema's own parameter descriptions. Baseline 3 is appropriate when the schema carries the burden.

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 states a specific verb ('Search and analyze') with a clear resource (X/Twitter discussions) and scope ('for a topic, with tweet-level evidence and cited posts'). It distinguishes itself from siblings by explicitly naming get_social_sentiment, web_search, and search_ugc as alternatives for different needs, leaving no ambiguity about what this tool does.

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 when-to-use vs. when-not-to-use guidance: it directs aggregate sentiment tasks to get_social_sentiment, open-web pages to web_search, and multi-platform search to search_ugc. It also states the tool's limitations ('Read-only public research data. No account access, no order placement or fund transfers'), giving the agent clear decision criteria.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds extra context beyond annotations: 'No account access, no order placement or fund transfers. Not investment advice.' This goes beyond generic read-only declarations. However, it doesn't mention rate limits or authentication details, but given the strong annotation coverage, a 4 is appropriate.

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 (plus the [Read] prefix) and front-loads the primary purpose. Every sentence serves a purpose: first states what it does, second routes to alternatives and adds constraints. 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 an output schema present, the description doesn't need to explain return values. All 6 parameters are documented with useful details. Usage guidance, exclusions, and safety disclaimers are covered. Nothing an agent needs to call the tool correctly is missing.

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 descriptions for each parameter. The descriptions add meaning beyond the schema by disambiguating from siblings (e.g., coin: 'not platform news index tickers (search_news)'). The description itself also reinforces the synthesized-answer behavior. This exceeds the baseline 3 for full coverage.

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?

States a specific verb and resource: 'Search the open web and return a synthesized answer with cited external pages.' It also explicitly distinguishes from siblings by pointing to search_news and search_x for alternative use cases. An agent can clearly identify what this tool does without opening the schema.

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?

Gives explicit when-to-use guidance: 'Built-in headline lookup, news-item search, or briefing-style news list -> search_news. X/Twitter-only discussion or tweet evidence -> search_x.' Also includes context like 'Read-only public research data' and disclaimers about account access and investment advice, providing clear boundaries.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety. The description adds further context: it is public research data, involves no account access, order placement, or fund transfers, and explicitly states 'Not investment advice'. It also discloses conditional behavior (daily_ranking only when rank index configured) and that include_orderbook_summary is ignored. This goes beyond the annotation set but doesn't fully exhaust every behavioral nuance given the rich 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 compact single paragraph that front-loads the core purpose before listing outputs and caveats. Every sentence adds distinct information: primary resource, window behavior, return fields, depth disclaimers, discovery path, deprecations, and legal disclaimers. It is efficient but slightly dense, reading more like a specification than a prose explanation, which slightly reduces readability.

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 an output schema exists, the description appropriately skips return-type details. It covers all non-schema context: the window options, default behavior for include_markets, the null depth_summary and the proper alternative, the conditional daily_ranking, the discovery route for event_ref, the deprecated parameter, and the read-only/public nature. Nothing essential for calling this tool correctly is missing.

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 description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema: it clarifies the event_ref format (split on first colon), specifies the window allowed values, states the default for include_markets, and notes that include_orderbook_summary is deprecated/ignored. This extra explanation enhances parameter understanding without redundancy.

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 explicitly states the tool reads a single event signal from a specific table (dws_external_event_signal_hf) keyed by event_ref in the format venue:venue_event_id. It lists the primary output fields and explicitly contrasts with get_market_orderbook for depth and search_events for discovery, distinguishing it from all sibling tools.

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?

Clear guidance is provided: when to discover event_ref via search_events and when to use get_market_orderbook for live depth instead of this tool (since depth_summary is always null). It also notes that include_orderbook_summary is ignored, steering agents away from a parameter that won't affect behavior.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses important behavior: rows missing open_mid_probability_utc or probability_delta_today are dropped, predictionRankIndex is required, and the tool is public research data with no account access or trading capabilities. This gives the agent concrete expectations beyond safety flags.

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 compact and front-loaded with the core '[Read]' purpose and ranking metric. Every sentence contributes distinct value: filter semantics, row-dropping behavior, prerequisite index, read-only nature, and disclaimer. No filler or redundant restatement of the schema.

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 read-only ranking tool with optional parameters and an output schema, the description is complete: it states the prerequisite index, data filtering behavior, scope of access, and the ranking basis. The output schema covers return values, so no additional output explanation is needed.

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 description coverage is 100%, so the structured schema already documents all five parameters. The description adds only a reference that filters match volume_delta ranking and a UTC date context, which is useful but not necessary to disambiguate the parameters.

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 identifies the tool as returning a daily ranking sorted by probability rise, with optional venue/category/status filters. It distinguishes itself from the sibling volume_delta_ranking by naming the sorting metric and explicitly referencing that sibling for filter semantics.

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 by stating the ranking is by probability rise and noting that optional filters are the same as volume_delta ranking. However, it does not explicitly state when to choose this tool over alternatives or provide exclusions, leaving the agent to infer when it is the appropriate choice.

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

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description goes beyond by adding operational requirements: 'Requires opensearch.predictionRankIndex', and disclaimers: 'No account access, no order placement or fund transfers. Not investment advice.' These are valuable behavioral disclosures not present in 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, dense paragraph that front-loads the core purpose and then lists filters, requirements, and caveats. It is concise and structured, with no redundant filler. Every sentence adds useful operational or behavioral context.

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 has 5 optional parameters, an output schema, and annotations covering safety, the description is complete enough for an agent to call it correctly. It covers the ranking basis, filters, the required index, read-only nature, and important disclaimers. It does not explain output format, but the output schema exists and covers that.

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 covers 100% of parameters with descriptions, including defaults and allowed values. The description restates some like 'category (exact term on rank index)' and 'status (active/closed/resolved/all; default active)' but adds no new information beyond the schema. Baseline 3 is appropriate since schema handles the burden.

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 states a clear purpose: 'Daily venue/overall ranking by volume delta (UTC rank_date)'. It identifies the resource (ranking data) and the dimension (volume delta). It is specific enough to distinguish from generic ranking tools, though it does not explicitly name alternatives among siblings like 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 provides context: it is read-only research data, requires opensearch.predictionRankIndex, and involves no account access or transactions. However, it does not explicitly state when to use this tool versus alternatives, nor does it name sibling tools or exclusions. The usage is implied by 'Read-only public research data' but not directly compared.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description goes further by explicitly stating 'Read-only public research data. No account access, no order placement or fund transfers.' It also discloses data freshness (hourly UNIQUE part_hour+venue+venue_event_id), collapse on venue_event_id, and the unsupported_filter nuance for coin-only, all of which add behavioral context beyond annotations. No contradictions present.

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 dense but well-organized, front-loading the core action and data source, then systematically covering filters, sort behaviors, and special cases. Each clause adds necessary context, though the long single paragraph could be slightly more scannable with bullet points. Still, no sentence is wasted and the structure is logical.

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 tool with 9 optional parameters, no required fields, and an output schema, the description covers every parameter's behavior, edge cases (coin-only unsupported, category empty exclusion), and related tool pointers. It also states account access limitations and non-investment-advice disclaimer, making it complete for an agent to invoke correctly without additional lookups.

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 the description adds significant semantic value: it clarifies that coin expands text recall only and cannot be used alone, defines allowed venue values (polymarket, predict_fun), explains sort semantics (volume_delta_today has no volume_delta column), and specifies how category matches two fields while excluding empty event_category_primary. These details go well beyond what the schema states.

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 opens with '[Read] Search prediction events on opensearch.predictionEventSignalIndex', clearly specifying the verb, resource, and data source. It distinguishes this tool from sibling news-feed search tools by focusing on prediction events, and it names the sibling endpoints for detail and orderbook ('Detail -> get_event_signal; orderbook -> get_market_orderbook'), making the scope 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?

The description provides explicit usage constraints: all query/coin/category are optional, but coin-only is an unsupported_filter. It also explains mapping nuances for sort keys (e.g., recently_listed uses create_time instead of a dedicated column, volume_delta_today maps to total_volume_usd_24h). It offers clear routing alternatives for related needs, giving an agent full context on when to use this tool versus others.

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