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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful detail about what the profile contains (email, username, organization), but does not disclose additional behavioral aspects such as authentication requirements or potential error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no redundant wording. It conveys the action, the subject, and the expected content efficiently.

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-only tool, the description is nearly complete: it names the three expected profile fields and the user scope. It does not define the exact response structure, but no output schema exists and the simple nature of the tool makes this acceptable.

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 are zero parameters, and the schema description coverage is 100% since the schema is empty. The description compensates by describing the return value, which is the only semantically relevant information for invoking the tool.

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 ('Return') and a clear resource: the signed-in user's profile, listing the key fields (email, username, organization). This makes the tool's purpose unambiguous and distinguishes it from siblings like auth_status.

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

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

The description provides clear context: use this tool to retrieve the profile of the currently signed-in user. It does not explicitly mention alternatives or when not to use it, but for a zero-parameter profile read the implied usage is evident.

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 mark the tool as read-only and open-world, so the description does not need to repeat safety signals. It adds value by specifying what the tool reports: token presence and the authenticated user. This is sufficient behavioral disclosure for a no-parameter status tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that states the tool's core behavior with no filler or redundancy. Every word contributes to understanding what the tool does.

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-only status tool with no output schema, the description fully covers what an agent needs to know: what condition is checked and what information is returned. There are no remaining gaps that would prevent 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?

The tool has zero parameters, so there is no parameter meaning for the description to clarify. The baseline for a parameterless tool is 4, and the description correctly focuses on the tool's output rather than irrelevant parameter details.

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

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

The description uses a specific verb ('Report') and clearly identifies the resource: CLI token presence and the authenticated user. It is immediately distinguishable from siblings like health or account_profile, so an agent knows exactly what this tool does.

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

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

The purpose implies when to call this tool: to verify CLI authentication status. However, there is no explicit guidance about when not to use it or how it differs from related tools such as account_profile, leaving the usage context somewhat 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description does not contradict them. It does add useful context about the kinds of values returned, but it does not disclose response format, ordering, pagination, or possible variability. With annotations covering the safety profile, the description adds some but not rich behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, compact sentence that front-loads the verb and resource and uses parenthetical categories efficiently. Every word earns its place, with no filler or redundant restating of the tool name.

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-only, open-world list operation, the description is fully adequate. It specifies the return domain and the categories included, and the tool's purpose is obvious from the name and description. Nothing essential is missing at this complexity level.

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 has zero parameters, and the input schema already documents this with 100% coverage. There are no parameter semantics for the description to clarify, so the baseline of 4 is appropriate; no additional parameter information 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?

The description uses a specific verb, 'Return', and names the exact resource: 'available filter values', followed by concrete categories (sectors, industries, countries, currencies, exchanges). This clearly distinguishes the tool from siblings like tickers_list and scores_list and states its purpose without ambiguity.

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

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

The intended usage is implied: call this tool when filter values are needed, likely for constructing or understanding screens. However, the description provides no explicit guidance on when to use this tool versus alternatives, and no alternatives or exclusions are mentioned.

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 the 'Check' action is consistent with that safe read-only profile. The description adds value by expanding scope beyond the annotation title 'API health' to include the database, but it does not disclose response behavior or failure semantics; given the annotation coverage, this is adequate though not rich.

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 five-word sentence with zero waste. The core action and target resource are front-loaded, and every word 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?

For a zero-parameter, annotation-backed health check, the description is nearly complete. The only minor gap is the unspecified response shape, but with no output schema and low complexity, an 'ok/error' style result is reasonably predictable.

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 has zero parameters and schema coverage is 100%, so per baseline no parameter explanation is required. There is nothing for the description to add about inputs.

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 ('Check') and resource ('API and database health'), making the tool's purpose unambiguous. None of the 22 sibling tools perform health checks, so it is fully distinguished from alternatives.

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 rather than explicit — the description clearly suggests it is used to verify system health, and no sibling tool competes for that role. However, it does not state when to call it (e.g., pre-flight checks, troubleshooting) or any conditions that would make it the right or wrong 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 provide readOnlyHint=true, so the operation is known to be non-destructive. The description adds the batch behavior beyond the annotations, but does not disclose limits, date-range handling semantics, or output format. This is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single efficient sentence with no filler. The key batch behavior is front-loaded, and every word contributes to understanding what the tool does.

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, no per-parameter descriptions, and only a one-line description, the tool is under-specified for correct invocation. An agent would need to guess date formats, the meaning of scoring_system_id, and response shape, despite the read-only annotation.

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 the bare parameter names. It clarifies that 'tickers' is an array of security identifiers, but it does not explain start, end, or scoring_system_id, leaving three of four parameters semantically under-specified.

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

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

The description uses a specific verb ('Return'), a clear resource ('score history'), and a defining scope ('several tickers at once'). This distinguishes it from siblings like history_ticker, which implies single-ticker history, and history_top, which implies top-ranked tickers.

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?

'Several tickers at once' clearly communicates the batch context and implies this tool is the right choice when multiple ticker histories are needed. However, it does not explicitly name alternatives or state when not to use 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 declare readOnlyHint=true and openWorldHint=true, so the read-only behavior is covered. The description adds single-ticker scope and the date format, but does not disclose return ordering, default date-range behavior, or what happens when scoring_system_id is omitted.

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?

One compact sentence that front-loads the action and scope, with the date format in a parenthetical. Every element earns its place and there is no wasted 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?

With four parameters, no output schema, and no parameter descriptions, the definition leaves the agent without guidance on the meaning of scoring_system_id, the expected response shape, or the default behavior for omitted start/end. It is minimally viable for a basic default call but not complete enough for confident invocation in varied cases.

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, but it only provides a generic date format and does not explain start/end semantics, optionality, or scoring_system_id. The ticker parameter is inferable from the tool name, but scoring_system_id remains unexplained, leaving a clear gap for correct invocation.

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

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

Description states a specific verb ('return') and resource ('score history' for a single ticker), clearly distinguishing it from siblings like history_batch and history_top. The parenthetical date format adds precision without obscuring the core purpose.

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?

'Single ticker' provides a clear selection criterion: use this when you need history for one ticker rather than multiple tickers or top-ranked tickers. It does not explicitly name alternatives, but the scoping is unambiguous enough to guide correct selection.

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 signal readOnlyHint=true and openWorldHint=true, so the description only needs to add extra behavioral context. It does indicate the output is 'score history', but it does not clarify how top-N is determined, what scoring_system_id controls, or whether results are sorted or paginated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler, front-loading the verb and resource. Every word contributes to the core purpose, and it does not repeat information already available in the annotations 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?

The tool has only two optional parameters and read-only annotations, so the description is sufficient for a basic default call. However, with no output schema, it leaves the structure of the returned score history unspecified, and scoring_system_id remains unexplained.

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 missing parameter documentation. It implicitly explains 'top' via 'top-N', but it never mentions scoring_system_id, its effect on results, or where to find valid scoring system IDs.

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 concrete operation and resource: 'Fetch the top-N tickers' and specifies the return type 'score history'. This clearly separates it from siblings like history_ticker (single ticker), history_batch (arbitrary tickers), and scores_top (current top scores without 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?

No guidance is provided on when to choose this tool over alternatives. The description does not mention that history_ticker covers a single ticker, history_batch covers multiple specific tickers, or that scores_top returns a current snapshot. The agent must infer the intended use from the name alone.

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 supply readOnlyHint and openWorldHint; the description adds substantial behavioral disclosure: two-stage scoring, filters applied after scoring, OR/AND logic, the min_market_cap_usd backend floor quirk, error behavior for invalid scoring_universe keys, and saved-screen config handling. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Long but tightly structured: a one-line summary, bolded stage headers, concrete examples, and a dedicated paragraph for edge cases. Each section adds a distinct rule, and the length is warranted by 15 parameters and zero schema coverage.

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

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

Covers invocation semantics, filter logic, config details, edge cases, and the saved-state path from screen_share/systems tools. The main gap is return/pagination details: limit, offset, sort_by, sort_order, and the general response shape are not described, and there is no output schema to fill that 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 0%, and the description compensates for most non-obvious parameters: config structure, scoring_universe keys, filter keys, min/max market cap asymmetry, and loose-input normalization. It omits limit/offset/sort_by/sort_order and the top-level include_duplicates parameter, but those are simpler and more inferable.

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: 'Compute custom scores from a CustomScoreConfig, scored against a chosen peer group.' The detailed two-stage explanation and concrete examples make the tool's purpose clear and distinguish it from standard score-listing siblings like scores_top and scores_list, even though no sibling is named.

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?

Clearly explains when to put criteria in scoring_universe vs stage-2 filters, with explicit examples and exclusions: min_score/max_score/ticker/tickers cannot go in scoring_universe, and min_market_cap_usd has special peer-group behavior. It does not explicitly name alternative sibling tools, but the usage boundaries are unambiguous.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses several non-obvious behaviors: tickers with no score are omitted, results are sorted by quality score descending, default rows are slimmed with truncated descriptions and duplicate rows, and full_rows returns the raw backend payload. It also surfaces authentication/ownership requirements for saved scoring systems.

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, then moves into scoping, edge behavior, response shape, and parameter details. Every sentence contributes useful information without redundancy, and the Args/Returns structure makes it easily scannable.

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 lookup tool with no output schema, the description is impressively complete: it defines what is returned, how missing tickers are handled, sort order, response shape components, and the difference between default and full rows. An agent has enough information to select and invoke 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 0%, so the description carries the full burden for parameters. It explains tickers are exact symbols with examples, scoring_system_id is optional and falls back to default scoring, and full_rows switches to the unmodified backend payload. This adds meaningful behavioral detail absent from the schema.

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

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

The description opens with a specific verb and resource: 'Return current scores for a specific list of tickers.' It clearly distinguishes this tool from sibling tools like scores_top or scores_show by emphasizing a user-supplied list and the exact-ticker scope, leaving no ambiguity about what the tool does.

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

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

The description gives clear context for when to use the tool: when you have exact ticker symbols and need their current scores. It also explains when to include scoring_system_id and the prerequisite of being signed in and owning that system, though it does not explicitly name alternative sibling tools or state when not to use them.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses meaningful behavior: default rows are slimmed, duplicates appear as ticker strings, descriptions are truncated, and full_rows=True returns the raw backend payload. It also clarifies that market caps are in USD, adding value beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short, front-loaded with the core purpose, and every sentence adds useful information. The market-cap unit note and the full_rows payload distinction are high-value details with no filler.

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

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

Given the tool's complexity — 16 parameters, no output schema, and no parameter descriptions — the description is incomplete. It explains the general list behavior and row-slimming but does not describe pagination, sort behavior, filter value formats, or the actual row fields returned, limiting an agent's confidence in invoking 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 0%, so the description must compensate for the 16 parameters. It only clarifies that market-cap parameters are in USD and explains full_rows; the rest, including limit, offset, ticker, sectors, sort_by, sort_order, min_score, and max_score, are left to inference from parameter names.

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

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

Description states a specific action and resource: 'List scored tickers with optional filters.' It adds distinguishing details like market caps in USD and the default slimmed row format, making the purpose clear even though it does not explicitly contrast with sibling list tools like scores_top or scores_for_tickers.

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

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

The description provides no guidance on when to choose scores_list over sibling tools such as scores_top, scores_for_tickers, or scores_show. The only conditional advice is the full_rows=True switch, which explains payload shape rather than tool selection, so there is no when-to-use or when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the basic safety profile is covered. The description adds 'aggregated' and 'USD' context, but it does not disclose output shape, pagination, or other behavioral details beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence with no filler. It front-loads the key result ('aggregated total market cap (USD)') and wastes no tokens.

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

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

The tool is simple with two optional parameters and no required arguments, and annotations cover the read-only behavior. However, with no output schema, the description does not specify the return format or the precise interaction between min_score and sectors, leaving it at minimum viable 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%, and the description's 'filtered universe' is too vague to map to the two parameters, sectors and min_score. It does not explain how these parameters affect the aggregation, leaving the schema titles to carry the semantic weight.

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

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

The description uses a specific verb ('Return') and resource ('aggregated total market cap (USD)'), making the tool's purpose clear. It is distinguishable from the sibling score tools, though it does not explicitly name any alternative.

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 guidance is given about when to use this tool versus siblings such as scores_statistics or scores_top. The phrase 'for a filtered universe' implies a use case, but there are no explicit alternatives, prerequisites, or exclusions.

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=true and openWorldHint=true, so the read-only nature is covered. The description adds only that the result is 'score row(s)' for one ticker, which is mildly informative but does not disclose return shape, error behavior, or 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?

The description is one concise sentence, front-loads the key action and resource, and contains no filler. Every word contributes to understanding the tool's core purpose.

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 single-parameter tool with read-only annotations, the description covers the essential operation. However, without an output schema, the vague 'score row(s)' does not fully explain what the response contains, and usage context relative to sibling tools 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?

Schema description coverage is 0%, so the description must compensate. It minimally clarifies that the ticker parameter refers to a single ticker, but it omits format requirements, case sensitivity, or accepted symbol forms.

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 action (Return), resource (score rows), and scope (a single ticker). It distinguishes from sibling tools like scores_list and scores_for_tickers by the 'single ticker' qualifier, though it does not explicitly name those alternatives.

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 guidance is provided about when to use this tool versus related tools such as scores_for_tickers, scores_list, or score_compute. The single-ticker constraint is implied, but there is no explicit context for choosing it over alternatives.

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

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

readOnlyHint=true already discloses the safe read-only nature, so the description's main contribution is naming the exact outputs (min/max/average). It does not disclose behavior when filters are null/omitted, how sector and market-cap filters combine, or whether multiple sectors yield per-sector or pooled statistics. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with zero filler: the verb, the computed statistics, and the scope all appear in the opening clause. Every word earns its place, and the length is appropriate for a one-purpose read-only aggregation tool.

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

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

There is no output schema and no parameter documentation, so the agent must infer return shape (beyond the three numbers) and filter semantics from names alone. Critical ambiguities—default universe when all filters are null, multi-sector behavior, and filter interaction—are unaddressed, making the one-sentence description insufficient despite the simple surface.

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 carries the burden of explaining the five filter parameters, but it only gestures at them via 'filtered universe.' It does not clarify whether min/max bounds are inclusive, whether filters are ANDed, or how an array of sectors is handled; the parameter names themselves carry the entire semantic load.

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

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

The description states a specific verb ('Return') and resource ('min/max/average score statistics') over a 'filtered universe,' making the aggregate intent unambiguous. It is internally clear and distinct in function from siblings like scores_list and scores_show, though it never names a sibling or explicitly states what it is not.

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 guidance on when to prefer this tool over the five other score-related siblings (scores_list, scores_top, scores_show, scores_for_tickers, scores_market_cap). 'For a filtered universe' weakly implies a filtering use case, but there are no exclusions, prerequisites, or explicit alternative routing.

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

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

The annotations already declare readOnlyHint and openWorldHint, covering the main safety model. The description adds the return format and the top-ranked nature, but it does not disclose ordering direction, limit semantics, or whether the map includes all tickers beyond the limited result.

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 contains the essential purpose and output format with no wasted words. Every part 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?

For a simple read-only top-N tool with one optional parameter, the description is mostly sufficient: it states what is returned and in what shape. It is slightly incomplete around limit semantics and sibling differentiation, but the annotations and simple schema keep the overall context adequate.

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 carries the burden, but it never mentions the 'limit' parameter. The property name and default value are somewhat self-explanatory, but the description adds no explicit meaning about how the limit affects the returned map.

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 ('Return'), the resource ('top tickers'), and the selection criterion ('by quality score'), plus the exact output shape. It is clear on its own, though it does not explicitly distinguish itself from sibling tools like scores_list or scores_show.

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 phrasing implies use when the agent needs the highest-quality tickers rather than all scores or per-ticker details. However, it gives no explicit when-to-use guidance and does not name alternatives or exclusions despite many closely related sibling 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?

Beyond the annotations, the description discloses that this persists configuration, is content-addressed so identical configs return the same URL, and creates no duplicate when the screen already exists. It also explains input normalization behavior, giving agents a concrete model of side effects without contradicting idempotentHint or readOnlyHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a one-sentence summary, a behavior section, and explicit Args/Returns sections. Every sentence adds meaningful operational detail; the most important behavior—link creation and content addressing—appears early.

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

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

Given an absent output schema and a single complex nested parameter, the description covers input semantics, normalization, return keys (url, slug, created, view_count), persistence, and deduplication. Nothing needed for correct invocation or interpreting the result is missing.

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

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

Schema coverage is 0% and the config parameter is an opaque object with additionalProperties allowed. The description compensates fully by enumerating the key fields (groups, winsorizePercentile, missingDataPercentile, normalizeGroupZScores, includeDuplicatesInScoring, optional filters) and clarifying loose-input normalization.

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: 'Create a shareable link for a screen (CustomScoreConfig) and return its URL.' It clearly differentiates itself from siblings that list, compute, or manage systems by focusing on sharing a screen configuration via a persistent link.

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 intended use is clear: generate a shareable, public link that can be copy-pasted to anyone so they can view and load an exact screen. It does not explicitly name alternatives or list when-not-to-use, but the description's scoping makes the usage context obvious among the sibling 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?

The annotations already cover readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true, so the baseline burden on the description is lower. The parenthetical about incrementing usage count adds useful behavioral context about a side effect that is not visible in the schema or annotations. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, compact sentence and the most important behavioral distinction (usage count side effect) is included in parentheses without bloating. It earns its place, though it could define 'apply' somewhat more.

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

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

Given the tool has only one parameter, no output schema, and sibling names largely self-explanatory (systems_* family), the single-sentence description is mostly sufficient for an agent to call it correctly. A minor gap is that it does not say anything about the return value or when applying is valid, but the simplicity of the operation and the annotations keep the definition reasonably complete.

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

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

The schema has only one required integer parameter, system_id, and the schema description coverage is 0% so the schema itself doesn't explain it. The description names the resource ('saved scoring system') which implies system_id refers to the ID of that saved system, adding some meaning. However, it doesn't explicitly state the format/requirements of system_id or explain what 'apply' results in.

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

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

The description uses a specific verb 'Apply' plus resource 'saved scoring system' and even clarifies the side-effect ('increments its usage count'). This makes it clearly distinct from sibling tools like systems_show, systems_list, systems_create, systems_update, and systems_delete, which involve other operations on scoring systems.

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 clearly states that this tool applies a saved scoring system, implying it is used when the agent needs to activate or use an existing scoring system. It does not explicitly name alternatives or say 'when NOT to use', but among the systems_* siblings the verb 'apply' is distinct enough to convey the intended usage context.

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 indicate this is a mutating but non-destructive operation. The description adds the context that the resulting system is 'saved' and configured from an object, which is useful, but it does not disclose return values, validation, uniqueness constraints, or side effects beyond creation. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. However, given the opaque config parameter and the lack of other context, the brevity leaves important information out; it is concise but slightly under-structured for the tool's complexity.

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

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

With no output schema and an open-ended config object, the description is not complete enough for an agent to confidently construct a valid call. It omits return behavior, config semantics, and how this creation interacts with systems_apply, systems_update, or scoring workflows.

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 the schema's lack of parameter documentation. It only mentions 'config object', giving no detail about the required name, the optional description, or the actual shape/fields expected inside config. This is insufficient for a permissive additionalProperties object.

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 action: create a saved scoring system. It specifies the resource ('scoring system') and the input source ('config object'), and the 'create' verb naturally distinguishes it from sibling operations like systems_update, systems_delete, and systems_apply.

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 about when to use this tool versus alternatives such as systems_update, systems_apply, or score_compute. No prerequisites, exclusions, or decision rules are provided, so the agent must infer usage entirely from the tool name and siblings.

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 destructiveHint=true and readOnlyHint=false, so the description adds no behavioral context beyond the word 'Delete'. It doesn't state that deletion is permanent, what side effects may occur, or why the idempotentHint might matter.

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?

One sentence, front-loaded with 'Delete', and no wasted words. This is appropriately concise for a simple single-parameter delete operation.

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

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

The description plus annotations cover the core safety profile for a low-complexity, one-parameter operation with no output schema. However, it omits any statement about postconditions, error behavior, or how to source the system_id, making it only minimally viable.

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 does not explain system_id beyond the schema's title. It doesn't say how to find the system_id or that it must reference an existing saved scoring system, leaving the agent without useful parameter-level guidance.

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 ('Delete') and resource ('a saved scoring system'), making the tool's purpose immediately clear. It also naturally distinguishes this from sibling tools like systems_create, systems_update, systems_apply, and systems_show.

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 gives no guidance on when to use this tool versus alternatives, no mention of irreversibility, and no indication that system_id should come from systems_list or systems_show. An agent gets no context about preconditions or caution.

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=true and openWorldHint=true, so the safety profile is covered. The description adds the scope of 'user's saved' systems, but does not disclose additional behavior such as response format, ordering, or whether the open-world hint means results may include unsaved or external systems. This is acceptable but minimal.

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, compact sentence that states the action, the resource, and the ownership scope with no filler. Every word earns its place and the key information is 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?

For a zero-parameter read-only list operation, the description is nearly complete. It lacks explicit mention of return values or pagination behavior, but with no output schema and simple semantics, the provided description is adequate for an agent to invoke 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?

The tool has zero parameters, so the input schema imposes no burden on the description. The description correctly implies that the tool takes no arguments and simply returns the user's saved systems, which is sufficient at the baseline for parameterless tools.

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

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

The description uses a specific verb and resource: 'List the user's saved scoring systems.' It clearly distinguishes this list operation from sibling tools like systems_show, systems_create, and systems_update by emphasizing the 'saved' collection and the user's ownership.

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 guidance on when to use this tool versus alternatives. While the description implies a list-all-saved-systems use case, it does not mention that systems_show is for a single system or that creating/updating systems are the mutation counterparts, leaving selection largely to the agent's 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 declare readOnlyHint=true, so the safe read-only nature is covered. The description adds only the fact that the system is 'saved' and looked up by ID, which is contextually useful but not a rich behavioral disclosure. No contradiction with annotations exists.

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?

One short sentence communicates the action, object, and key scope. There is no wasted wording, and the essential information is 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?

For a simple read-only single-ID retrieval tool with no output schema, the description is nearly complete. It could arguably mention what a 'scoring system' includes or the return format, but the phrase 'Show a saved scoring system' sufficiently covers the expected behavior for an agent.

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 0%, so the description carries the burden. It relates system_id to the saved scoring system via 'by ID,' which is useful but somewhat redundant given the parameter is already named system_id. No additional detail is provided about where to find the ID or how the lookup behaves.

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

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

The description uses a clear verb ('Show') with a specific resource ('saved scoring system') and a precise access method ('by ID'). It naturally distinguishes this tool from siblings like systems_list, systems_create, and systems_update, making its role immediately understandable.

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 clearly implies the intended use case: retrieve a single existing scoring system when you have its ID. It does not explicitly mention alternatives like systems_list or systems_delete, but the 'by ID' scoping provides enough context for an agent to select it appropriately.

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 indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the mutation profile is known. However, the description adds no behavioral context beyond the word 'update'—it does not clarify whether this is a partial update, whether config is replaced entirely, or what side effects occur. No added value beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, direct, front-loaded sentence with no filler or redundancies. It is concise to a fault—it earns its place as a purpose statement but omits useful supporting detail that could have been added without bloating the description.

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 4 parameters, 0% schema coverage, and no output schema, the description is far too sparse. An agent cannot tell whether omitted fields are preserved, what config should contain, whether applying the system is affected, or what the tool returns. The description alone is insufficient for correct invocation beyond guessing at the required system_id.

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 needed to explain what system_id, name, config, and description mean and how they behave. It mentions none of them. An agent gets no help understanding that config is an object, which fields are optional, or what the required system_id refers to beyond the generic tool name.

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 ('Update') and resource ('a saved scoring system'), which distinguishes it from sibling tools like systems_create, systems_delete, systems_apply, and systems_show. Even without the title, the purpose is immediately understandable.

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 gives no guidance about when to use this tool versus alternatives. It does not mention that systems_create is for new systems, systems_delete for removal, or systems_apply for scoring with a system. The word 'saved' only weakly implies an existing system, but no explicit usage context or exclusions are provided.

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

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

The annotations already signal readOnlyHint=true and openWorldHint=true, so the description does not need to restate those. The phrase 'optionally truncated to limit' adds some behavioral context about how the limit parameter affects output. However, it does not disclose any further behaviors such as ordering, pagination, or how 'available' is determined.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence where every word earns its place. It is front-loaded with the core action ('Return available tickers') and adds the optional truncation behavior without any filler or redundancy.

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

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

For a simple read-only list tool with one optional parameter and no output schema, the description is nearly sufficient. It tells the agent what the tool returns and the one way to constrain the result. It could be more complete by stating the output format, but the simplicity of the operation and the tool name reduce the need for elaborate explanation.

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 explaining the limit parameter. The phrase 'optionally truncated to limit' clarifies that limit is an optional cap on the return set. This is useful but minimal; it does not specify behavior for null, zero, negative, or very large limit values.

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

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

The description clearly states the tool's action and resource: 'Return available tickers.' This is specific enough to communicate the core purpose. However, it does not explicitly differentiate itself from the sibling tool tickers_search, relying on the reader to infer that 'available' implies a full list rather than a search.

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

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

The description implies the tool should be used when one wants to retrieve available tickers, optionally with a limit. It does not explicitly state when to use this tool instead of tickers_search or other sibling tools, nor does it provide exclusion criteria. Usage guidance is therefore only implied, not directly articulated.

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 supply the read-only safety profile. The description adds useful behavioral detail (case-insensitive substring matching over available tickers), but does not mention return shape, result limits, or behavior when no match is found, so it is not rich context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence conveys the action, the resource, and the matching behavior with no filler.

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

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

For a one-parameter read-only search tool, the description plus annotations cover the essential behavior. The lack of an output schema leaves return-format details unstated, but the phrasing 'Search available tickers' implies the result is the matching set of tickers.

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%, but the description compensates by defining the single query parameter as the case-insensitive substring used to search. This is sufficient to know what value to pass.

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

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

The description uses a specific verb ('Search') with a clear resource ('available tickers') and a precise matching mode ('case-insensitive substring'). This clearly distinguishes it from the sibling tickers_list, which would be the listing alternative.

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 clearly implies when to use this tool: when a substring of a ticker is known and matching available tickers is needed. It does not explicitly name alternatives or exclude cases, so it stops short of a 5.

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