Stock Trends Market Intelligence

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the 'does not execute trades or manage assets' line largely restates structured data. The one genuinely additive signal is 'Purchase', hinting at a metered/cost-incurring call, but it is not explained (credits? budget?) and the non-idempotent hint is left unaddressed despite a comparison seemingly being deterministic.

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 no filler, and the core purpose leads. The phrasing 'Purchase the API's analytical comparison' is slightly awkward and buries the operation behind the billing framing.

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 should say what the comparison yields, but it is silent on return content. Combined with 0% param coverage and a two-nested-array signature, an agent lacks the information needed to construct a correct call.

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 0% and the description never names the two required parameters (left/right), their weight semantics, the 1-25 item bounds, or the symbol_exchange pattern. 'Two supplied portfolios' only faintly implies a two-argument shape, so the description fails to compensate for the absent schema documentation.

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 identifies the resource (analytical comparison of two portfolios) and a verb (compare matched by the name), but "Purchase the API's..." is an odd framing that makes it unclear whether this is a paid metered operation. It gives no differentiation from the close sibling stocktrends_evaluate_portfolio, which also analyzes a portfolio.

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?

There is no guidance on when to choose this over stocktrends_evaluate_portfolio, construct_portfolio, or evaluate_symbol, and no stated preconditions such as needing resolved instruments or valid symbol_exchange formats. The only contextual claim is a negative ('does not execute trades or manage assets'), which is a boundary, not usage 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=true and destructiveHint=false, so safety is covered. The description adds relevant behavioral context — that the output is an API-authored, equal-weight proposal and that no trades/assets are touched — plus an implicit cost/metering trait via 'Purchase.' However, it does not explain what 'purchase' consumes (credits? quota?) or whether calls are billable, leaving the most consequential trait underexplained.

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 core action and a scope disclaimer; little waste. The scope disclaimer is well placed, though the leading verb choice is imprecise.

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 4 undocumented parameters, no output schema, and no parameter guidance, the description is too thin. An agent cannot tell what bias/count/exchange do or what the returned proposal looks like, so it is not complete enough to invoke confidently.

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 0% for 4 parameters (bias, count, exchange, universe), so the description must carry the full explanatory burden. It only alludes to 'equal-weight' and never mentions bias, count, exchange, or the 'top' universe constraint, so it fails to compensate for the coverage gap.

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 and resource: it produces an 'equal-weight analytical allocation proposal,' which an agent can distinguish from the evaluate_/compare_portfolios siblings that analyze rather than construct. The verb 'Purchase' is a bit confusing and inconsistent with the title's 'Construct,' but the resource and output type are clear.

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?

There is no positive when-to-use guidance and no named alternative, despite several closely related siblings (evaluate_portfolio, compare_portfolios). The only usage-like statement is a negative: 'It does not execute trades or manage assets,' which clarifies scope but does not say when to prefer 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 readOnly/idempotent/non-destructive, but the description adds non-obvious context: this call does not authorize payment or any paid execution path, which is critical for an agent deciding whether a budget gate has been cleared. It stops short of describing the response shape or whether the estimate is illustrative vs. binding.

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, both front-loaded with the capability followed by the restriction. No filler and no restatement of the tool name or 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 planning tool with no output schema, the description covers what it does, its scope boundary, and the payment-related guarantee. It does not clarify that the returned estimate is planning-only/non-binding, which would fully close the loop.

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 five parameters including the two enums are already documented in the schema. The description adds no syntax, default, or interpretation detail beyond that, so the 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?

Names a specific verb ('Estimate ... Cost'), the exact resource (workflow-level budgeting via GET /v1/cost-estimate), and the scope limit ('planning tool ... for workflow-level budgeting only'). No sibling tool performs cost estimation, so the agent can place it immediately.

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 scopes usage ('for workflow-level budgeting only') and lists what it is not for (paid execution, payment, x402, wallet use, paid endpoint calls). No alternative tool is named, but none of the siblings competes for this purpose, so the gap is minimal.

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, destructiveHint=false and openWorldHint=false, so the safe read-only profile is covered by structured data. The description's 'does not execute trades or manage assets' largely restates that, and the word 'Purchase' hints at possible credit/cost consumption but is never clarified. It adds little 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?

Two short sentences with no filler, and the primary claim leads. It is arguably over-compressed rather than concise given how much the tool leaves unspecified, but structurally it is clean and front-loaded.

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 and zero parameter documentation, the description should describe what the assessment returns and how positions/weights are interpreted. Instead it covers only a negative scope statement, leaving the agent unable to predict results or input semantics for a credit-consuming evaluation call.

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?

There is one parameter with 0% schema description coverage: the nested 'positions' array (symbol_exchange pattern, weight, 1-25 items) is undocumented in prose. The description explains nothing about how weights are interpreted (relative? summing to 1?) or the symbol_exchange format, so it fails to compensate for the coverage gap.

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 names an action (obtaining an analytical assessment) on a clear resource (the supplied positions), and the title reinforces portfolio evaluation. It does not distinguish itself from close siblings like stocktrends_evaluate_symbol, stocktrends_compare_portfolios or stocktrends_construct_portfolio, so an agent must infer the boundary. The verb 'Purchase' is also an indirect way of saying 'evaluate'.

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 only usage signal is implicit: 'It does not execute trades or manage assets' tells the agent this is not a trade-execution tool. There is no statement of when to select this over evaluate_symbol / compare_portfolios / construct_portfolio, no prerequisites, and no exclusions. Context is left entirely 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 establish readOnly, non-destructive, non-open-world, and non-idempotent behavior, so the safety profile is covered. The description's one genuinely additive disclosure is 'Purchase', implying the call consumes credits/quota — a real behavioral trait not expressed in annotations and consistent with idempotentHint=false. However, it says nothing about cost magnitude, caching, rate limits, or failure modes when the symbol is unknown, so the disclosure is useful but shallow.

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 with the action front-loaded ('Purchase API-authored analytical decision context for one instrument'), no filler. It is efficient, though the brevity is partly a symptom of under-specification rather than discipline.

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, 0% parameter descriptions, and no return-value explanation, the description should carry much more load for a 3-parameter analytical tool. It does not say what comes back, how a decision context is shaped, or how to supply the instrument identifier — all critical 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 0% and the description compensates almost nothing: 'one instrument' gestures at the symbol parameter but never explains the relationship between symbol, exchange, and symbol_exchange, nor that all three are optional (required: 0) with likely mutual exclusivity. An agent cannot tell from the description whether to pass symbol_exchange or symbol+exchange.

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 resource ('one instrument') and the general output class ('analytical decision context'), but that phrase is opaque jargon — it doesn't say whether the result is a rating, a signal, or indicator aggregates. It also fails to distinguish this tool from near-siblings like evaluate_portfolio, get_stim_latest, or get_indicators_latest, which an agent must choose between.

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 only guidance is a liability disclaimer ('not investment advice or a trade instruction'), which is framing rather than selection criteria. There is no statement of when to call this instead of evaluate_portfolio, get_selections_latest, or the indicator-history tools, and no prerequisite (e.g., resolving the instrument first via resolve_instrument).

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, non-destructive, non-idempotent, closed-world), so the bar is lower, and the description adds a genuinely non-obvious auth/cost trait: invocation requires an x402 payment authorization. It also discloses that the snapshot is 'API-authored' (server-computed). It omits cost magnitude, pagination, and failure behavior when payment is absent.

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, with the action ('Purchase the API-authored sector breadth snapshot') front-loaded before the disclaimer. It is tight, though 'API-authored' is jargon and the closing disclaimer is boilerplate that consumes a full sentence.

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 seven-parameter tool with no output schema and zero schema description coverage, the description leaves too much unsaid: it never defines what 'sector breadth' contains, how group_level/exchange filter the result, or what the snapshot returns. The payment disclosure is the only substantive addition.

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 0% across seven parameters and the description says nothing about any of them. A few names (limit, min_price, min_volume, exchange) are self-descriptive enough to infer, but cs_only, include_unknown, and group_level (enum) are opaque, so the description fails to compensate for the coverage gap.

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 resource ('sector breadth snapshot') tied to a clear retrieval verb, and the tool name reinforces 'latest'. It stops short of differentiating from siblings like stocktrends_get_leadership_summary_latest or stocktrends_get_market_regime_latest, so it is clear but not disambiguating.

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?

There is no when-to-use guidance, no prerequisites, and no named alternative among the many sibling tools. 'Breadth is participation context, not a trading recommendation' is an interpretation caveat, not invocation 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, non-destructive, closed-world, non-idempotent behavior, so the bar is lower. The description adds one genuinely useful trait annotations do not carry: that access requires an x402 payment authorization. However, it gives no cost, credit, rate-limit, or pagination detail, and 'Purchase' sits in tension with readOnlyHint=true (payment vs. pure read).

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 is appropriately sized and front-loaded, so there is no padding to trim. But the one sentence is dense with undefined jargon ('bounded API-authored') and wastes its budget on a mislabeled resource instead of the parameters the agent needs.

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 five-parameter tool with no output schema and no annotation coverage of returns, the description omits return shape, pagination/limit behavior, date-range semantics, and any cost figure. Too much an agent needs in order 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 0% across five parameters and there are no enums, so the description must carry the burden. It says nothing about symbol_exchange format, the start/end date semantics, the 260-default limit, or the cs_only flag. 'Bounded' is the only vague gesture toward the limit parameter and is not enough.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'Purchase' and resource 'instrument classification history,' but the tool name and title say 'indicators history.' That mismatch means an agent cannot tell whether this returns indicators or classifications. The verb also conflicts with the GET-style name, so the purpose is muddled rather than specific.

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?

There is no statement of when to use this instead of the obvious sibling stocktrends_get_indicators_latest, nor any prerequisite/precondition beyond the implicit payment. The agent is left to infer that 'history' contrasts with 'latest' on its own.

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, destructiveHint=false, and idempotentHint=false, covering the safety profile. The description usefully adds that this is a paid call requiring an x402 payment authorization, which is meaningful context the annotations do not convey. However, it omits cost, how the payment authorization is supplied, and why the non-idempotent hint matters.

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 tight sentence with no filler, and the key mechanic (payment authorization) is placed up front in the supplementary clause. It is not padded, though it is arguably too short given the schema gaps.

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, so the description should carry more of the return-value and payment burden. Instead it mentions an x402 payment authorization without explaining how that authorization is passed or what the paid call returns, and the 0%-covered parameters are undocumented — significant gaps for a paid, non-idempotent endpoint.

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 0% for both parameters. The description never mentions symbol_exchange or cs_only, nor the required exchange-suffix format encoded in the schema regex. 'Instrument classification' only loosely hints at the symbol parameter and leaves cs_only entirely unexplained.

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 names a verb (purchase) and a resource (API-authored instrument classification), but the resource ('classification') does not match the tool name/title ('indicators'), leaving ambiguity about what is actually returned. It also does not differentiate itself from the sibling stocktrends_get_indicators_history. The mismatch makes the purpose only partially clear.

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?

There is no statement of when to use this tool versus stocktrends_get_indicators_history, evaluate_symbol, or any other sibling. No prerequisites or exclusions are given beyond the implicit 'latest' framing, so the agent must guess at selection 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 cover the safety profile (readOnly, non-destructive, openWorld=false), and the description adds the critical non-obvious trait that this call is paid and needs an x402 payment authorization. It does not disclose cost, whether repeat calls re-charge, or latency, and the 'purchase' wording sits in mild tension 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?

Two tight sentences with the purpose front-loaded and no filler. It is concise but arguably too terse for a paid, four-parameter tool, 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?

For a paid tool with four undocumented parameters, no output schema, and no annotation coverage of the payment behavior, the description leaves too much unstated: no parameter meaning, no return shape, no cost/repeat-call guidance. It only covers scope and payment requirement.

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?

Four parameters with 0% schema description coverage and cryptic names (min_rsi, min_mt_cnt, limit_bucket, limit_overall). The description adds no meaning for any of them, leaving the agent to guess at filtering semantics that the schema only bounds numerically.

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 concrete verb and resource: purchasing/retrieving the 'leadership summary'. The clause 'Leadership is rotation context, not stock picks' narrows what the resource means, distinguishing it from pick/selection-oriented siblings. It does not name a specific sibling tool, so it stops 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 implies the trigger ('purchase ... with an x402 payment authorization') and warns that the output is rotation context rather than stock picks. It never states when to prefer a sibling such as get_selections_latest or get_breadth_sector_latest, so usage is only implied.

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 only cover the read-only/safe profile; the description adds genuinely new behavior: the call is a 'purchase' of a bounded window (implying cost, consistent with idempotentHint=false), and it explicitly states snapshots are API-authored with no local calculation or interpretation. It does not disclose response format or pagination 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?

Purpose is front-loaded in the first sentence, followed by scope disclaimers. The four-item negative list (trade signal, forward-return forecast, probability forecast, trading recommendation) is somewhat padded but serves a stated disclaimer role.

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?

A read-only history tool with three optional, fully documented parameters and no output schema needs little more, and the cost/persistence framing helps. However, it says nothing about what a snapshot contains, the cost magnitude of the 'purchase', or ordering of returned records, leaving gaps for an agent deciding whether to call it.

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 limit, start_date and end_date each fully documented including defaults, bounds and weekdate format. The description adds only the word 'bounded' and 'weekly' framing, which the schema already conveys, so the 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 concrete verb and resource ('Purchase bounded persisted Market Epoch v1 history'), so an agent knows it retrieves stored weekly Epoch snapshots rather than computing them. It does not explicitly distinguish itself from the sibling stocktrends_get_market_epoch_latest, leaving the history-vs-latest routing to the tool name alone.

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?

There is no when-to-use guidance and no named alternative, even though stocktrends_get_market_epoch_latest and stocktrends_get_market_regime_history are obvious candidates for confusion. The description instead spends its sentences on disclaimers about what Epoch is not.

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 safety (readOnly, non-destructive, closed-world), and the description adds two things they do not: that this is a 'Purchase' (i.e., consumes credits/quota, which also plausibly explains idempotentHint=false), and that the payload is descriptive context rather than a signal or forecast. It still omits cost magnitude and what happens on repeated calls.

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 action and the resource. The trailing list of four disclaimers is slightly repetitive but earns its place as an interpretation guardrail for a context payload.

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 and no parameters, the description is the only place to explain what a 'Market Epoch v1' actually contains and roughly how much the purchase costs. It names the payload but does not describe its shape or the credit implications, leaving a gap for a paid, output-less 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?

The tool takes zero parameters (empty schema, additionalProperties false), so there is no parameter semantics to add. Baseline 4 applies; the description correctly implies a no-argument call.

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 ('Purchase the latest persisted Market Epoch v1 structural market-state context'), and the word 'latest' implicitly separates it from the sibling get_market_epoch_history. It never names that sibling explicitly, so differentiation still requires reading the sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance: no condition under which the latest epoch is preferable to the history variant, and no mention of the cost-estimation sibling. The negative clauses ('not a trade signal...') bound interpretation of the output rather than routing the agent between 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 cover the safety profile (readOnly, non-destructive, non-idempotent), so the description's addition of the x402 payment-authorization requirement and the 'bounded' result note is genuine value beyond structured fields. The non-forecast disclaimer further sets expectations. It does not state cost, whether payment is mandatory per call, or what 'bounded' means numerically.

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 core action and followed by a useful caveat; no filler. Slight vagueness in 'bounded' is the only drag on otherwise efficient phrasing.

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 two-parameter, no-output-schema tool the description covers the payment prerequisite but omits both parameter semantics and any hint of the return shape. Since no output schema exists, a brief note on what the history contains would have improved completeness.

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 0% across two parameters, so the description carries the full burden but does not compensate. It alludes to a 'bounded' result but never explains limit (default 12, max 52) or the start_date format, leaving both parameters undocumented in every available source.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: retrieving/purchasing bounded market regime history. 'History' implicitly distinguishes it from the sibling stocktrends_get_market_regime_latest, though no sibling is named explicitly. An agent can tell what the tool returns 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?

There is no when-to-use guidance and no routing to alternatives such as stocktrends_get_market_regime_latest or the other history tools. The only caveat ('Regime is market context, not a forecast or recommendation') constrains interpretation, not invocation 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 already cover the safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=false), so the description only needs to add context. It does add real value: this is a paid call requiring an x402 payment authorization, and the result is market context rather than a trading recommendation. That payment requirement is a behavioral trait not derivable from the annotations or empty 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?

Two tightly written sentences with no filler. The core action and its payment precondition come first, and the qualification about what the regime is follows. Every clause earns its place.

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 input parameters and no output schema, the description's remaining job is to set expectations about cost and content. It discloses the payment requirement and the nature of the returned classification, which is sufficient for an agent to call the tool correctly, though it does not hint at response shape or pricing magnitude.

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 the baseline of 4 applies. There is nothing for the description to disambiguate, and it correctly does not waste words inventing parameter 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 names a specific verb ('Purchase') and resource ('latest API-authored market regime classification'), which cleanly separates it from the many other 'latest' siblings (breadth, leadership, epoch, stim) and from stocktrends_get_market_regime_history. It does not explicitly name the history sibling or the condition that would push an agent toward it, so it falls 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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative. The only usage-relevant content is the precondition that an x402 payment authorization is required, which the agent must infer from 'with an x402 payment authorization'. The disclaimer about trading recommendations is a caveat, not selection 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?

The description adds genuinely useful context beyond the annotations: the call requires an x402 payment authorization, and the output is research context rather than a recommendation. However, it resolves none of the operational questions a paid call raises (cost amount, behavior when authorization is missing or insufficient, whether a failed payment is retried or charged) and does not explain the tension between readOnlyHint=true and a spending operation, which is only partially reconciled by idempotentHint=false.

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, front-loaded with the action and its payment requirement, with the disclaimer placed second. The disclaimer is close to boilerplate but is defensible for a financial-data tool; nothing else is wasted.

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 paid, non-idempotent tool with eight undocumented parameters and no output schema, the description leaves the important gaps open: no cost or payment flow, no error behavior on authorization failure, no sense of what the ranked output contains (symbols? scores? RSI values?), and no routing guidance among the many sibling screener and indicator tools. The disclaimer and payment note are necessary but far from sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%: the schema supplies only types, enums, defaults and ranges, and the description mentions no parameter at all. Self-describing names (limit, min_rsi, weekdate) let an agent guess, but nothing documents what 'sort: mt_cnt' ranks by, how trend and weekdate interact, or whether the filters are ANDed, and the description makes no attempt to compensate.

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 concrete verb ('Purchase') and a concrete resource ('API-authored ranked screener output'), so an agent knows this retrieves a ranked screener result set rather than computing one. It does not, however, differentiate itself from adjacent screener/selection siblings such as stocktrends_get_selections_latest or stocktrends_get_leadership_summary_latest, leaving the agent to infer the distinction from the name alone.

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?

There is no when-to-use guidance, no mention of prerequisites (e.g. an x402 wallet/authorization must be available first), and no named alternative among the 18 siblings. The purchase framing implies a cost precondition but the description never says to prefer a cheaper non-paid sibling when a paid screener snapshot is unnecessary.

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 the safety profile (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description adds information annotations do not carry: that access requires an x402 payment authorization, which is critical before an agent calls it. It stops short of explaining pagination, cost magnitude, or what the base universe actually contains.

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, zero filler, with the primary purpose front-loaded and the disambiguation second. The constraint about payment and the sibling exclusion each earn their place. Slightly dense jargon (ST-IM / STIM) keeps it from being maximally clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter tool with no output schema and no annotation-level parameter guidance, the description leaves too much undefined: no filter semantics, no notion of what the 'base universe' contains or how it differs structurally from the thresholded list, and no return-shape hints. The payment disclosure is helpful but does not cover the operational 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?

All six parameters have 0% schema description coverage, and the description says nothing about any of them. Opaque names like cs_only, include_mast, and min_prob13wk are left entirely unexplained, so an agent cannot know what any filter does without guessing. The description fails to compensate for the coverage gap.

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 names a specific resource (the API-authored base ST-IM selection universe) and explicitly distinguishes it from the thresholded published STIM Select list, which is its nearest sibling (get_stim_latest / get_stim_history). The verb 'Purchase' is unusual and slightly obscures that this is fundamentally a retrieval endpoint, but the resource identity is 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?

'This is not the separately thresholded published STIM Select list' gives a clear exclusion that lets an agent route away from this tool when it wants the thresholded list. However, it never names the alternative tool or states the positive condition ('use this when you need the raw universe'), so the driver is 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?

Annotations already cover read-only/non-destructive behavior, so the bar is low, and the description adds two things not in structured data: this is a paid call gated by x402 payment authorization, and the returned data is probabilistic context rather than a forecast. It omits billing granularity and pagination behavior for large ranges.

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 compact sentences, payment prerequisite and data caveat both front-loaded with no filler. Nothing is padded or repeated.

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?

A paid, range-parameterized history endpoint with no output schema and 0% parameter description coverage needs the description to carry the parameter and return-shape burden, and it does not. Only the payment gate and the data caveat are covered.

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 0% across five parameters, so the burden falls entirely on the description, which says nothing about start/end formats, the limit range, include_gaps, or the required symbol_exchange encoding. "Bounded" only faintly gestures at the limit constraints.

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 ("Purchase") and resource ("API-authored ST-IM history"), with the "bounded" qualifier signaling range-limited retrieval. This separates it from stocktrends_get_stim_latest by the history/latest distinction, though "ST-IM" itself is unexplained jargon.

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 discloses a prerequisite (an x402 payment authorization is required to call it) which is real usage guidance, but it never states when to prefer this history endpoint over the sibling "latest" variant or how the range parameters should be chosen. Usage is implied rather than directed.

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 beyond the annotations by disclosing that the call requires an x402 payment authorization, that it is API-authored, and that the identifier format has a canonical and a deprecated form — none of which is derivable from readOnlyHint/destructiveHint. It does not say whether the payment is charged per invocation or what happens on payment failure, which is why this is not 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?

Two tight sentences, front-loaded with the action and payment requirement, then the identifier convention. No filler and nothing important buried.

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 still owes the agent some sense of what the record contains and what the x402 payment flow requires (cost, when authorization is demanded, failure behavior). It covers the parameter and the acquisition model but leaves the payment mechanics and payload shape unspecified.

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 parameter's pattern and examples are fully documented there. The description's 'canonical IBM-N; legacy IBM_N accepted temporarily' restates the schema verbatim without adding syntax or resolution rules, so the 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 concrete action and resource: fetch the latest ST-IM record, with the acquisition model (x402 purchase) made explicit. It is distinguishable from stocktrends_get_stim_history by the 'latest' framing, though 'ST-IM' itself is never expanded, so a new agent still has to infer the resource's meaning.

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 statement of when to prefer this over stocktrends_get_stim_history (historical) or stocktrends_get_indicators_latest (a different data family). The only usage cue is the payment precondition, which is a prerequisite rather than a selection rule.

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 the safety profile is covered. The description adds two useful traits beyond that: it makes no paid request (cost behavior) and does not commit to selecting an ambiguous symbol (non-resolving behavior). It still says nothing about result shape or how candidates are ranked/limited.

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 the core purpose front-loaded and no filler. It is tight, though the terseness comes partly at the expense of the parameter and usage detail an agent would want.

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, 0% parameter description coverage, and no naming of the resolve_instrument alternative, the description leaves significant gaps. For a four-parameter lookup tool it should at least explain the filtering flags and what candidates are returned.

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 0% with four parameters (symbol, limit, cs_only, details), yet the description explains none of them. 'Across exchanges' barely gestures at search scope but does not clarify cs_only, details, or the limit cap, so it fails to compensate for the coverage gap.

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 clear verb and resource ('Search public instrument candidates across exchanges'), so the agent knows it returns candidate instruments rather than single resolved ones. It stops short of naming the obvious sibling (stocktrends_resolve_instrument), leaving the differentiation implicit rather than 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?

The clause 'does not select an ambiguous symbol' implies this tool is for candidate discovery rather than resolution, and 'does not make a paid request' hints at a free pre-step. However, it never states when to prefer this over stocktrends_resolve_instrument or other siblings, so usage is only implied.

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 declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds useful behavioral context beyond those annotations: the API's default U.S. listing preference, how to request a specific listing including Canadian securities, and that upstream 404 and 409 responses are preserved. There is no contradiction with 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 four short sentences, front-loads the core action, and every sentence adds distinct value: purpose, default behavior, alternative tool, and error behavior. There is no redundant or filler text.

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 six-parameter resolve tool with no output schema and no parameter descriptions, the description covers purpose, default routing, alternative tool selection, and error preservation. However, it leaves several parameters undocumented, so an agent may have to guess at the meaning of cs_only, details, and prefer_exchange.

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 0%, so the description must compensate for six undocumented parameters. It explains the intended use of exchange and symbol_exchange and the default U.S. preference, but it does not describe symbol, cs_only, details, or prefer_exchange, leaving most parameters semantically opaque.

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: 'Resolve a Stock Trends instrument identifier.' It also explicitly distinguishes this tool from the sibling lookup tool by saying 'Use lookup to explore alternatives,' so an agent can tell the two apart 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?

It gives clear context for specifying 'exchange or canonical symbol_exchange' to target a particular listing, including Canadian securities, and names the lookup tool as the alternative for exploring options. It does not state when not to use this tool or which parameters are required, but the primary routing guidance is strong.

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