Inflation rate

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.