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

Annotations already declare readOnly/idempotent/non-destructive, so the description adds genuinely new behavior: results are published about a day after the auction, values are in trillion rials (هزار میلیارد ریال), and each record breaks out offered, ordered, accepted, YTM and sold amounts plus auction/year totals. It does not discuss history depth beyond the limit parameter or how missing/unsold auctions are represented, so it stops short of a 5.

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

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

Three sentences, front-loaded with the core purpose, then payload detail, then routing and latency. Dense but every sentence carries information; the Persian parentheticals aid interpretation rather than padding.

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-param read-only tool with no output schema, the description covers what is returned field-by-field, the units, the reporting lag, and the sibling for announcement text. Nothing an agent needs to call or interpret it correctly is missing.

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

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

Schema description coverage is 100%, so `year` (Jalali, 1399-1500, defaults to current year) and `limit` (1-6 newest results, default 2) are already fully documented. The description adds no parameter-level detail such as what `year` does to the year totals it mentions, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get the results of the Central Bank's weekly government Islamic securities (sukuk) auctions') and immediately enumerates the payload ('sold amounts and yields'). It also routes a different need to the sibling cb_news_item, so an agent can separate it from the news tools without opening a schema.

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

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

Explicitly names the use case ('government borrowing and the yield level of public sukuk') and gives the alternative for announcement text ('call cb_news_item with the `id`'). This is the when-to-use / when-to-use-something-else split that makes sibling selection unambiguous.

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

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

Annotations already mark it read-only, idempotent, non-destructive, and open-world, but the description adds important behavior: official vs free-market rate scope, empty-list behavior for missing dates, and interpretation of per_units and trend. These are meaningful details beyond the structured annotations.

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

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

Front-loads the tool's purpose, then efficiently covers official-rate caveat, return-field semantics, empty-result behavior, and the sibling alternative. Every sentence is useful and nothing is redundant.

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

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

For a two-parameter read-only tool with no output schema, the description supplies enough context to call and interpret it: date coverage, currency coverage, official-rate meaning, empty-result behavior, and the key return concepts. No critical gap remains for agent selection or invocation.

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

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

Schema description coverage is 100%, so both input parameters are already well documented in the schema. The description adds useful context about official-rate scope and return fields like per_units and trend, but it does not add much input-parameter semantics beyond what the schema already provides.

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

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

States a specific verb and resource: retrieves the Central Bank of Iran's official reference exchange rates for one day, in rials per currency unit. It also distinguishes official rates from free-market rates and names cb_rate_history for multi-day series, so an agent can distinguish it from 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?

Explicitly says to use it for today or any past day back to 1383/2004, clarifies these are official not free-market rates, and directs series requests to cb_rate_history. It also explains that weekends, holidays, and future dates return an empty rates 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 readOnly/idempotent/non-destructive, and the description adds real domain behavior: values are percent, CPI-based, 12-month rates; the last listed month is the latest known; annual history reaches back to 1316; and 1401 contains a base-year change. That base-year caveat is exactly the kind of quirk an agent would otherwise misread. Freshness/latency and coverage gaps for future years are not stated.

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

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

Front-loaded with the core purpose, then the two series, then usage and a sibling reference. Dense but each sentence carries information; the parenthetical unit explanation and the note about the last item being latest are both load-bearing.

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

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

There is no output schema, and the description compensates by explaining the shape of both return series (per-month 12-month rates for `monthly`, year-averages newest-first for `annual`). Missing only minor edge behavior such as nulls for incomplete current-year data or how far back the monthly series can go.

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

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

Schema coverage is 100%, so both parameters are already documented; the description goes further by defining what the year selects (the monthly series for that Jalali year) and bounding the annual history retrieval depth. It does not explain what `annual_years: 0` yields, leaving one edge case to inference.

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

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

States a specific verb and resource ('Get Iran's inflation rate as published by the Central Bank') and immediately enumerates the two series it returns. It is clearly separable from siblings such as cb_policy_rates and cb_exchange_rates without opening any schema.

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

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

Gives concrete usage context ('Use it for "what is inflation now" and trends') and an explicit procedure for the latest monthly figure (take the last item of the current year's `monthly`), plus a pointer to cb_policy_rates. It lacks an explicit when-not rule or differentiation from cb_rate_history/cb_statistics, so it stops short of a 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety burden is covered. The description adds genuinely non-structured context: units (trillion rials / هزار میلیارد ریال), the growth_pct comparison basis (same month a year earlier), and the important staleness caveat that `period` 'can lag by months'. It stops short of describing pagination or completeness of the statement list.

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

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

Front-loaded with the primary output, then maps each returned key to its meaning, then closes with routing. Dense but every clause carries information an agent would otherwise have to guess (fields, units, lag, alternatives); no filler sentences.

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

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

No output schema exists, yet the description documents the return shape thoroughly (monetary_aggregates with balance/growth_pct, period, statements, lead, monthly_report links). For a single-optional-param read tool with full annotation coverage, this is 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 is 100%, so the baseline is 3. The description earns a bump by clarifying that `limit` governs only the `statements` array ('the latest statements on it', '`statements` are the newest news items'), which the schema's wording ('how many recent liquidity statements') does not make unambiguously scoped.

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

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

States a specific verb and resource ('Get Iran's liquidity (نقدینگی, M2) as numbers from the newest monthly report') plus the secondary payload ('latest statements'). It names the concrete fields (liquidity, M1, quasi-money, monetary base, money multiplier) so an agent can distinguish it from cb_inflation, cb_statistics and cb_news without opening any schema.

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

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

Explicitly routes the agent: 'For other sheets of that file call cb_statistics("monetary"); for other topics use cb_news.' That gives both the alternative tool and the condition selecting it, and even names the argument value. Nothing is left to inference about when this tool is the wrong choice.

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

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

Annotations already declare readOnly, idempotent, open-world, and non-destructive behavior. The description adds useful behavior beyond that: results are newest first, only titles are returned here, the filter matches titles, and dates are Jalali. It does not cover pagination behavior or rate limits, but the key operational traits are disclosed.

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

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

The description is front-loaded with what the tool returns, then adds usage examples, the title-only limitation, the full-text alternative, ordering, filtering advice, and date format. Every sentence contributes actionable information without unnecessary verbosity.

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

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

There is no output schema, so the description carries the burden of explaining return values, and it does: titles, dates, ids, newest-first ordering, and title-only scope. Combined with complete schema parameter descriptions and safety annotations, an agent has enough context to call the tool correctly.

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

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

Schema coverage is 100%, so the schema already documents year, limit, and query. The description still adds meaningful semantics: the query parameter filters titles and short Persian root words are recommended, and it reinforces the Jalali date context. Limit behavior is left entirely to the schema.

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

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

The description states a specific verb and resource: it lists the Central Bank's latest news and announcements, including which fields are returned (title, date, id). It also explicitly distinguishes itself from cb_news_item by saying this tool provides titles only and the sibling provides full text.

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

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

It gives clear usage context: find official statements on topics like liquidity, inflation, currency supply, bond auctions, and rules. It also names the alternative explicitly: use cb_news_item with an id for full text. The title-filtering tip is directly 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 declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely non-obvious context: the body is Persian as published and must be treated as data rather than instructions, an explicit prompt-injection warning. It does not discuss truncation/continuation behavior in prose, leaving that to the schema.

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

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

Three short sentences, front-loaded with the core action and return contents, followed by the id source and the motivation. No filler and nothing redundant with the schema.

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

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

With no output schema, the description correctly compensates by listing the returned fields and flagging that attachments exist and the text is Persian. The one remaining gap is that it never mentions the default 3000-character truncation, which affects how an agent should read a long statement.

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 `id` and `max_chars` are already documented, and the description only reinforces the id's origin. It says nothing about max_chars or what happens when the text is cut, so it does not meaningfully exceed 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?

States a specific verb and resource ('Read one Central Bank news item or announcement in full') and enumerates what comes back: title, date, text and attached files. The word 'one' plus the id provenance note cleanly separates it from the list-style sibling cb_news.

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?

Tells the agent where the required id comes from ('`id` comes from cb_news or cb_liquidity'), which is the key routing decision, and motivates the call by noting statements carry numbers that titles only hint at. It stops short of stating when not to use it (e.g. for pure listing) but the practical guidance is clear.

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

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

Annotations already declare this as a read-only, idempotent, non-destructive, open-world operation. The description adds important behavior not covered by annotations: older reports are PDF links, latest.repo returns specific auction fields, and damaged Persian PDF text means only numbers are returned and should be checked against the file link.

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

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

The description is front-loaded with the core action and remains focused on useful operational details. It is slightly longer than minimal, but every sentence adds either scope, return-shape context, or a data-quality caveat.

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

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

There is no output schema, so the description carries the return-value explanation and does so adequately by describing latest.repo fields, older PDF links, and the numeric-only extraction limitation. Combined with complete schema coverage and safety annotations, an agent has enough context to invoke the tool correctly.

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

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

Schema description coverage is 100%, so both parameters (year and limit) are already documented in the input schema. The description does not add further parameter semantics beyond the schema, so the baseline 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 states a specific verb and resource: list weekly open market operation reports and read the newest report's repo auction figures. It distinguishes the tool from related siblings by pointing to cb_policy_rates for the interbank rate and corridor, so an agent can identify its role without opening the schema.

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

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

The description clearly implies this tool is for open market operation reports and latest repo auction details, and explicitly routes related rate/corridor questions to cb_policy_rates. It does not give explicit when-not-to-use guidance beyond that related-tool pointer, so it falls short of full alternative routing.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real value beyond that: it discloses the weekly cadence and the exact semantics of each returned column (floor vs. corridor ceiling), which the annotations cannot convey. It stops short of describing row counts, ordering beyond the schema's 'newest first', or gaps in 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?

Front-loads the core purpose in the first clause, then the column glossary, then the routing hint. The four-column definition list is dense but each entry earns its place by disambiguating similar-sounding rate series; the sentence is somewhat long but not padded.

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 explaining return values and does so via the column glossary, plus the weekly cadence and default-year behavior. An agent could call this correctly. Minor gap: no mention of how current-year data behaves mid-year or what an empty result means.

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% — both `year` (Jalali, 1399 to now, defaults to current) and `limit` (1-60, newest first) are already fully documented in the schema. The description adds no parameter-level detail such as how `year` interacts with `limit` or whether partial years are truncated. 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?

States a specific verb and resource — the Central Bank's weekly interest rates — and enumerates the four series returned (interbank, repo_min, standing_lending, standing_deposit), so the agent knows exactly what data this yields. It does not differentiate from the closest sibling, cb_rate_history, which an agent could plausibly confuse with a weekly-rates tool.

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

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

Gives an explicit usage context ('monetary policy and money market questions') and routes inflation questions to cb_inflation by name. Missing any guidance on when to prefer cb_rate_history or cb_statistics over this tool, which is the more likely ambiguity given the sibling 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?

Adds substantial context beyond the readOnly/idempotent annotations: files are binary and not read here, the agent should hand links to the user, the newest economic_trends/monetary_reports issue carries file links while others carry their own `url`, and publications lag their period so the newest issue can be stale.

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?

Core purpose is front-loaded in one sentence, followed by a compact kind-by-kind enumeration. Dense but each sentence carries operational information; the kind list is near the length limit without waste.

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

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

No output schema exists, and the description covers what is returned (issue list, file links, `url` field, ordering) plus the freshness caveat, which is exactly what an agent needs to call it and report results correctly.

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

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

Schema coverage is 100% so the enum is already documented, but the description adds value by explaining what each kind actually contains (balance sheets, money and credit; rial interbank market and OMO) and file formats per kind. It does not clarify `limit` beyond the schema, keeping it below 5.

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?

Opens with a specific verb+resource ('List the newest Central Bank publications of one kind with download links'), including ordering ('newest first'), which immediately separates it from siblings like cb_statistics or cb_news.

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?

Enumerates each of the four kinds with what they contain and periodicity, and explicitly routes the agent elsewhere when it needs the numbers ('To read the numbers of the monthly Excel files use cb_statistics'). This is an explicit alternative selection, not 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?

Goes well beyond the readOnly/idempotent annotations: discloses ordering (oldest first), the computed total change, a 20-point sampling cap ending at to_date, that days without a published rate are skipped, and that rates are rials per currency unit (pointing to per_units in the sibling). That is exactly the behavioral context annotations cannot carry.

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

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

Front-loads purpose, then the two behavioral branches, then the sibling pointer and units note – every sentence carries information. The middle sentence is dense and run-on, 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 no output schema, the description still tells the agent what comes back (rate series plus total change, in rials per unit), how many points, and how gaps are handled. All four parameters and both operating modes are accounted for.

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 already 100%, but the description adds actionable meaning: step_days 7 for months, 30 for years, capped at 20 points ending at to_date, and to_date defaulting to today. It doesn't restate the Jalali/Gregorian format rules, which the schema handles.

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

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

States a specific verb and resource ("Get the official CBI rate of one currency over time") plus the output shape (oldest first, with total change). It explicitly distinguishes itself from the sibling cb_exchange_rates, which covers all currencies on a single day.

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

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

Gives explicit when-to-use branches: without dates → fast 7-day snapshot; with from_date → sampled archive series. It names the alternative (cb_exchange_rates) and the condition that selects it ("every currency on one 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds real behavioral context beyond them: data is published months after the period, the newest month varies by section, every sheet name is listed in the result, row order is preserved, empty cells are dropped, and header/title rows come first. The unit convention (trillion rials) is a similarly valuable disclosure.

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

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

Purpose is front-loaded in the first sentence, then behavior and workflow follow in a logical order with no filler. It is somewhat long and the section enumeration partially duplicates the schema enum text, but each paragraph carries distinct 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 no output schema, the description carries the return-format burden itself and does so: row shape, preserved ordering, dropped empty cells, leading title/header rows, the embedded sheet list, and units. Combined with the parameter guidance and lag caveat, an agent has what it needs to call and interpret the result correctly.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns a bump by explaining the sheet-iteration workflow (result lists every sheet name, then re-call with sheet) and warning to check `period` because the newest month differs per section. The section-to-content mapping largely restates the schema's enum description, so it is not a full step above baseline.

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

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

States a specific verb and resource: read one table of the Central Bank's monthly statistics Excel file, returned as rows of numbers and Persian labels. It enumerates the four section domains, which lets an agent separate it from cb_news, cb_inflation, and the other siblings without opening the schema.

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

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

Explicitly scopes usage to 'numbers the site only publishes as spreadsheets' and names the concrete topic coverage per section (monetary, balance_of_payments, fiscal, capital_market). It also gives the multi-call workflow ('call again with sheet') and routes to sibling cb_liquidity for the liquidity summary.

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