Monthly statistics tables

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.