Sell The News

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

With no annotations, the description carries the burden and does well: it discloses that omitting date auto-returns the latest available recap, that the recap synthesizes intraday buckets into one narrative, and how includeIntraday changes output. It does not mention auth, rate limits, or failure behavior when no recap exists, which keeps it short of a 5.

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?

Front-loaded with the core action, then usage triggers, then the behavioral fallback and the includeIntraday caveat. Every sentence contributes, though the middle sentence is dense and could be trimmed slightly without loss.

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?

No output schema exists, and the description compensates by describing what the recap is (synthesized market narrative) and what includeIntraday appends. Covers purpose, triggers, and parameter effects adequately; only edge cases like missing date data are unaddressed.

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, but the description adds real meaning beyond the schema: it explains the consequence of omitting date (auto-latest) and the specific condition under which includeIntraday should be set, going past the schema's neutral 'if true, append...' wording.

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 (get) and resource (precomputed AI daily news recap) and clearly distinguishes the daily recap from the intraday buckets it synthesizes, which separates it from get_intraday_news_recaps. An agent can identify the tool without opening its 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?

Names concrete triggering requests (daily market recap, today's/yesterday's AI news summary, end-of-day narrative, what mattered on a date) and explicitly gates includeIntraday to the 'how was it built / source headlines' case. The date-omission fallback is also spelled out, so usage requires no inference.

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?

With no annotations, the description carries the full burden and does well: it discloses read-only behavior, that it never triggers new AI analysis, the chronological ordering, and the automatic fallback to the latest date when no date or bucketId is supplied. It omits any auth or rate-limit context, so it is not exhaustive.

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?

Front-loaded with the core purpose before usage, behavior, returns, and safety. Sentences are logically ordered and each adds something, though the block is longer than strictly necessary with some overlap between the usage and behavior 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?

There is no output schema, yet the description compensates by enumerating the returned fields (bucket time window in US Eastern Time, source/news counts, headline, market narrative, affected tickers). Together with the default/ordering behavior, an agent has enough to call and interpret it 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 description coverage is 100%, so the schema already documents each parameter, including that date is ignored when bucketId is provided and the pagination bounds. The description restates the date/bucketId interaction and default-fallback behavior rather than adding new syntax or format meaning beyond the schema. Baseline 3 applies.

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 ('Get precomputed AI intraday news recap buckets') and the 'intraday' scope plus the AI-recap nature naturally distinguishes it from the daily, weekly, and list siblings. An agent can tell what it retrieves 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?

Explicitly enumerates when to use it ('intraday news analysis, same-day market narrative, what happened during the trading day, or a specific recap bucket') and references list_news_recaps as the source of bucketId values. It stops short of naming a concrete 'use X instead when...' alternative, so it is clear context rather than full routing.

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?

With no annotations, the description carries the full burden and does well: it discloses the return shape (pinned headlines plus cards with source, ET timestamp, title, full text, tickers), the offset=0 restriction on pinned items, and the default cross-source dedupe behavior with the 'Also reported by' field and its opt-out. It omits any note on auth, rate limits, or freshness/latency guarantees, which is the only real gap.

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, front-loaded with what is returned before the behavioral defaults and pagination note. Dense but every sentence carries information; only the long outlet parenthetical is mildly expendable.

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?

Nine parameters with no output schema means the description must explain the response, and it does so adequately (pinned headlines, card fields, dedupe folding, pagination cursor). Nothing critical to invoking it correctly is missing, though the tool's relationship to the many sibling news tools remains unaddressed.

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, but the description adds genuine meaning beyond the schema: it explains why clusterDedupe defaults to folding duplicates, that pinned headlines only appear at offset=0, and that 'before' should be taken from the previous response's last item. These are usage-level semantics the schema text alone does not fully convey.

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 ('Get the latest live financial news') and enumerates the covered outlets, so the agent knows exactly what it retrieves. It does not name or contrast any sibling (get_stock_news, search_news, get_daily_news_recap), so the boundary between this tool and the other news tools must be inferred from the word 'live'.

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 concrete usage triggers ('Use when the user wants the latest developments as they happen', 'Use when the user wants pure market news') and explains the pagination workflow with the 'before' cursor. It never states when to choose this over a sibling such as get_stock_news or search_news, so the guidance is contextual but not comparative.

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?

No annotations are provided, so the description carries the burden. It discloses the return payload well (key levels, per-strike Greek profiles, supported Greeks) and the net GEX/positioning computations, but says nothing about data freshness, source, auth/subscription requirements, or rate limits for a live market-data tool.

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?

Purpose is front-loaded in the first sentence, and the middle sentence is a dense but useful enumeration of payload contents; the Greek list and use-case sentence close it out. The parenthetical metric list is long, but each item is informative rather than 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 read-only data-fetch tool with no output schema and fully documented parameters, the description covers the returned fields and the analytical purpose adequately. The remaining gap is operational context (data freshness, quotas), which is minor for this tool type.

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 ticker, greeks, expiration, and maxStrikes (including the token/context tradeoff and the note that Key Levels are always included). The description only restates the supported Greek list, adding no syntax or format detail beyond the schema baseline.

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 ('Get') and resource ('options chain data and Greek exposure analysis for a stock ticker'), then enumerates exactly what the payload contains. Since the sibling set is entirely news/DD/WSB tools, there is no ambiguity to resolve; an agent can route to this tool unambiguously.

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 closing clause gives concrete use contexts (options market positioning, dealer hedging flows, support/resistance identification) with no competing sibling to distinguish from. It stops short of stating when NOT to use it or any prerequisites, so it is clear context rather than full when/when-not 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?

With no annotations, the description carries the burden and mostly succeeds: it discloses the default-to-latest behavior when no parameters are given, parameter precedence, ISO week id format, and the Monday–Sunday US Eastern coverage window. It omits auth/permission needs, error behavior for invalid or unavailable weeks, and return shape.

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?

Front-loaded with the core purpose, then ordered by decision-relevance: trigger conditions, week semantics, parameter precedence, and finally the optional includeDaily flag. Six sentences, each carrying a distinct invocation rule with no 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 zero-required-parameter lookup tool with no output schema and no annotations, the description covers selection logic thoroughly. The remaining gap is return-value expectations (recap structure/content, what happens for weeks with no data), which an agent cannot infer from the schema.

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 a 3 baseline applies, but the description adds operational meaning beyond the schema: the precedence chain (weekId > date > latest) and the conditional trigger for includeDaily ('only when the user asks for day-by-day inputs or daily source headlines'). The lang parameter is left entirely to 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?

States a specific verb and resource ('Get one precomputed AI weekly news recap') with clear scope ('one', 'precomputed', 'from the database'). The 'weekly' qualifier distinguishes it cleanly from sibling tools like get_daily_news_recap and get_intraday_news_recaps without needing to open their 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 enumerates triggering user intents (weekly market recap, this/last week's AI news summary, dominant market themes). It also resolves the three-branch ambiguity among weekId, date, and neither, and conditions includeDaily on a specific user ask — full when/when-not coverage.

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?

No annotations are provided, so the description carries the full burden. It discloses the non-obvious behavior that a single day can have multiple analysis runs and that posts are offset newest-first, which is genuinely helpful. However, it says nothing about read-only status, rate limits, data freshness, or what happens with out-of-range indices.

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, front-loaded with what the tool returns before moving to navigation hints, and no filler. Slightly padded by the comma-separated report-contents list, but every sentence carries information an agent can use.

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 3-optional-parameter tool with no output schema and full schema coverage, the description covers what is returned and the run/offset addressing model. It is close to complete, missing only guidance on sibling selection and failure behavior.

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% and the schema descriptions are already thorough (including the 'not a day count' clarification for offset), so the baseline is 3. The description restates the offset/run navigation without adding format or edge-case meaning beyond what the schema provides.

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 gives a specific verb (Get) and resource (AI-generated analysis report of r/wallstreetbets daily discussion threads), and the content list (sentiment, tickers, trades, mood, contrarian signals) makes it distinguishable from the raw-comment sibling get_wsb_discussion. It stops short of naming that sibling explicitly, so differentiation is inferred rather than stated.

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 sentence about 'offset' and 'run' explains how to navigate the report hierarchy, which is useful usage context, but there is no guidance on when to choose this tool over get_wsb_discussion or the news-recap siblings, and no conditions or exclusions are given.

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?

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it explains the output format, score refresh cadence, what happens to old threads without vote counts, filtering rules for bot comments and low/zero-score comments, and how replies are represented. This is unusually rich behavioral disclosure beyond what the schema provides.

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 front-loaded with purpose and output format, and the dense scoring/filtering details are relevant for interpreting results. It is somewhat long, but most sentences earn their place given the complexity of the return format.

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?

There is no output schema and no annotations, yet the description explains return values, line format, score semantics, threading, filtering behavior, and usage context in enough detail for an agent to call and interpret results correctly. Missing auth or rate-limit details are minor and not evident as required for this public data 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 description coverage is 100%, so both parameters are already documented in the schema. The description does not add syntax, format, or edge-case detail specifically about `date` or `limit`; 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?

The description states a specific verb and resource: getting raw Reddit comments from the r/wallstreetbets daily discussion thread, with top-level comments newest first. It implicitly distinguishes itself from analysis-oriented siblings by emphasizing raw comments, but it never names or directly contrasts with `get_wsb_analysis` or other siblings.

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 final sentence gives implied usage context (retail sentiment, popular tickers, trading ideas) but does not state when to use this tool versus alternatives or when not to use it. No explicit routing to siblings is provided.

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?

With no annotations provided, the description carries the behavioral burden and does well: it discloses that only lightweight metadata is returned, that full narratives are excluded, and that dates are US Eastern calendar dates with ISO YYYY-Www weeks. It does not explicitly state it is a safe read-only operation, but the discovery/metadata framing makes the non-mutating nature evident.

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?

Front-loads the purpose before usage and constraints, and nearly every clause earns its place. Slightly dense with the format details (Eastern dates, ISO weeks) packed at the end, but no 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?

No output schema exists, so the description must describe the return shape, and it does ('recap type, date or ISO week, and intraday bucket count'), plus it explains the handoff to detail tools. Nothing needed to call 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 level, limit, and offset are already fully documented in the schema with defaults and ranges. The description adds no parameter-specific syntax beyond what the schema provides, so baseline 3 applies.

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+resource ('Discover which precomputed AI news recaps are available') and clearly scopes it as a metadata-only discovery tool, distinguishing it from the get_* detail siblings named in the text.

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 enumerates triggering conditions ('asks what AI market recaps exist', 'asks for an unspecified historical recap', 'needs valid dates/weekIds before calling a detail tool') and routes to the three alternative detail tools by name with the exact key needed.

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?

With no annotations, the description carries the full burden. It does add genuine behavioral context beyond the schema: Meilisearch typo-tolerant matching and native-language result boosting. But it omits return shape, pagination behavior, and any auth or rate-limit notes for an 8-parameter search tool.

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?

Three front-loaded sentences: scope first, then engine behavior, then filter/sort options. Efficient overall, though the closing sentence partially duplicates what the schema already states about source filtering and sort order.

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 search tool with 8 parameters, no output schema, and no annotations, the description covers identity, engine semantics, filtering, and sorting adequately. Return-value details are not needed without an output schema, but the absence of any guidance on choosing among the many news siblings is a residual 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 description coverage is 100%, so every parameter including lang, sort, sources, aiSummary, and marketOnly is already documented in the schema. The description restates source filtering, sort order, and language ranking without adding syntax or edge-case meaning beyond what the schema provides, so the baseline of 3 applies.

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 (full-text search) and resource (news articles) and enumerates the exact sources covered, so the scope is unambiguous. However, it never differentiates itself from siblings like get_stock_news or get_live_news, leaving the agent to infer which news tool fits a given request.

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 mentions that results can be filtered by source and sorted by relevance or time, which hints at usage, but it never states when to choose this tool over get_stock_news, get_live_news, or the recap tools. Usage is implied rather than guided.

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