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

With no annotations and no output schema, the description receives the full burden of behavioral disclosure. It does not state that this is a read operation, what the response looks like, or any other behavioral expectations. The noun-phrase description offers only conceptual content, not 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?

The description is extremely concise with no filler. The flow mapping is front-loaded and every word contributes to understanding the 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?

The tool is simple, and the description makes it minimally usable. However, with no output schema or annotations, the return shape, field names, and expected usage context remain implicit. An agent can guess the general purpose but not the exact output or when to prefer this over sibling market tools.

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 only provides an integer range and default, while the description meaningfully maps 1 to bourse and 2 to fara-bourse. This adds real semantic value despite not defining 'fara-bourse' in more detail.

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

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

The description identifies a clear resource: 'Market overview / index values', and the flow parameter adds scope. However, it lacks an explicit verb and does not differentiate from siblings like market_status or get_market_watch.

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

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

No guidance is given about when to use this tool versus alternatives. The flow mapping is parameter information, not usage context or exclusion criteria.

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

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

With no annotations, the word 'snapshot' and 'whole-market' convey that this is a point-in-time read over a broad market scope and that bulk fetching is intended. However, it does not disclose response shape, pagination, or potential side effects, leaving some behavioral burden unmet.

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

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

Two compact sentences carry purpose, scopes, and a usage preference with no filler. The key concept is front-loaded and every clause adds 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 tool with no output schema, the description fails to describe what the snapshot contains, how 'top' limits results, or what 'flow' means; it also references an absent 'market' parameter. The agent cannot reliably construct a correct call from this description 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 0%, yet the description only documents a 'market=' value set that does not match the actual schema properties 'top' and 'flow'. It adds some domain meaning for market segments but leaves both declared parameters essentially unexplained and may mislead an agent looking for a market 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?

The opening phrase 'Whole-market snapshot' gives a clear verb-resource pair, and the parenthetical enumerates the market scopes (all, bourse, fara-bourse, payeh), so an agent can distinguish it from per-symbol tools. It does not explicitly differentiate it from market_status or get_index_overview, but the whole-market watch concept is clear.

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

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

'Prefer this over per-symbol loops' states the intended use case and warns against an inefficient alternative. It does not name sibling tools or state when NOT to use it, so it earns a 4 rather than a 5.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only conveys that the tool returns a money-flow summary, without mentioning time period, data scope, return shape, authentication, or any other behavioral details. This is thin for a tool with no structured metadata.

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 no filler, and the key retail/institutional distinction is placed prominently. It is concise, though it could add a bit more structure around expected output or time period.

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-style tool, the description is adequate but not complete. There is no output schema, and the description does not specify what fields or time range the summary covers, so an agent may call the tool correctly but be unsure how to 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?

The description names insCode as the instrument identifier for the money-flow summary, reinforcing the sole required parameter. However, schema coverage is 0%, and the description does not explain the insCode format or how to obtain it, leaving the agent to infer from context.

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

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

The description clearly states the resource: a money-flow summary for an instrument, split by retail/institutional categories. This distinguishes it from siblings like get_quote or get_order_book. It lacks an explicit verb, but the tool name 'get_' supplies the retrieval action.

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

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

The description implies when to use the tool: when you need retail/institutional money-flow data for an instrument identified by insCode. However, it does not explicitly contrast with sibling tools or state when not to use it.

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

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

With no annotations available, the description carries the full explanatory burden. It usefully discloses the 5-level depth and the buy/sell ordering queue, but it does not describe the response shape, ordering of levels, or any session/authentication requirements. The read-only nature is only weakly implied by the get verb.

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

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

The description is a single front-loaded sentence with no filler. The key detail, 5-level depth, leads directly, and the identifier mechanism follows.

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 lookup the description provides the essential scope and lookup key, but no output schema or return description exists. An agent is left to infer the exact JSON shape and whether any market or session conditions apply, so the context 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 coverage for the single insCode parameter is 0%, so the description must compensate. It only restates that the order book is looked up by insCode, without explaining where this identifier comes from, its format, or how it differs from a symbol/ticker. This is barely more than the property name in 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 clearly identifies the resource as a 5-level order book with buy/sell sides and the lookup key as insCode. It does not, however, contrast itself with sibling tools such as get_quote or get_market_watch, so differentiation is left to the resource name.

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

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

There is no statement of when to use this tool versus get_quote, get_price_history, or get_market_watch. The only implied context is that a caller needs an insCode identifier; no alternative or exclusion is mentioned.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It usefully adds that data comes from a full-market pull and is cached for 1h, which signals freshness behavior. However, it does not mention output structure, error cases, or implications of the cache beyond the time window.

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

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

The description is two short, information-dense sentences with no filler. The core purpose is front-loaded, and the caching note adds relevant context without bloating the text.

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

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

The tool has a simple parameter set, but with no output schema and no annotations, return format and the role of top remain unexplained. The description covers what the data is and its freshness, but not enough for fully confident invocation without inference.

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

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

Schema description coverage is 0%, so the description must compensate for the parameters. It explains that insCode is the instrument identifier, but it never explains the meaning of the top parameter. The schema's default/min/max hints at a count limit, but the agent cannot know what top actually controls.

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 as daily OHLCV history in Rial keyed by insCode, which distinguishes it from get_quote or market_status. It lacks an explicit verb like 'returns' or 'retrieves', but the noun-phrase framing still conveys the tool's output well.

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 word 'Daily' and 'history' imply this is for historical daily data rather than current quotes, but no alternative tool is named and no when-to-use or when-not-to-use conditions are stated. Usage context is present but only implied.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It goes beyond the obvious by revealing that results are 'stamped with freshness: market_open + staleness_seconds,' which tells the agent that quotes may be slightly stale and carry a freshness marker. This is meaningful non-obvious behavior, though it could still mention rate limits, error behavior, or whether it is strictly read-only.

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

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

The description is two short sentences with no fluff. The core purpose is front-loaded, and the freshness detail is concise and relevant. Every word earns its place.

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

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

For a single-parameter tool this is adequate: the agent knows what it gives and that freshness is included. However, without an output schema, the agent is left wondering what fields the quote actually returns, how staleness_seconds is represented, and how to obtain an insCode. It is enough to call if the insCode is already known, but not fully 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 0%, so the description must compensate, but it only restates the parameter name: 'by insCode.' It does not explain what an insCode is, its format, how to obtain it, or that search_symbol could be used to resolve it. The parenthetical '(Rial)' refers to currency, not the parameter semantics, leaving the required parameter under-explained.

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: 'Live quote for an instrument by insCode.' It adds distinguishing details—currency (Rial) and freshness stamping—that separate it from siblings like get_price_history and get_market_watch. This is unambiguous and immediately actionable.

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

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

The description implies when to use the tool—when a live quote is needed—but it does not explicitly mention alternatives or exclusion criteria. It could have noted that get_price_history is for historical data or that search_symbol should be used first to resolve an insCode. The usage context is clear but not explicit enough for a higher score.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states 'Local, no network' (indicating a local calculation with no network dependency) and gives the exact trading hours and timezone. However, it does not mention potential edge cases like holidays or weekends beyond the specified weekdays, nor does it describe the return value (e.g., boolean). This is adequate but not comprehensive for a tool with zero annotation coverage.

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, tightly packed sentence that leads with the core question, then provides the specific schedule and a note about locality. Every word contributes value; there is no fluff or redundancy.

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

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

For a zero-parameter tool with no output schema, the description covers the essential context: the market, the time window, the timezone, and the local no-network behavior. It could be improved by noting that the result is a boolean or by acknowledging holiday handling, but given the simplicity of the operation, the description is nearly complete.

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

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

The input schema has zero parameters and schema coverage is 100%, so there is nothing for the description to add about parameters. Per the rubric, a baseline of 4 is appropriate when there are no parameters to document.

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 ('Is') with a clear resource ('Tehran market') and precise conditions (Sat–Wed 09:00–12:30 Asia/Tehran). It immediately distinguishes itself from siblings like session_status or get_quote by focusing on a single market's open/closed state, so an agent can tell them apart without deeper inspection.

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

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

The description implies when to use it (to check if the Tehran market is open) but does not explicitly state when not to use it or mention alternatives such as session_status, which likely covers a broader market session status. There is no exclusion or routing guidance, leaving some ambiguity for an agent deciding between this and a sibling.

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

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

With no annotations present, the description carries the full burden of behavioral disclosure. It usefully reveals that the session is read-only and that non-GET requests are blocked, but it omits other behavioral context such as how redirects or invalid URLs are handled and what the tool returns.

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

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

The description is a single, front-loaded sentence with no filler. Every phrase contributes meaning, and the critical constraint about non-GET requests is placed clearly.

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

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

For a tool with no annotations and no output schema, this description is too thin. It leaves out the meaning of waitMs, expected return value, prerequisite conditions beyond a 'saved' session, and how failures are surfaced, making it incomplete for an agent to invoke confidently.

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

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

Schema description coverage is 0% and the description adds no parameter-level detail. The url parameter is somewhat inferable from 'open a page', but waitMs is completely unexplained in terms of purpose or effect.

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 action ('Open'), a target resource ('a page on the TSE/TSETMC portal'), and a constraining context ('saved read-only session'). It is immediately differentiable from siblings like page_read, which implies reading content rather than navigating to a page.

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

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

The description implies when to use the tool — to open a page while relying on an existing read-only session — and adds the exclusion that non-GET requests are blocked. However, it does not explicitly name alternatives or state conditions for preferring this tool over page_read or session_status.

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?

No annotations are present, so the description carries the behavioral disclosure burden. It does disclose that the output is readable text, includes tables as text, and is truncated to maxChars. It does not mention error behavior, whether a page must be open, or what happens when no page is open, leaving some behavioral gaps.

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, opening with the core action and resource. The truncation note is useful. It is slightly under-specified, but the brevity is not padding or redundancy.

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

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

For a tool with no output schema, no annotations, and no parameter descriptions, the description is too sparse to be fully actionable. It omits selector semantics, return format details, and failure behavior. An agent may still use it correctly in simple cases, but significant context is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning to maxChars by noting that output truncates to it, but the selector parameter is completely unaddressed, and maxChars' default/minimum/maximum are left to the schema. This is insufficient coverage for a two-parameter tool with no schema descriptions.

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 ('Extract') and specific resource ('currently open portal page'), making the tool's purpose clear. It reads page text, which distinguishes it from sibling tools that retrieve market data or open pages, though it does not name 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?

The phrase 'currently open portal page' implies the tool should be used after page_open, and before other data tools. However, there is no explicit guidance about when not to use it, prerequisites, or how it compares to alternatives such as get_quote or search_symbol.

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?

No annotations exist, so the description carries the full behavioral burden. It does disclose the return content (insCode + market) and implies a read-only search, but it omits details like result count limits, exact result format, or behavior on no-match. Acceptable for a benign search tool, but thin given zero annotation support.

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 packs purpose, query format, examples, and return value with zero filler. Every clause earns its place.

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

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

For a one-parameter search tool with no output schema, the description covers the essentials: what to pass, in what languages, and what comes back. The only gap is the exact shape of the returned insCode/market payload, which a live tool response would reveal.

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% (schema only specifies a string with length constraints), so the description must compensate. It does: it explains that 'query' accepts Persian/English symbols or names and gives real examples ('فملی', 'خودرو', 'farda'), adding meaning well beyond the bare 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 ('Search'), a precise resource ('TSETMC instrument'), and the query scope (Persian/English symbol or name) with concrete examples. It also states the return payload (insCode + market), making the tool's role unambiguous against siblings like get_quote or get_order_book.

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 context is implied rather than explicit: returning insCode signals this is a lookup step before quote/order-book calls, but the description never names a sibling alternative or states when NOT to use it. No exclusions or conditions are provided.

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

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

With no annotations, the description carries the full burden of disclosure. It usefully states that credentials are never exposed, which is a meaningful behavioral guarantee. However, it does not say whether this is a local read, whether it has side effects, what session states are reported, or what the response structure looks like.

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 concise sentence that front-loads the key purpose and includes a security-relevant qualifier. There is no redundant wording or unnecessary context.

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 parameterless status tool, the description conveys what the agent will learn (existing sessions and the browser allowlist) and the main boundary (no credential exposure). It could be more complete by describing the output fields or exact session states, but nothing needed to invoke it correctly is missing.

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

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

The tool has zero parameters and the schema has 100% coverage with an empty properties object. There is nothing for the description to add about parameters, so the baseline of 4 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 states a clear resource: authenticated portal sessions and the browser allowlist, and the action is implicitly a status query ('which ... exist'). It is distinguishable from sibling market/quote/page tools, though it never explicitly names a sibling to contrast with.

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

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

There is no guidance on when to use this tool versus alternatives like market_status, page_read, or get_quote. The intended use is only implied by the session/allowlist scope; no explicit when-to-use or when-not-to-use conditions are given.

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