দরদেখা — বাংলাদেশের বাজারদর

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so safety is covered. The description adds useful behavioral context — that prices are 'latest' and 'official' — but says nothing about districts lacking data, how ties or missing values are handled, or whether the result includes per-district values or only the extremes.

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 that front-loads the operation and scope, then states the output, with no redundant restatement of the name or 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?

A simple read-only, two-parameter tool with full schema coverage and rich annotations; the description covers scope, geography, recency, and the comparison output. It is nearly complete, with only minor gaps around missing-district handling and whether per-district values are returned (no output schema exists to cover that).

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 (commodity and priceType enum) are fully documented in the schema, giving a baseline of 3. The description reinforces that only one commodity (singular) is compared, but adds no detail on priceType behavior or commodity naming beyond what the schema says.

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 (compare) and resource (latest official price of one commodity across all districts), plus the derived output (cheapest/most expensive districts). It implicitly separates itself from get_market_price and get_price_trend by being the cross-district comparison, but it never names a sibling to make that explicit.

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 'across all districts of Bangladesh' implies the use case is a cross-district comparison, but there is no explicit when-to-use/when-not guidance and no named alternative (e.g., use get_market_price for a single district). Usage is inferable rather than stated.

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, closed-world, non-destructive behavior. The description adds useful output context beyond that: official retail and wholesale prices, unit normalization, source date, and a citable URL. It does not cover missing-data behavior or coverage limits, keeping it below 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?

Two sentences, front-loaded with the return value and scope, followed by a concise usage trigger. There is no redundant or low-value 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?

With no output schema, the description still explains the returned data well: retail and wholesale price, unit normalization, source date, and citable URL. For a three-parameter read-only lookup with full schema coverage and clear annotations, this is sufficient for correct 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 coverage is 100%, and the schema already explains the optional date default, bilingual district examples, and bilingual commodity examples. The description reinforces that the scope is one commodity in one district and one date, but adds no parameter-specific syntax or constraints 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 states a specific verb and resource: return the official daily retail and wholesale price of one agricultural commodity in one district of Bangladesh. Its scope of one commodity and one district also distinguishes it from siblings like compare_districts and get_price_trend without needing to name them.

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 a clear trigger: use whenever a user asks what a commodity costs today or on a given date in a given place. It does not explicitly exclude cases or name the sibling tools, 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds only that the returned history is at daily granularity, and says nothing about pagination, result size at the 400-day maximum, or what a daily record contains.

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 verb and resource first and no wasted preamble. The 'rather than guessed' rationale is the only slightly soft phrase, but it does justify why an agent would call this instead of estimating.

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 and only a third of parameters documented, the definition leaves the return shape undefined - no fields per day, no price unit or currency, no behaviour for an unknown commodity or district. For a data-retrieval tool that an agent must interpret, this is thin.

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?

Only 'days' is documented in the schema (33% coverage, with default and max already stated there). The description partly compensates by making the cardinality explicit - one commodity, one district - but it never says whether those values are names, codes, or IDs, which is the real gap.

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 sentence names a specific verb and resource ('Return the daily price history') and constrains scope to one commodity in one district. That single-district framing implicitly separates it from compare_districts, but no sibling is ever named, so differentiation relies on 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?

The trailing clause ('so the change over time can be stated precisely rather than guessed') hints at a use case, but there is no statement of when to prefer this over get_market_price (current price) or compare_districts. The agent must guess which sibling to call.

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 this is a safe, read-only, idempotent operation, so the description does not need to repeat safety details. It adds useful behavioral context by describing the response contents: match status, correct figure, and a citable URL.

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 three tight sentences with no wasted phrasing. The core purpose is front-loaded, followed by an example and a usage recommendation.

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-only tool with rich annotations and no output schema, the description supplies the necessary return-value context and input example. Nothing critical is missing for correct 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 coverage is 100%, so the claim parameter is already documented as a Bangla or English string. The description adds practical meaning with a free-text Bangla example, helping the agent understand the expected input format 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 states a specific verb and resource: checking whether a stated price matches the official record. It also distinguishes the tool's verification role from price-fetching or trend-analysis siblings by emphasizing claim checking rather than retrieving prices directly.

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 explicitly says to use this tool to check claims instead of asserting a price from memory, giving clear usage context. It does not explicitly contrast with siblings such as get_market_price or get_price_trend, so the routing guidance is clear but not exhaustive.

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