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

The annotations already declare that this is a read-only, idempotent, non-destructive, open-world operation, so the safety profile is covered. The description adds useful content details about what the profile includes, but it does not disclose other behavior such as response format, rate limits, or authentication requirements.

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 core resource and then lists the key fields returned. There is no redundant wording or unnecessary preamble.

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 read-only profile lookup, the description provides enough context about the returned fields, and the schema fully documents the input. The lack of output schema is mitigated by the field list, though a note about resolving unknown symbols via search_symbol would make it more 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?

Schema description coverage is 100%, and the single symbol parameter is fully documented in the schema as accepting a Persian symbol or insCode. The description itself adds no parameter-level meaning beyond that, so the baseline score is appropriate.

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

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

The description clearly states that this returns an issuer profile from Codal and lists the fields included: CEO, ISIC, address, and activity description. It is specific about the resource and contents, though it does not explicitly contrast itself with sibling tools such as codal_filings or symbol_overview.

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 explicit guidance on when to use this tool versus alternatives. An agent can infer that it retrieves company profile data, but there are no stated conditions, exclusions, or references to sibling tools like search_symbol for resolving symbols or codal_filings for filings.

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 a read-only, idempotent, non-destructive, open-world operation. The description usefully adds expected result content, including publish time, tracing number, and page/PDF/Excel/attachment links, but gives no further context about pagination, default date behavior, availability of files, or external-source limitations.

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 front-loads the action and resource, then efficiently lists the principal returned fields. There is no filler or redundant explanation.

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?

Together with the annotations and mostly documented schema, the description is sufficient for a basic invocation and partially compensates for the missing output schema by listing result contents. It remains incomplete for more confident use because it omits sibling differentiation, default search scope, pagination behavior, and guidance for opaque category and letter-type identifiers.

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 description adds no parameter-specific meaning beyond the schema. With 75% schema coverage, most filters and date formats are already documented, while the description does not help explain category or letter-type IDs, pagination, or how the filters interact.

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—"Search Codal disclosures"—and identifies the returned metadata and document links. It clearly concerns regulatory filings rather than general market data, but does not explicitly distinguish itself from the closest sibling, codal_company.

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: choose this tool when searching Codal disclosure filings. There is no explicit guidance on when to use it instead of codal_company or other siblings, nor any exclusions or recommended filtering workflow.

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 the tool as read-only, idempotent, open-world, and non-destructive. The description adds that results include dates and factors, but it says nothing about data source, coverage limits, or the response shape beyond that.

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 with the resource front-loaded, and the bilingual Persian terms are useful for matching domain vocabulary. The phrase 'with dates and factors' is slightly vague but still earns its place by indicating included data fields.

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?

This is a simple one-parameter read tool whose schema and annotations are already complete. The description covers the data domain well enough to invoke it, though it could clarify what 'factors' means or whether dates are historical or upcoming.

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 symbol parameter is already documented as a Persian symbol or insCode. The description does not add any parameter-specific meaning, so the baseline score of 3 is appropriate.

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

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

The description names the resource clearly and specifies the two relevant corporate-action types, capital increases and price adjustments. It lacks an explicit verb and does not name a sibling alternative, but no sibling appears to cover corporate actions, so the tool is still distinguishable.

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

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

Usage is implied by the resource: an agent should use it when it needs corporate-action data for a symbol. However, the description gives no explicit when-to-use guidance, no exclusions, and no direct comparison to sibling tools such as price_history or symbol_overview.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. Beyond that the description adds nothing behavioral: it does not say whether non-ETF symbols error or return empty, whether values are real-time or end-of-day, or what units the premium/discount is expressed in. With the conceptual framing being the only contribution, transparency is thin.

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 short clause with no filler and the key concept (premium/discount, NAV vs market price) front-loaded. It loses a point only because the fragment form omits a verb, making it less immediately actionable than a full sentence would be.

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 (one required parameter, no nesting), but there is no output schema, so the description carries the burden of saying what comes back — NAV value, market price, premium percentage, timestamps — and it does not. It also doesn't note the ETF-only applicability, which is the most likely source of misuse given the many non-ETF symbol siblings in the toolset.

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 single symbol parameter is already documented with a Persian example ('فولاد') plus the insCode alternative. The description adds no parameter meaning and does not repeat that restriction, which is fine, but it also does not clarify whether sym/insCode typed input behaves identically. Baseline 3 applies when the schema does all the work.

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 distinct resource — fund/ETF NAV versus market price, expressed as premium/discount with the Persian terms صدور و ابطال — which clearly separates it from quote, order_book, and other pricing siblings. However, there is no verb: it reads as a topic label rather than a statement of what the tool returns or computes, so the agent must infer that calling it yields NAV and premium/discount figures.

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

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

There is no when-to-use guidance, no statement that this only applies to ETF/fund symbols rather than ordinary equities, and no mention of alternatives. The parenthetical 'صدور و ابطال' hints at the issuance/redemption use case but is left implicit rather than spelled out as a selection condition.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only that the tool exists to make terminology correct in answers; it says nothing about whether an unknown term errors or returns an empty result, or whether definitions are curated locally or fetched externally (notable given openWorldHint=true).

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

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

A single front-loaded sentence with the purpose stated first and the rationale second; no filler. The parenthetical example list is the only mild expansion, and it earns its place by disambiguating the term vocabulary.

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-optional-parameter read-only tool with annotations covering safety, the definition is nearly sufficient. The remaining gap is that there is no output schema, yet the description never indicates what a lookup returns (definition text, translations, usage notes) or the list-all behavior when the term is omitted.

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% — the schema already states 'Persian or English term; omit to list all'. The description's contribution is listing example Persian terms, which usefully signals that Persian input is expected, but it adds no matching, casing, or partial-term behavior 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 gives a specific verb ('Explain') and a specific resource (Iranian market terms), with concrete example terms (صف خرید، سرانه خرید، حقیقی/حقوقی، دامنه نوسان) that pin down the domain. No sibling tool in the list provides glossary/definition content, so the tool is distinguishable in practice even though no sibling is named explicitly.

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

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

Usage is only implied by the trailing clause 'so answers use them correctly' — an agent can infer it should call this when it encounters Persian market jargon it may misrender. There is no explicit statement of when to call it, when not to, or what to do if a term is missing.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so safety is fully covered. The description does add one genuinely useful behavioral detail — results are expressed in index points and include both upward and downward contributors — but it says nothing about ordering, how many are returned by default, or the index scope, and no output schema exists to fill that gap.

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

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

One front-loaded sentence that states the semantics first and appends a Persian synonym, which plausibly aids matching for a Persian-language data source. No filler, though the parenthetical duplicates the concept rather than extending it.

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 single-parameter, no-output-schema tool this is close to adequate, but an agent still cannot tell the sort order, whether positive and negative contributors are interleaved or split, or what the limit applies to. Those gaps are small but real for a tool whose whole value is a ranked list.

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

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

Schema description coverage is 0%, and the description never mentions the single 'limit' parameter, so nothing in prose explains whether it caps contributors per direction or overall. The schema does carry a default of 15 and a max of 60 structurally, which keeps this from being a 1, but the description adds no compensating meaning.

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

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

The description names a specific output resource: stocks that move the total index the most, measured in index points. That is concrete enough to distinguish it in substance from a generic movers list, though it never explicitly contrasts itself with the sibling top_movers, so the agent has to infer the difference.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no naming of an alternative such as top_movers or market_overview when the agent wants plain price change rather than index-point contribution. The agent must guess the selection condition from the tool 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 already declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds only the content scope (all index types plus industry indices with change %), with no notes on payload size, the ~50 industry indices mentioned only in the schema, or freshness of the data.

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

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

A single front-loaded sentence that lists the index categories and the returned metric, with a bilingual gloss and no wasted wording. It is appropriately sized for a simple, two-parameter read 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?

For a low-complexity, no-output-schema read tool with fully described optional parameters and annotations covering safety, the description is nearly sufficient. The remaining gap is that it does not mention the market switch or clarify how it overlaps with the industry_summary sibling.

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

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

Schema description coverage is 100%, so both parameters (market and only_headline) are already documented. The description's mention of 'every industry index' loosely relates to only_headline but adds no syntax, defaults, or meaning beyond the schema, so the baseline 3 applies.

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

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

The description names the specific resource (all indices: total, equal-weight, free-float, and every industry index) and what each carries (change %), so an agent can tell it returns index data. It does not explicitly distinguish itself from sibling tools like industry_summary or market_overview, which is the only gap.

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

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

There is no when-to-use, when-not-to-use, or alternative-tool guidance. The agent is left to infer from the name and description whether this is the right tool versus industry_summary or market_snapshot.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered by structured data. The description contributes by revealing the computed content (cap-weighted change, index effect, queue counts), which matters because there is no output schema, but it says nothing about freshness, market-hours dependency, or whether omitted industries are dropped or zero-filled.

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

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

A single dense sentence with the resource announced first and the metrics listed after, with no filler or repetition. It is slightly list-like and the parenthetical Persian term is unexplained, but nothing is wasted.

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

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

For a one-optional-parameter read tool with no output schema, the description carries the necessary burden by naming the returned measures, so an agent knows what a call yields. Remaining gaps are minor: it does not state the response structure (per-industry rows) or whether the market parameter changes the set of industries returned.

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

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

There is a single optional parameter and schema coverage is 100%; the schema itself spells out 'bourse', 'fara', and the omit-for-both default. The description adds no meaning beyond that and does not even mention the market selector, so it sits at the baseline where the schema does all the work.

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

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

The description names a specific resource ('per-industry breakdown') and enumerates the concrete measures it returns: traded value, average and cap-weighted change, index effect, and queue counts. That is far more specific than a tautology and clearly separates it from market-level siblings such as market_overview or indices, though it never names those siblings explicitly.

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

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

Usage is only implied: the phrase 'per-industry breakdown' suggests this is the tool for industry-level aggregation rather than per-symbol or whole-market views, but there is no statement of when to prefer it over market_overview, indices, or trade_summary, and no prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the 5-reported-day window, the market-wide scope, and that results are ranked by magnitude of position change. It does not say whether the result list is sorted, how many rows come back by default, or how the '5 reported days' window is anchored.

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 with the scope and time window front-loaded and no filler. The parenthetical Persian term adds redundant length for non-Persian readers but does not obscure the meaning.

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 tool with full annotations and no output schema, the description covers purpose, scope, and window adequately. It still leaves the caller guessing about result ordering, result size vs the undocumented limit, and the shape of returned fields, which matters more because there is no output schema.

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

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

The schema has 0% description coverage for the single parameter 'limit' (default 30, max 200) and the description never mentions it, so an agent gets no guidance on what limit caps. The phrase 'changed most' hints at ranking/truncation but does not explain the parameter.

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

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

States a specific resource (large holders) and a specific behavior (positions that changed most) over a concrete window (last 5 reported days), scoped market-wide. This distinguishes it from the symbol-level siblings shareholders, shareholder_history, and shareholder_portfolio, though it never names them explicitly.

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

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

Usage is implied by the scope: use it to see market-wide large-holder position changes for the recent 5-day window. There is no explicit when-to-use/when-not guidance and no mention of the sibling shareholder tools an agent might otherwise pick, so routing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, covering the safety and idempotency profile. The description adds essentially nothing behavioral beyond that – no data freshness, caching, or scope notes that would help an agent interpret open-world live market data.

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

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

It is a single compact sentence with no wasted wording. The enumeration is dense but front-loaded, though the trailing Persian gloss adds little for an agent that already has 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 simple, annotation-covered, single-parameter read tool with no output schema, listing the returned metrics is close to sufficient. However, with many similar market-level siblings, the definition should say what this tool uniquely covers and which market values are valid in context, so it is adequate but not 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?

Schema description coverage is 100% and the single 'market' parameter is fully documented as 'bourse' or 'fara' in the schema. The description only restates 'for the market', adding no semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

The description enumerates the metrics returned (index value, equal-weight index, value/volume/trades, market cap), which tells an agent roughly what data comes back, but it omits a verb and doesn't distinguish this from overlapping siblings such as market_snapshot, market_status, or indices. An agent would have to guess which market-level tool to pick.

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

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

There is no when-to-use guidance at all – no mention of when market_overview is preferable to market_status, market_snapshot, or indices. The only clue is the parenthetical Persian label, which restates the tool name rather than routing the agent.

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 results are end-of-day rather than intraday and are scoped to a past date, but it leaves a tension unexplained: 'every instrument' versus a schema default limit of 30 (max 300), leaving the agent unsure whether the response is truncated by default.

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 front-loaded sentence with the resource and scope stated immediately, followed by a bilingual gloss. The Persian parenthetical is a faithful duplicate rather than new information, so it is mild padding, but the sentence is otherwise efficient.

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, one required, no output schema and modest annotation detail, the definition should clarify what a 'table' row contains (price, volume, change) and how limit interacts with the 'every instrument' claim. It orients the agent adequately but omits those operational details.

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 75% – date and sort_by are documented, limit and security_type are weakly or only partially described – so the schema does most of the work. The description reinforces that the date must be a past trading day but adds nothing about limit truncation, sort semantics, or the stock/fund/bond filter 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 concrete deliverable: an end-of-day table covering every instrument for a specified past date, which tells an agent this is a cross-sectional, single-day snapshot. It stops short of naming or excluding siblings such as market_overview, market_watch or price_history, so the distinction must be inferred from the 'every instrument / one date' scope.

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

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

The only guidance is the implicit constraint 'on a past date' – useful, since it tells the agent not to use it for live data. There is no explicit when-to-use, no stated alternative for current-day or per-symbol queries, and no prerequisites such as needing a valid trading day.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds value beyond that by disclosing what the response contains — Tehran time, session hours, bourse state, and totals — which matters because there is no output schema. It stops short of stating data freshness or whether the 'totals' are intraday or end-of-session figures.

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 clauses: a front-loaded question that states the purpose, then a compact enumeration of returned fields, plus the Persian name for local users. No filler. The field list is slightly telegraphic ('bourse state and totals') and would read better with a connector, but nothing is wasted.

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

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

With zero parameters, no output schema, and a simple read-only nature, the definition supplies nearly everything needed: the timezone framing, the session-hours concept, and the shape of the returned state. The only gap is that it does not say how fresh the status is or whether it reflects pre-market/auction phases, which for a market-clock tool is a modest omission rather than a blocking one.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The description correctly implies the caller supplies no arguments — the market's state is determined server-side.

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 question — 'Is the Tehran market open right now?' — which names the resource (Tehran market) and the exact fact being reported (open/closed state). It then enumerates the payload (Tehran time, session hours, bourse state, totals), so the agent knows this is a status check rather than a data dump. It does not explicitly contrast itself with close siblings like market_overview or market_snapshot, which keeps it from a 5.

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

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

Usage is only implied by the phrasing: an agent can infer 'call this when you need to know whether the market is currently trading.' There is no explicit when-not guidance and no mention of the alternative siblings (market_overview, market_snapshot, market_watch) that also surface market-level state. Minimum viable for a zero-parameter read tool, but routing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds only a light behavioral hint ('in one call' implying a single-shot bulk read) and says nothing about data freshness/latency, how paging works, or how the default filters (only_traded=true, descending=true) shape the result set.

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 that identifies the tool immediately and wastes no words; the parenthetical Persian term is useful for domain matching. It is arguably under-specified rather than over-long, so nothing needs cutting.

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 10-parameter tool with no output schema, the description does not indicate what a result row contains or what 'compact' vs 'full' changes in the response shape, leaving the agent to infer the return payload entirely from schema prose. It does establish scope (whole market, all instruments) correctly, so the gap is moderate rather than fatal.

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

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

With 10 optional parameters and 70% schema description coverage, the schema already explains board, market, industry, security_type, sort_by and detail, including examples. The description's 'filter, sort and page' only loosely maps to those parameter families and adds no format, unit, or interaction detail (e.g., how limit interacts with the 700 cap) beyond the schema. Baseline 3 is appropriate.

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

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

The description names a specific verb set (filter, sort, page) and a precise resource (every listed instrument / whole-market screen), plus the Persian domain term دیده‌بان بازار. It is clearly distinct from quote, order_book, or symbol_overview, but does not differentiate itself from close siblings such as market_snapshot or market_overview, which could also be read as whole-market views.

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

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

Usage is implied by 'whole-market screen ... filter, sort and page' (i.e., use this when you need a ranked/filtered list of all symbols rather than a single quote), but there is no explicit when-to-use, when-not-to-use, or named alternative among the 27 siblings. An agent must infer that top_movers or market_snapshot are the narrower choices.

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 genuinely new behavioral context by enumerating the payload contents: five depth levels, order counts, imbalance, and buy/sell queue detection, which tells the agent what signals it will get. It stops short of disclosing snapshot freshness, market-hours behavior, or latency.

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

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

A single front-loaded sentence with no filler: the depth level, the added metrics, and the Persian domain terms are all packed in without 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 one-parameter, read-only market-data tool with no output schema, the description is nearly complete because it enumerates the returned fields. The remaining gap is whether the book is a live snapshot or delayed and how it behaves outside trading hours.

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 single symbol parameter is fully documented in the schema, including the Persian-name-or-insCode alternative. The description adds nothing about symbol semantics, so the baseline 3 applies.

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

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

The description gives a specific verb-less but precise resource statement: a five-level order book with order counts, imbalance, and buy/sell queue (صف) detection, and it distinguishes itself implicitly from shallower siblings such as quote by naming the five-level depth and from order_book_history by omitting history. It never names a sibling explicitly, so it falls short of a 5.

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

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

There is no explicit when-to-use guidance and no mention of alternatives such as quote (top of book) or order_book_history (historical depth). The agent must infer that this tool is for current market-depth analysis with queue/imbalance signals, which is implied by the content list but never stated as a selection rule.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuine content-level context beyond that — data is event-rebuilt rather than snapshot, sampled at intervals, and includes queue episodes with peak sizes. It stops short of disclosing data volume, whether empty windows or non-trading days return errors, or how the sampled series is bounded, which matters for a potentially large intraday pull.

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 that leads with the resource and follows with the payload contents, with no filler. The parenthetical Persian alias is a compact disambiguation aid rather than padding. Slightly dense, but 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 5 parameters, a single required field, rich annotations and no output schema, the description does the necessary job of telling the agent what the returned data represents (sampled depth plus queue episodes with peak sizes). Residual gaps are around result size and edge-case behavior for empty or out-of-session windows, which are secondary for a read-only query tool.

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

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

Schema description coverage is 100%, so formats for date (Gregorian/Jalali), symbol (Persian name or insCode), from_time/to_time and step_seconds are already fully documented in the schema. The description only loosely echoes 'sampled depth', which hints at step_seconds, and adds no meaning beyond what the schema supplies; 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?

The description names a specific resource ('intraday order-book evolution') and a specific mechanism ('rebuilt from every event'), then enumerates contents: sampled depth and buy/sell queue episodes with peak sizes. It implicitly contrasts with the snapshot-style sibling 'order_book' but never names it, so sibling differentiation is left to inference.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no sibling is named as an alternative. An agent must infer from 'Intraday ... evolution' that this is the historical/reconstructed variant rather than the live 'order_book' snapshot, which is a reasonable but unstated 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, idempotentHint=true, and destructiveHint=false, so the description only needs to add context. It adds the full-history scope ('since listing') and the adjustment semantics, but says nothing about ordering, pagination/truncation under the 5000-row limit, or what happens when the requested range exceeds available history.

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 short sentence with the core resource front-loaded, plus a bilingual gloss. Nothing is wasted, though 'since listing' is slightly misleading next to a limit default of 250 and optional date bounds.

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

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

For a five-parameter historical-data tool, the description covers what the data is (daily OHLCV) and the adjustment option, which is the essential framing. It leaves the default-window behavior and the interaction between limit and date ranges unaddressed, so an agent must infer retrieval scope from the schema alone.

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 80%, so the schema already explains symbol formats, date formats, and the adjustment flag in detail. The description's 'optionally adjusted' merely restates the adjusted parameter, and it adds no meaning about limit, from_date, or to_date beyond what is structured.

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

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

The description names a specific resource and granularity: daily OHLCV history, plus the adjustment option. That is clearly distinct from siblings like quote, trades, or order_book_history, though no sibling is named explicitly.

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

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

Usage is only implied: the word 'history' plus 'since listing' signals retrospective daily bars, so an agent can infer this is not for real-time quotes. There is no explicit when-to-use/when-not guidance or routing to alternatives such as trades for intraday data.

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 a safe, read-only, idempotent open-world operation, while “Live/last” adds some freshness context. The description does not clarify when a live quote versus a last quote is returned, or whether data can be delayed outside trading hours.

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 compact and front-loaded with the tool’s purpose, followed by a useful inventory of included metrics. The Persian parenthetical is brief and relevant to the tool’s symbol conventions.

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 one-parameter read tool, the input schema, safety annotations, and enumerated quote metrics provide enough information to invoke it correctly. With no output schema, the field list is valuable, though precise live/last behavior and sibling differentiation remain gaps.

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 symbol parameter already explains that either a Persian symbol or an insCode is accepted. The description adds no parameter meaning beyond that complete schema, so the baseline score 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?

The description clearly identifies a live/last quote and lists concrete outputs such as change percentage, VWAP, price limits, P/E, and market cap. It does not explicitly distinguish this current-quote view from siblings such as symbol_overview or market_snapshot.

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

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

“Live/last quote” implies that the tool is for a current or most recent pricing snapshot. There is no explicit guidance on when to prefer it over symbol_overview, market_snapshot, trades, or price_history.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds value by disclosing the shape of the result (counts, per-capita, buyer power, net money flow) and that daily history is included, but says nothing about units, rate limits, or data-source behavior.

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

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

A single front-loaded sentence with no filler; the metric list is the payload. It is slightly dense with undefined domain jargon ('per-capita', 'buyer power'), which costs it a point.

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

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

With only two well-documented parameters, rich annotations and no output schema, the definition is nearly adequate. The gap is that key output concepts ('buyer power', 'per-capita') are never defined or given units, which matters for an analysis tool an agent must interpret results from.

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%: 'days' is documented with default, min/max and the 0 = latest session semantics, and 'symbol' explains Persian names or insCode. The description adds no meaning beyond that beyond loosely implying the daily history corresponds to 'days', so the baseline 3 applies.

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

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

The description names the specific resource (real vs legal / حقیقی و حقوقی buying and selling flow) and enumerates the metrics produced: counts, per-capita, buyer power, net money flow. That is concrete enough to separate it from siblings like trade_summary or market_holder_moves, though it never explicitly names a sibling 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?

There is no when-to-use or when-not-to-use guidance and no mention of alternatives such as symbol_statistics or trade_summary. The intended use (retail vs institutional flow analysis) must be inferred entirely from the metric list.

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

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

Annotations already declare read-only, idempotent, open-world and non-destructive behavior, so the safety profile needs no restating. The description usefully lists the returned fields in place of an absent output schema, but says nothing about the result cap (limit defaults to 15, max 50) or what happens on zero matches, which matters for a lookup 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?

One front-loaded sentence that states purpose, search basis, and return shape with no filler. The Persian alias in parentheses is the only extra, and it aids matching for bilingual queries.

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

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

For a two-parameter read-only search with rich safety annotations, the definition is nearly sufficient: it compensates for the missing output schema by naming return fields. The remaining gap is limit behavior and match semantics (exact vs substring, ranking), which an agent would need to call it optimally.

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 and it only partly does: 'symbol or name fragment' clarifies what query accepts, but limit is never mentioned (its default and 50-cap exist only in the schema constraints). The query clarification is the main added value.

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

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

The description gives a specific verb and resource ('Find instruments') plus the search basis ('symbol or name fragment'), and it enumerates what comes back (symbol, name, market, board, insCode). It is distinguishable from data-fetching siblings like quote or symbol_overview, though it never names them to sharpen the boundary.

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

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

There is no explicit when-to-use statement, no prerequisite, and no alternative named. The only hint is the implicit 'you have a fragment, not an exact identifier' framing, leaving the agent to infer that this is a resolution step before calling symbol_overview or quote.

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 real value by disclosing that results are multiple dated snapshots and that deltas are computed between them — the only signal about return content, since there is no output schema. It stops short of stating how many snapshots are returned, how far back history goes, or pagination behavior.

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

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

One front-loaded sentence with no filler, and the key qualifier ('dated', 'with computed changes') arrives immediately. It is arguably too terse for a history tool, but nothing is wasted.

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

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

The tool is simple (2 params, both fully documented, no nested objects), so the description only needs to clarify the return shape — which it does only partially. It never defines what the 'computed changes' measure (share count, percentage, ranking shift) or whether the response is a list of snapshots, leaving a meaningful gap on the history dimension.

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

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

Schema description coverage is 100%, so the schema already explains the Jalali/Gregorian date formats, the omit-for-latest default, and the symbol/insCode convention. The description adds no parameter meaning beyond that, which is the expected baseline when the schema is this complete.

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

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

The description names a specific resource ('major-holder snapshots') with a clear scope modifier ('dated', 'for a symbol') and an added computation ('changes between snapshots'). It is clear what the tool returns, though it never distinguishes itself by name from the lookalike siblings 'shareholders' and 'shareholder_portfolio', which an agent must infer is the non-historical counterpart.

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

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

Usage is only implied: 'history' plus 'changes between snapshots' suggests this is for trend/ownership-change analysis rather than a current snapshot, which is presumably what 'shareholders' provides. There is no explicit when-to-use, when-not-to-use, or named alternative, so selection against the sibling shareholder tools relies on 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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. Beyond that the description adds nothing: no indication of what the portfolio response contains, whether it is per-symbol or market-wide, or how the open-world scope is resolved. With the lower bar set by annotations, this still leaves the behavior opaque.

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 with no waste, but it is under-specified rather than efficient: 'Everything else' is undefined and the sentence is not front-loaded with a clear verb. Length is fine; substance is thin.

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 lookup with no output schema and no annotations explaining return shape, the description should say what a portfolio here comprises (symbols, quantities, values, status) and confirm the market-wide scope. 'Everything else' leaves the agent guessing about the result set and its boundaries.

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% with a single required holder_id already documented as coming from 'shareholders', so the baseline of 3 applies. The description contributes no additional meaning about the parameter, but the schema carries it fully.

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?

It names a resource (a major holder's holdings across the market, with the Persian gloss پرتفوی سهامدار) but the verb is implicit and the framing 'Everything else that major holder owns' is relative to something unstated. An agent cannot tell from this text how it differs from the sibling tools 'shareholders' and 'shareholder_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?

There is no when-to-use guidance, no exclusion, and no mention of the natural alternatives (shareholders, shareholder_history, market_holder_moves) that an agent would need to choose between. The only hint is that the holder id should come from 'shareholders', which lives in the schema, not the description.

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

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

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered externally. The description adds useful output context (the fields returned and the holder_id hook), but says nothing about whether this is a current snapshot versus historical data, how many holders are returned, or ordering.

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 resource and then the return fields, with the bilingual term aiding symbol lookup. The trailing 'for deeper lookups' is slightly vague and could be tightened to name the intended follow-up 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?

With no output schema, the description carries the burden of describing returns, and it does list the key fields plus the holder_id linkage. For a single-parameter read tool it is nearly complete; only the snapshot-vs-history question and result scope remain unstated.

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

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

Schema description coverage is 100% and the single symbol parameter is documented with concrete examples ('فولاد' or an insCode). The description adds no meaning beyond the schema, so the baseline of 3 is appropriate for a one-parameter tool where the schema does the work.

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

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

The description names a specific resource (major shareholders, with the Persian term for matching) and enumerates the returned fields: shares, percent, holder_id. It is clear what the tool does, but it does not differentiate itself from siblings like shareholder_history, shareholder_portfolio, or market_holder_moves, which an agent could easily confuse with 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?

Usage is only implied through the required symbol parameter; there is no explicit when-to-use or when-not-to-use guidance, and no named alternative. The phrase 'for deeper lookups' hints at a follow-up tool using holder_id, but it never names that tool, so the chaining guidance is suggestive rather than actionable.

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

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

Annotations already establish a read-only, idempotent, non-destructive, open-world operation, and the description adds content-scope context through its notice categories. It does not explain freshness, ordering, limit behavior, or whether full_text controls truncation, leaving operational transparency thin.

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 single compact phrase is front-loaded with the resource and uses the colon effectively to list representative notice types. The bilingual parenthetical is potentially useful for this domain, and there is 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 simple four-parameter read tool, the description and annotations are sufficient to infer a basic call, especially since symbol and market have schema guidance. With no output schema, however, the absence of retrieval scope, recency or ordering, result-format context, and full_text semantics leaves noticeable gaps.

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 documents market and symbol, but limit and full_text have only titles, types, and defaults, and the description adds no parameter guidance. In particular, it never explains what full_text changes or clarifies how limit applies, so it does not compensate for the 50% schema description coverage.

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

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

The description identifies a distinct resource, "Exchange supervisor notices," and concretely scopes it to "trading restrictions, clarifications, halts," with a Persian term aiding domain recognition. It does not state an explicit retrieval verb or differentiate the tool from siblings such as codal_filings, so it is clear rather than fully discriminating.

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 listed notice types imply when to use it: when looking for supervisor restrictions, clarifications, or halts. There is no explicit when-not guidance or routing to alternatives such as market_status for current state or codal_filings for company disclosures.

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

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

Annotations already establish that this is read-only, idempotent, open-world, and non-destructive. The description adds useful context that the call aggregates multiple datasets into one dossier, but it does not discuss latency, freshness, payload size, or any limits for such a broad aggregation.

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

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

The definition is just two short sentences, front-loads the core purpose, and wastes no words. The enumerated contents help the agent decide quickly without becoming verbose.

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 broad aggregate tool with no output schema, the description does a good job listing the categories of data returned and signalling that it is the starting point. It leaves some operational details unspecified, such as result freshness or latency, but covers what an agent needs to choose the 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?

There is only one parameter, and the schema fully documents it as a Persian symbol or insCode. The description adds no parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb-and-resource framing ('One-call dossier for a symbol') and explicitly enumerates what the tool returns: identity, quote, order book, flow, shareholders, filings, and notices. This clearly distinguishes it from the many granular sibling tools such as quote, order_book, and codal_filings.

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?

'Start here' gives clear usage guidance that this is the entry-point overview tool rather than a targeted data retrieval tool. It does not explicitly name when to prefer granular siblings or state exclusions, so it stops short of full when/when-not guidance.

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

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

The annotations already establish that the operation is read-only, idempotent, non-destructive, and open-world. The description adds useful provenance by stating that the exchange computes the statistics, but it does not clarify data freshness, coverage, or behavior for invalid 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?

The description is a single efficient statement that front-loads the source, resource, and symbol scope. The parenthetical example adds concrete value without unnecessary wording.

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 one-parameter read tool, the description provides enough information to understand the basic request. However, with no output schema, the broad phrase 'averages and stats' leaves the available metrics and result structure unclear, and sibling boundaries remain unstated.

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

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

The schema fully documents the sole required parameter, including support for Persian symbols and insCode values. The description adds no further parameter meaning, so the high schema coverage supports the baseline score.

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 identifies the resource and operation: retrieving exchange-computed averages and statistics for a symbol, with a concrete example. It does not distinguish these statistics from sibling tools such as symbol_overview or trade_summary.

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 for agents seeking exchange-computed symbol averages rather than raw quotes or trades. There is no explicit guidance about when to prefer this tool over symbol_overview, trade_summary, or price_history.

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, open-world behavior, so the safety profile is covered. The description adds that results are ranked lists (implying ordering by magnitude) but does not disclose sort direction, tie-breaking, whether an empty market returns empty results, or any data-freshness caveats.

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 dense sentence that front-loads the core concept and then enumerates modes; no filler. The bilingual Persian glosses cost tokens but plausibly help matching Persian-language queries, so they earn their 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 multi-mode ranked-list tool with no output schema, the description covers the mode space adequately and the schema covers the remaining parameters. It stops short of explaining how mode selection affects result shape or what a 'buy_queue'/'real_buyer_power' row actually contains, which would matter for a tool with this many distinct modes.

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 75%, so the schema carries most of the burden. The description does add real meaning to the 'kind' parameter by mapping modes to concepts (e.g. 'most traded' covering value/volume/trades, and the Persian aliases for queues and real-money flow), but it says nothing about 'market', 'security_type', or 'limit' beyond what the schema states.

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

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

The description names a specific resource class ('ranked lists') and enumerates the concrete modes it returns: gainers/losers, most traded, buy/sell queues, real-money inflow/outflow, buyer power. That enumeration lets an agent distinguish it from siblings like market_watch or market_snapshot, though it never states the verb explicitly or names those siblings.

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

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

There is no when-to-use or when-not-to-use guidance. The enumerated modes hint at use cases, but overlapping siblings such as real_legal_flow and market_holder_moves are not mentioned, so an agent must guess which tool to pick for money-flow or holder-move questions.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds that results are individual ticks with four fields, which is useful context. However, it says nothing about result truncation (limit defaults to 200, capped at 5000), ordering semantics, or behavior when the requested date has no data.

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

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

Two compact clauses with zero waste; the resource and returned fields are front-loaded and the sibling redirect follows immediately. The Persian term (ریز معاملات) is a justified disambiguation aid for symbol/domain vocabulary.

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 seven parameters, no output schema, and two undocumented parameters (limit, newest_first), the description carries a fair amount of burden. It partially compensates by describing the returned fields, but an agent cannot tell whether a default call returns a truncated sample or the full day's ticks, which matters for correct interpretation.

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 71%, slightly below the high-coverage baseline, so the description ideally should compensate more. 'Filter by time and size' maps to from_time/to_time/min_volume but adds no syntax or semantics beyond the schema, and limit, newest_first and symbol receive no explanation in either place (limit and newest_first have no schema description at all).

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

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

The description identifies the resource precisely as raw tick-by-tick trades and enumerates the returned fields (time, price, volume, value), so an agent knows exactly what it retrieves. It also names the sibling it is not (trade_summary), making the boundary clear. The only weakness is the absence of an explicit verb such as 'retrieve/list'.

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

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

'Filter by time and size; prefer trade_summary for analysis' gives a clear routing rule to an alternative tool for the aggregation case. It stops short of stating the positive trigger (when raw ticks are actually required) or excluding other siblings like price_history or order_book_history, leaving some inference to the agent.

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 the safe-read profile (readOnly, idempotent, non-destructive, openWorld), so the description's job is to add operational nuance, and it does: it flags that tick-rule pressure is an 'estimate' and that results include a 'completeness check against official totals', warning the agent that some figures may be approximate or partial. It does not mention cost or latency for what is likely a heavy intraday aggregation, which keeps it short of full marks.

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

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

A single sentence, front-loaded with the core action and then a compact enumeration of the returned sections. No filler, no restatement of the name, and the listed outputs are exactly the information an agent needs to decide if the tool fits.

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 five parameters, 80% schema coverage and no output schema, the description compensates well by enumerating the returned components in place of a formal output schema. What remains unstated, such as units, formatting, and runtime cost for a full-day aggregation, is minor for a read-only tool.

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

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

Schema description coverage is 80%, with the date, symbol, from_time and to_time parameters already documented in the schema. The description adds only indirect hints: 'a day's ticks' implies the date scope, and 'intraday bars' hints at interval_minutes, but the interaction between from_time/to_time and interval_minutes is not clarified. Baseline 3 is appropriate where the schema does the heavy lifting.

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

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

The description leads with a specific verb and resource ('Aggregate a day's ticks') and then enumerates the exact derived outputs (intraday bars, VWAP, biggest trades, volume by price level, tick-rule pressure, completeness check). That makes it clearly a one-shot aggregation tool rather than a raw data fetch. It never names a sibling, though, so the agent must infer on its own that it differs from 'trades' or 'price_history'.

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

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

Usage is only implied: the agent can infer this tool is for getting a full-day computed summary rather than raw ticks. There is no explicit statement of when to prefer it over 'trades', 'price_history', or 'symbol_statistics', and no prerequisites or exclusions are given.

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