mkts Market Data

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

Annotations already carry readOnly, idempotent, non-destructive, and open-world. Beyond them, the description discloses a non-obvious behavioral trait: all symbols are read from one normalized snapshot, so results are internally consistent rather than fetched independently. It also signals that symbols may be only partially resolved (requested vs resolved), which is important for interpreting missing data.

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 the countable 2-10 scope and the snapshot-consistency point. Slightly compressed jargon ('mkts snapshot', 'provenance metadata') costs a little readability without bloating length.

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 one-parameter, read-only, non-destructive tool with annotations covering the safety profile, the description supplies what an agent needs: input range, snapshot semantics, and a rough idea of the return payload. With no output schema present, the return contract is only sketched rather than specified, which is the only real 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% and the single 'symbols' parameter is already documented with examples and min/max bounds, so the schema does the heavy lifting. The description reinforces the 2-10 constraint and hints at symbol resolution ('requested and resolved'), but adds no syntax or format detail 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?

Names a specific verb (compare) and resource (market symbols) with an explicit cardinality bound (2 to 10) and a consistency guarantee (same normalized snapshot). It does not name a sibling it is *not*, so an agent must still infer its distinction from get_market_snapshot or get_assets_bulk.

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?

Usage is implied by the verb 'compare' and the 2-10 range: use it when you need multiple symbols side by side. There is no explicit when/when-not statement and no pointer to get_market_snapshot or get_assets_bulk as the single-symbol or bulk 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?

While annotations cover safety hints (readOnly), the description adds rich behavioral details, such as specifying that 'a later restatement stays visible rather than replacing the original' and that 'Days the market was shut are absent, not zero-filled.' This context is vital for data interpretation.

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?

Although dense, the description is highly efficient. Each sentence serves a distinct purpose: defining the source, stating the value proposition, differentiating from siblings, explaining data integrity, and listing hard limits.

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 being a high-volume, archival, bulk-data retrieval tool, the description is maximally complete. It covers data integrity, performance implications relative to siblings, and hard constraints (366 days / 10k limit).

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, the baseline is high. The description adds semantic value by explaining how the parameters lead to a high-density, aggregated output format rather than a one-to-one retrieval, which helps the agent understand the resultant data structure.

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 defines the tool's purpose as retrieving daily closes from an immutable archive. Crucially, it distinguishes itself by specifying it provides 'N symbols by M days in one call,' setting it apart from tools that require one call per holding.

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 provides an ideal use case ('shape a portfolio backtest actually needs') and explicitly defines when *not* to use it by referencing alternative sibling tools that would require multiple, inefficient calls.

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?

Goes well past the read-only/idempotent annotations: it discloses that cadence is non-uniform (roughly 15 minutes since March 2026, sparser before), that the response reports observedIntervalMinutes which must be read before treating data as fixed bars, and that intraday history is tier-gated. This is exactly the kind of caveat that prevents misanalysis.

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 purpose, then alternatives, then caveats, then limits – a logical order with no filler. It is fairly dense at five sentences, but each sentence carries distinct information (cadence warning, bucketing, window cap, tier note).

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 no output schema, the description compensates by naming the key response field (observedIntervalMinutes) and describing bucket behavior. Minor gaps remain: no mention of the response envelope (e.g., observation array shape or pagination/truncation behavior on long windows).

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 value beyond it: the 92-day maximum window, tier-dependent reach-back, and the semantics of interval bucketing ('keeping the last observation in each bucket'). It does not cover type or the from/to defaults, which remain schema-only.

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 the specific verb and resource ('Get every price observation mkts made of one symbol inside a time window') and immediately contrasts it with the daily-close alternative, so an agent can distinguish it from get_asset_series and get_price_history without opening a 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 names the three usage cases (intraday movement, timing questions, session behavior) and routes the daily-close-over-months case to get_asset_series by name. That is a clear when-to-use plus a named alternative.

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 cover read-only, idempotent, non-destructive behavior, and the description adds important operational context: the data comes from a snapshot refreshed about every 15 minutes, includes 'when it was last observed', and should not be used when latest intraday detail is required.

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 the core purpose and return contents, followed by source freshness and sibling routing. Although dense, every sentence contributes decision-relevant information without restating annotations or schema details.

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, but the description lists the key returned fields and explains the snapshot freshness model. Combined with a fully documented input schema and safety annotations, it gives enough information to invoke and interpret the tool 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%, and the schema already explains the symbol format and the optional type enum behavior. The description only says the lookup is 'by symbol', so it adds little parameter-level 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 and resource: 'Look up one asset by symbol' and enumerates the profile fields returned. It clearly distinguishes a profile/snapshot lookup from a quote, intraday, or bulk lookup.

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 identifies this as the default for 'what is X' or 'how is X doing' and names the alternatives: get_asset_quote for latest/intraday detail and get_assets_bulk for several symbols. This gives clear 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 readOnly, idempotent, open-world, and non-destructive, so the safety profile is covered. The description adds genuinely new context — that results carry an observation timestamp, market state when available, and an upstream source — which warns the agent about quote staleness and provenance, but says nothing about failure modes for unknown symbols or rate limits.

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 tight sentences, front-loaded with the capability and followed by the return shape. No filler, though the asset-class enumeration is slightly redundant with the enum.

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 no output schema, the description usefully enumerates the return fields (price fields, market state, timestamp, source), which is real value. The remaining gap is routing: a 14-sibling toolset where several tools return price-like data, and the description never says when this one is correct.

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's enum explanation for `type` (auto picks the larger-by-market-cap asset) is far richer than anything in the description. The description's list of asset classes merely repeats the enum values, and it adds nothing about symbol format (ticker vs coin ID vs forex pair) 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?

States a specific verb (get) and resource (current quote) plus the asset classes it covers, so the operation is unambiguous. It does not distinguish itself from siblings like get_asset_intraday, get_price_history, or get_market_snapshot, so an agent can't tell from the description alone which of these is the right snapshot call.

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?

"Current quote" implies a point-in-time read rather than a series, which is the main selection signal versus get_price_history. However, there is no explicit when-to-use/when-not guidance, no mention of the intraday or bulk alternatives, and no prerequisites or rate/cost notes.

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 readOnly/idempotent/non-destructive, but the description adds real behavioral context beyond them: revisions recorded after the requested date are excluded (no hindsight leakage), and isExactDate=false signals the market was closed and the most recent earlier observation was substituted. That is exactly the kind of non-obvious behavior an agent cannot infer from 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?

Front-loaded with the core action, then the alternatives, then the caveats — a good ordering with no filler. Minor waste in restating the 100-symbol cap that the schema already enforces via maxItems.

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 carries the burden of explaining return semantics — and it does, via the isExactDate explanation and the revision-exclusion rule. For a two-parameter read tool, nothing an agent needs 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 date format and symbol array bounds are already documented. The description's 'single symbol or up to 100' restates minItems/maxItems rather than adding syntax or format guidance, so the baseline of 3 applies; the isExactDate note describes a return value, not a parameter.

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 what mkts recorded about one or more symbols on a specific past date') plus the source ('immutable point-in-time archive'). It explicitly contrasts with the sibling get_assets_bulk, which serves current prices, so an agent can choose without opening either 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 concrete when-to-use cases (backtesting, reconstructing a past decision, checking whether a figure was revised) and an explicit when-not ('not for current prices, which get_assets_bulk serves'). The alternative is named along with the condition that selects it.

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds real value on top: a hard 100-symbol cap, rate-limit pressure, and the guarantee that unknown symbols surface in unresolvedSymbols rather than being dropped. It stops short of describing what 'current data' actually contains per asset, which matters since there is no 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?

Three sentences, no filler, and the scope ('up to 100 symbols in a single call') is front-loaded before the routing advice and the return-value caveat. Every sentence carries a distinct piece of 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?

For a one-parameter batch read with annotations and no output schema, this is nearly complete: limits, alternative, and the unresolvedSymbols escape hatch are all covered. The remaining gap is the payload shape of the 'resolved assets' — an agent cannot tell whether it gets quotes, profiles, or full series, which the lack of an output schema makes the description's responsibility.

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 already documents the array, the 100-item cap and the ticker format, so the baseline is 3. The description adds the non-obvious constraint that the list must be 'explicit' (no patterns or ranges) and that unknown entries are reported back rather than erroring, which changes how an agent should build the input.

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 current data for an explicit list of ... symbols') plus the batch scope ('in a single call', 'up to 100'). It explicitly names the sibling it replaces (get_asset_quote) and the contrast with a per-symbol loop, so an agent can distinguish it without opening any 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?

Explicit routing guidance: 'Use this instead of calling get_asset_quote repeatedly', with the reason (rate-limit exhaustion). The word 'current' also signals the boundary against the historical sibling get_assets_as_of, though that exclusion is left implicit.

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?

The description goes far beyond basic behavior by detailing data quality constraints and structural quirks. It explains that later restatements are visible instead of silently replacing originals, and that market closure days are absent rather than zero-filled.

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 definition is comprehensive, packing a vast amount of highly valuable technical context into one block. Although slightly lengthy, the information density is extremely high, making the structure highly effective despite not being 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?

Given the complexity of time-series data and the absence of an output schema, the description is maximally complete. It covers the source type, the nature of the data (immutable/restatable), the practical limit (366 days), and the intended use.

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%, setting the baseline at 3. The description focuses heavily on output behavior and use cases, adding no significant semantic meaning to the input parameters beyond what the schema already defines.

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 function ('Get what mkts recorded for one symbol on every day in a date range') and immediately distinguishes the data source ('immutable point-in-time archive'). It effectively differentiates itself from siblings like get_price_history.

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 provides explicit guidance on the optimal use case ('Use this for backtesting rather than calling get_assets_as_of once per day'), directly contrasting its utility against a known alternative sibling.

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 establish that this is a safe, read-only, idempotent, open-world operation. The description adds useful behavioral context beyond annotations: results are newest first, include specific fields and links, exclude insider-ownership forms, and flag shared fund filers with sharedFiler.

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 and efficient: purpose first, then return contents, use cases, exclusions, and a fund-specific caveat. Each sentence contributes actionable information without repetition.

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 three-parameter read-only filings lookup with no output schema, the description explains what is returned, ordering, exclusions, and a non-obvious fund-trust behavior. Together with annotations and a fully documented schema, an agent has enough context to call 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 input schema already documents symbol, type, and limit thoroughly, including examples and the 'omit for all types' behavior. The description adds little parameter-level meaning beyond what the schema provides, making the baseline score 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 and resource: list recent SEC filings for a US-listed company or fund from SEC EDGAR. It distinguishes the tool from sibling market-data tools by focusing on regulatory filings and gives concrete examples such as 10-K, 10-Q, and 8-K.

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 clearly says to use this tool to find the latest 10-K, 10-Q, or 8-K, or to see recent filings, and explicitly excludes insider-ownership forms 3, 4, 5, and 144. It does not name a sibling alternative, but there is no obvious competing filing tool in the provided sibling list.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds a modest behavioral note that module selection shrinks the response, but says nothing about data latency, coverage depth, history length, or auth/quota constraints for an open-world external data call.

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, no filler, purpose front-loaded ahead of payload nuance. Slightly redundant with the schema's module description, which keeps it from a 5.

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 no output schema, the description is the only place return characteristics could be explained, and it only says 'time series' and 'payload' sizes. For a 3-parameter open-world data tool an agent would benefit from knowing the shape/units/history depth of the series, which is left unstated.

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 both enums are self-documenting, so the schema already carries parameter meaning. The description restates period options ('annual or quarterly') and module payload trade-offs without adding semantics such as default behavior interactions or what 'all' returns when a statement is unavailable.

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 financial-statement time series) plus the asset scope (stock or ETF) and period granularity. It implicitly separates itself from quote/price/profile siblings by naming financial statements, but never names an adjacent tool such as get_asset_profile or get_filings to make the boundary explicit.

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?

Usage is only implied: an agent can infer this is the tool for statement data, but there is no when-to-use/when-not guidance and no routing to alternatives like get_asset_profile for descriptive facts. The payload-size advice ('choose one module for a smaller response') is useful context but lives in the schema, not the description.

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 openWorldHint, so safety is covered. The description adds value by disclosing the scope of returned content (the specific macro categories), which matters because there is no output schema; it does not mention freshness or snapshot timing, which keeps it from 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?

A single front-loaded sentence with no filler, and the enumerated content list is the useful part of the definition. Nothing repeated or redundant.

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-parameter read tool with no output schema, the description tells the agent roughly what will come back, which is the main missing piece. It could go further on format or recency, but nothing essential for calling it correctly is absent.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter guidance is needed.

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 current mkts macro dashboard') and enumerates the content categories (equity proxies, crypto, commodities, dollar, volatility, 10-year yield). It is clear what the tool returns, though it does not explicitly differentiate itself from the sibling get_market_snapshot.

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?

Usage is only implied by the 'macro dashboard' framing; there is no explicit statement of when to use this versus get_market_snapshot or get_asset_quote. An agent can infer it is a broad overview call, but the definition leaves the routing decision to 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?

Annotations already carry the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower. The description adds genuine value by listing the returned aggregates and calling out the 'underlying snapshot timestamp', which matters because there is no output schema. It stops short of stating data freshness or rate limits.

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 sentence, front-loaded with the verb and scope, with the returned fields as a compact list. Nothing is redundant with the title beyond the necessary scope word.

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 no-param, no-output-schema tool, the description covers both what is fetched and what comes back, which is the main gap an agent faces. It omits freshness/update cadence and any hint on when the global view should precede per-asset calls.

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?

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The enumeration of what the snapshot contains compensates for the empty 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?

Specific verb (get) plus a well-scoped resource: current global cryptocurrency market aggregates, with the returned metrics enumerated. The word 'cryptocurrency' implicitly separates it from get_macro_snapshot, but the description never names that sibling, so an agent must infer the boundary.

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?

No explicit when-to-use, when-not-to-use, or alternative is given. For a zero-parameter global-overview tool the intended usage (market-wide context versus per-asset calls like get_asset_quote) is strongly implied but left to 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?

The annotations already establish that this is a safe, read-only, idempotent, open-world operation. The description adds useful context by saying news comes from configured source feeds and that results include source and publication links. It still does not disclose freshness windows, rate limits, ordering beyond what the schema provides, or behavior when no results are found.

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 compact sentences with no wasted language. The core purpose is front-loaded, followed immediately by filtering scope and return 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?

For a simple read-only news retrieval tool with full parameter schema coverage and safety annotations, the description is nearly complete. It notes the configured-source behavior and returned links, though without an output schema it could say slightly more about headline fields or ordering. The remaining gaps are minor.

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 three parameters, including the limit maximum and the fact that symbol overrides category. The description restates the available filtering modes but does not add syntax, format, or interaction details beyond the 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?

The description clearly states a specific verb and resource: get recent market news from configured source feeds. It also scopes the tool with symbol and category filters. It does not explicitly distinguish itself from nearby sibling tools such as get_filings, so it falls just short of a 5.

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 how to filter by symbol or category, which implies the tool's usage context. However, it gives no explicit when-to-use guidance, no exclusions, and no comparison to sibling tools. It is adequate but relies on the reader to infer its place among the other market-data tools.

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 read-only, idempotent, non-destructive, open-world access, so safety is covered. The description adds real behavioral context by warning that coverage varies by asset class (stocks/ETFs include OHLCV, crypto may only have close and volume) and that history is range-bounded — important for an agent interpreting results.

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 short sentences with zero filler; purpose is front-loaded and the asset-class caveat follows immediately. Every clause conveys information an agent can act on.

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 only two simple parameters, full schema coverage, and annotations covering safety, the description needs chiefly to explain what comes back — which it does at a high level, absent an output schema. It stops short of stating units, adjustment basis (split/dividend), or ordering, but nothing required for correct invocation 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% with a documented enum for range and an example-bearing symbol description, so the schema carries parameter meaning. The description's 'bounded' echoes rather than extends the range semantics, and adds nothing on symbol formats beyond what the schema already shows.

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 ... daily price history for a symbol') and adds a scope qualifier ('bounded'). The 'daily' vs intraday distinction implicitly separates it from get_asset_intraday, but it does not name or differentiate against get_asset_series, which likely overlaps most closely.

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?

Usage is only implied: 'daily' points agents to this tool rather than the intraday sibling, and the range enum defines the bounded window. There is no explicit when-to-use/when-not guidance or named alternative such as get_asset_series for longer histories.

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 readOnly/idempotent/non-destructive, so the bar is lower. The description adds genuinely new context beyond them: data comes from a snapshot refreshing roughly every 15 minutes (freshness caveat) and results are capped at 25 assets, which matters for result interpretation.

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 sentences, front-loaded with the capability, then examples, then constraints and the hand-off to get_fundamentals. No filler and no repetition of schema enums.

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 an 11-parameter screening tool with no output schema, the description covers scope, freshness, result cap, filter semantics, and out-of-scope cases. Minor gap: it doesn't hint at what fields come back per asset (price, change, volume, market cap), leaving the agent to infer the return shape.

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 cross-parameter semantics the schema cannot express — that all filters are AND-combined and independently optional — plus the universe note that market-cap filters exclude forex and many ETFs, which helps the agent reason across 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?

States a specific verb (find) and resource (assets) plus the exact filter dimensions, sortability, and universe scope (stocks, ETFs, crypto, commodities, forex). The three example queries make the tool's role unmistakable versus siblings like get_fundamentals or get_asset_quote.

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 concrete use cases ("biggest movers today", "tech stocks over $1T", "cheapest crypto"), states all filters are optional and AND-combined, and explicitly excludes valuation screens like P/E by routing to get_fundamentals. Both when-to-use and when-not-to-use are covered with a named alternative.

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