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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds real substance by disclosing the comparison surface the agent will get back (returns for every period, allocation, manager), which goes beyond what the annotations state.

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

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

Two short sentences with zero filler; the capability statement is front-loaded and the usage routing follows. Every clause carries information.

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

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

With one fully documented parameter, no output schema and complete annotations, the description covers what an agent needs to select and call it. Minor gaps remain: nothing about result ordering, or behavior when an id is invalid or the array bounds are violated.

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

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

Schema coverage is 100% and the schema already documents the 'regNo' / 'regNo-groupId' format with examples. The description still earns credit by adding provenance: 'Ids are the reg_no (and group_id) of search rows', telling the agent where to obtain valid 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?

States a specific verb and resource ('Put 2 to 8 funds side by side') and enumerates exactly which attributes are compared (type, size, NAV, returns, allocation, manager). That level of detail makes it unmistakably distinct from the single-fund sibling fp_fund without needing to name it.

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?

'Use after fp_search_funds when the user is choosing between funds' gives both a prerequisite and the decision context that selects this tool. It does not state a negative case (e.g. use fp_fund for a single fund), so it falls just short of full when/when-not coverage.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds that this returns a complete snapshot with a specific field set, which is useful behavioral context, though it says nothing about payload size or pagination for such a broad record.

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, no filler: the first defines scope and payload, the second routes to alternatives. Front-loaded with the primary 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?

With no output schema, the field enumeration carries the return-value burden and does it well, and the dependency on a prior search is stated. Minor gap: nothing describes the effect of on_date (historical snapshot) or the default behaviour of group_id, relying entirely on the schema for those.

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

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

Schema coverage is 100%, so reg_no, on_date and group_id are all documented in the schema itself. The description only reinforces provenance of reg_no ('after fp_search_funds'), adding no syntax or semantics for the optional on_date or group_id beyond what the schema states. Baseline 3 applies.

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

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

States a specific verb and resource ('Get one fund in full') and enumerates the content returned (NAV, returns, size, allocation, investors, manager, auditor, custodian, website). This clearly distinguishes it from fp_search_funds (list) and fp_history (series) without needing to open a schema.

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

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

Explicit prerequisite ('Use after fp_search_funds') and explicit routing away from two siblings: 'For a price series use fp_history; to put several side by side use fp_compare.' The when-to-use and alternatives are both named.

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 this as a safe, idempotent, read-only listing, so safety is covered. The description adds real behavioral context beyond that: returns are averages expressed as percent per type and allocation is an average share across stock/bond/cash/deposit, which is non-obvious interpretation guidance.

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 and the sibling routing instruction are front-loaded, and no sentence is filler. The final sentence about averages and allocation is dense but carries genuine interpretation value for the returned numbers.

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

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

No output schema exists, so the description carries return-value explanation, and it does so for the two non-obvious fields (returns as average percent, allocation as average share). It stops short of enumerating the full record shape, but for a small reference listing that is 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?

The tool takes zero parameters, so there is no parameter semantics to explain; baseline is 4. The description correctly doesn't waste words on 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?

States a specific verb and resource ('List fund types') and enumerates the returned metrics (fund counts, total size, average returns) plus example type names. An agent can tell this is the reference/lookup tool rather than a search or detail tool.

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 says 'Use first to learn the type ids for fp_search_funds', naming the sibling and the ordering dependency, and gives a concrete question-shaped use case. Both when-to-use and the alternative are spelled out.

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

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

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds useful behavioral context beyond annotations: a maximum of 60 points, oldest-first ordering, and derived result fields for NAV change or net units.

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 three tight sentences with the core purpose front-loaded. The examples, ordering note, and result note each add useful information without repetition.

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

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

With no output schema, the description still names the main return fields, ordering, and point cap, while the input schema fully documents parameters. It is nearly complete, though it does not describe every series-specific return shape.

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

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

Schema description coverage is 100%, and the enum descriptions already explain each series in detail. The description repeats the series categories and adds some output semantics, but it does not add parameter-level meaning for days, reg_no, or group_id beyond the schema.

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

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

The description states a specific verb and resource: "Get a fund's daily history." It enumerates the available series and the 60-point cap, which clearly distinguishes this historical time-series tool from sibling fund-detail tools.

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

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

It gives concrete usage examples such as "how did this fund move in the last 6 months" and "are investors putting money in." It does not explicitly name when not to use it or point to a specific sibling alternative, so it is clear but not fully 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?

Discloses a non-obvious behavioral constraint absent from the schema: results are returned "oldest first" and capped at "at most 60 evenly spaced points." That downsampling behavior directly changes how an agent should interpret `days` (a 4000-day request still yields 60 points), and it adds that the series carries the window's change. Annotations already cover the safety profile, so this is pure added value.

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

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

Two sentences, no filler: mechanics first, then when-to-use with quoted example questions. The most surprising fact (60-point cap) sits in the opening sentence where it cannot be missed.

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 manages to convey ordering, granularity, result volume, and that the value series includes window change — enough to use the tool correctly. Return field shapes (low/high, rolling returns) are only in the schema descriptions, so not everything is covered, but the critical gaps are closed.

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

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

Schema coverage is 100% and each parameter already has a meaningful description, so the schema does the heavy lifting. The description's "evenly spaced points" and "over the window" hints loosely connect to `days` and `series` but add no format or interpretation detail beyond what the schema states. Baseline 3 applies.

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

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

States a specific verb and resource ("get the daily history of one market or industry index") with scope qualifiers (single index, daily granularity, oldest first). It also implicitly distinguishes itself from fp_history (fund history) and positions fp_indices as the lookup step, so an agent can pick it without opening the schema.

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

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

Explicitly prescribes the workflow ("Use after fp_indices") and gives two concrete motivating questions ("how did the bourse index move this year", industry vs fund market comparison). No exclusion statement — it never says to use fp_history instead for funds — but the context is clear.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's added value is in output shape: 'The first block is the market overview' and the fact that each index carries an ins_code. It does not mention the 70-row cap behavior beyond the schema or result size, which keeps it off a 5.

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

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

Front-loaded with the purpose, then usage examples, then the sibling routing rule. Every sentence carries information; the trailing 'The first block is the market overview' is slightly stranded at the end rather than grouped with output expectations.

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

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

No output schema exists, and the description does compensate by describing the response layout (market-overview block first, then ranked indices with ins_code). It could say more about what the ranking actually returns per index, but an agent has enough to call it and interpret the result.

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

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

Schema coverage is 100% and the enum values and defaults are fully documented in the schema, so this is the baseline case. The description reinforces the ranking concept ('by return') but adds no format or semantics the schema doesn't already carry.

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: 'Show the Tehran and Farabourse market summary and rank the 65 market and industry indices by return.' The scope (65 indices, ranked by return) plus the market summary distinguishes it cleanly from fp_index_history and fp_industries.

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

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

Gives concrete trigger phrasings ('how is the bourse today', 'which industries are up this year', 'what is the total index') and an explicit handoff rule: pass the ins_code to fp_index_history for daily values. The boundary between this tool and its closest sibling is stated, not inferred.

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

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

The annotations already establish read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful scope beyond annotations: the ranking is based on the last trading day and can be ordered by value, volume, or trade count.

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 action and metrics, then gives a focused usage example and alternatives. It is short and every sentence contributes useful routing information.

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

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

For a simple two-parameter read-only ranking tool, the description supplies the temporal scope, ranking dimensions, and sibling routing. It does not spell out the exact response shape, but the output is strongly implied and no output schema exists to rely on.

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

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

Schema coverage is 100%, so both parameters are already documented in the input schema. The description echoes the sort metrics but does not add syntax, defaults, or limit behavior beyond what the schema provides.

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

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

The description uses a specific verb and resource: "Rank the stock-market industries by trading on the last day." It also names the three ranking metrics, so the agent can distinguish this tool from siblings like fp_stocks and fp_indices.

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 a clear use case, "which industries had the most money flowing today," and routes follow-up detail requests to fp_stocks(industry=...) and fp_indices(query=...). It does not explicitly state when not to use the tool, but the context and alternatives are clear.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds real behavioral value by disclosing that avg_annual_return_pct only covers funds older than one year, a data-quality caveat unavailable anywhere else. It does not discuss ordering ties or result volume, which keeps it from a 5.

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

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

Three short sentences, each earning its place: what it returns, when to use it with the follow-up call, and one data caveat. The core purpose is front-loaded and nothing is redundant.

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

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

With no output schema, the description names the returned fields (AUM, fund count, typical return), which is the key omission it needed to fill. Only minor gaps remain, such as default/max result count and tie-breaking in the ranking.

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 'limit' (managers to return, 1-40) and 'query' (partial name filter with an example) are already documented in the schema. The description adds the downstream handoff of a manager name to fp_search_funds, but says nothing about limit behavior beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Rank fund management companies by total assets under management') and names the exact fields returned (fund count, typical return). An agent can distinguish it from fp_search_funds, which searches individual funds, without opening either schema.

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

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

Gives a concrete triggering question ('which companies run the most funds') and an explicit chaining instruction: 'Pass a manager name from here to fp_search_funds(manager=...)'. It stops short of naming exclusions or the other siblings (fp_fund_types, fp_compare), so it is strong but not complete routing guidance.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), so the description's job is to add semantics — and it does, disclosing that returns are percent, size is billion Toman, and each row carries reg_no and group_id. It does not mention the 50-row ceiling or whether results are paginated beyond the schema's limit, which keeps it from a 5.

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

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

Two tight paragraphs: the capability and ranking axes come first, then usage triggers, then the hand-off to sibling tools and unit definitions. No sentence is redundant against the schema.

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

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

With no output schema, the description still tells the agent the key returned fields (reg_no, group_id) and the unit conventions for numeric columns, which is enough to chain calls. It does not enumerate the remaining row fields (name, ticker, manager, age) or mention the row-limit default/ceiling, a minor gap for a 10-parameter search tool.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds unit semantics for the ranking columns ('Returns are percent; size is billion Toman') that the schema does not spell out globally, plus the chaining meaning of reg_no/group_id. The min_age_years caveat about young funds is in the schema, not repeated here.

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 pair (search and rank) against a named resource (Iranian mutual funds and ETFs) plus the filter dimensions (name, type, manager) and ranking basis (return or size). It also distinguishes itself from siblings by naming fp_fund, fp_history, fp_compare as downstream consumers of its rows.

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

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

Gives concrete natural-language triggers ('best fixed income funds this year', 'biggest gold funds', 'funds managed by X') that map directly onto sort_by/fund_type/manager parameters, and tells the agent what to do next with the returned reg_no/group_id. It also points to fp_fund_types for the full type enumeration.

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, openWorld and non-destructive, so safety is covered. The description adds genuinely non-obvious behavior: prices are denominated in rial, the 5-level order book and retail vs institutional counts are last-published (staleness caveat), and history rows are newest first. Missing are any rate limits or coverage caveats for unlisted/suspended symbols.

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

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

Front-loaded with the capability and its payload, then usage, then units and caveats, then the optional parameter — a sensible order with no filler. The opening field list is long but each item is informative about the return shape, which matters given there is no output 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?

With no output schema, the description carries the burden of describing return content, and it does so field-by-field while also stating units and sort order. It is close to complete; only the interaction with the fp_history sibling and any cap on history_days beyond the schema's 250 maximum remain unaddressed.

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

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

Schema coverage is 100%, so both parameters are already documented, and the description largely restates history_days. It does add two useful details not in the schema: the rial price unit (a property of the symbol data, not a parameter) and the newest-first ordering of returned OHLC rows. That is only marginal parameter-level value above the high-coverage schema baseline.

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

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

States a specific verb and resource ('Get one listed share') and enumerates the returned content: last trade, range, order book, buyers/sellers, period returns, industry. The singular 'one ... share' plus the explicit pointer to fp_stocks distinguishes it from the sibling list tool without needing the schema.

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

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

Gives a clear triggering condition ('Use after fp_stocks or when the user names a ticker'), which routes the agent from the list tool to this one. It stops short of an explicit exclusion, though: the sibling fp_history exists and the description never says when to prefer fp_history over the history_days parameter here.

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, and the description adds behavior the annotations cannot: prices are in rial, value in billion Toman, and shares that did not trade are excluded from results. With no output schema, the note that each row carries ins_code and symbol is also material to correct downstream use.

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

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

Three tight sentences, front-loaded with scope and followed by usage examples and one unit/exclusion caveat. No sentence is reusable boilerplate; each adds either routing or output-shape information.

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

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

Six optional parameters, no output schema, and the description compensates by explaining return row identity (ins_code, symbol), units, and the exclusion of untraded shares. Nothing an agent needs to call or interpret this tool is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by linking parameters to other tools — symbol feeding fp_stock and the industry value being resolvable via fp_industries. It stops short of restating sort/limit semantics, which the schema already handles well.

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

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

States a specific verb (search and rank) and resource (listed shares traded on the last trading day) with the ranking modes named: gainers, losers, most traded, by industry. It also distinguishes itself from siblings by directing ticker lookups to fp_stock and industry names to fp_industries.

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

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

Gives concrete triggering queries ("biggest gainers today", "most traded banks", "find the ticker of X") and explicitly routes the agent onward: pass the returned symbol to fp_stock for a full quote. The alternative and the handoff condition are both stated, not inferred.

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