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

Annotations already declare this as read-only, idempotent, open-world, and non-destructive, so the safety profile is covered. The description adds useful context beyond annotations: it reads live from the site's fees page, explains fee fields as percent/min/max, defines 'mg' as milligrams, and clarifies that delivery means physical gold at a branch.

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 tool purpose, then adds the return-shape explanation and the sibling alternative without filler. Every sentence contributes useful selection or interpretation 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 one-parameter, read-only lookup with no output schema, the description is complete enough: it explains the fee structure, units, delivery meaning, live source, and when to use mg_trade_quote instead. An agent can select and interpret the call without missing material context.

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 single 'customer' parameter has full schema description coverage, so the schema already explains 'individual' versus 'company'. The description does not add further parameter-specific guidance, so the high-coverage 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 gives a specific verb and resource: 'Get Milli.gold's current fees for buying, selling, transferring and delivering gold and for wallet withdrawals.' It also explicitly distinguishes the tool from the sibling mg_trade_quote by directing concrete pricing there.

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 states the intended use clearly and names the alternative for a different need: 'To price a concrete trade use mg_trade_quote.' That gives the agent an explicit routing rule between current fee lookup and trade pricing.

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 open-world, so the safety profile is covered; the description adds real domain context that the annotations can't — the quote excludes tax and making charge, and `as_of` is in Tehran time. It stops short of saying how fresh or cached the quote is beyond the as_of field, which is the only remaining gap.

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: what it returns first, then the unit/tax caveats, then the sibling redirect. Nothing is padded and the most important fact is front-loaded.

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 the return value — and it does, specifying both units (per mg and per gram), the currency (Rial), the tax/making-charge exclusion, and the timezone of the timestamp. An agent can call this and interpret the result with no further information.

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 takes no parameters, so baseline is 4. The mention of `as_of` being Tehran time describes a response field rather than an input, but it is still useful orientation for interpreting the call result.

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 current Milli.gold price of 18k melted gold') and immediately pins down the unit domain (Rial per milligram and per gram). This is clearly separable from mg_price_history and mg_platform_stats, which deal with trends and platform metrics rather than a spot quote.

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 the trend over a day, week or month use mg_price_history.' The alternative and the condition that selects it are both named, so an agent won't call this for time-series data.

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 readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful corpus context (~80 articles, Persian content with English URL slugs). It says nothing about result ordering or how many hits come back, which with no output schema is a real remaining gap.

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 purpose and followed by the two routing pointers. No filler or restatement of the name.

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 tool with no output schema, the description covers what it searches, how to phrase the query, what happens when the query is empty, and which sibling to call next. Nothing an agent needs 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 coverage is 100%, so the baseline applies, but the description adds non-obvious meaning: the query matches URL slugs rather than article text, and the examples in the prose ('how to buy, sell, deliver, transfer, verify, fees') show the agent what vocabulary works. That is real value beyond the schema's own 'card' example.

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 ('Find Milli.gold help-center articles') plus the enumerated topic space and the matching mechanism (English keyword). An agent can immediately distinguish this search tool from mg_read (which fetches an article) and mg_fees (the fee table).

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: read results with mg_read, and use mg_fees for the fee table itself. It also pre-empts the obvious failure mode by explaining the articles are Persian but their URLs are English, so English keywords must be used.

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, non-destructive, open-world behavior, so the description focuses on tool-specific traits. It adds per-section availability limits, the absence of search or older pages, Persian-language news content, returned fields, and the handoff to mg_read.

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 scope, then adds constraints and the mg_read handoff. Every sentence carries useful information, and there is no redundant restatement of the tool 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?

With no output schema, the description provides the return fields (date, categories, summary, URL), availability constraints, section context, and the alternative for full-post reading. Combined with annotations covering safety and schema covering parameters, an agent has enough information to invoke it 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 limit and section semantics. The description adds useful context beyond the schema by noting approximate per-section counts ('about 20 news, 10 mag, 10 help') and the nature of the news content, which helps an agent choose section and limit.

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 and resource: 'List the newest posts' on Milli.gold's news, magazine, or help site. It also explicitly routes full-post reading to the sibling tool mg_read, so an agent can distinguish listing from reading.

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 clearly states the main usage constraint ('Only the newest posts are available... there is no search or older pages') and names mg_read as the alternative for reading a full post. The only gap is that it does not explicitly clarify how the 'help' section relates to the sibling mg_help_topics tool.

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 genuinely useful semantics beyond that: figures are rounded company-published totals and weights are in kilograms, which prevents misreading the numbers as exact or unit-ambiguous.

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 short sentences: the first front-loads what is returned, the second carries the rounding/unit caveat and the sibling redirect. No filler and nothing buried.

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 does the work of enumerating the returned metrics, their units and their rounding. Minor gap: it doesn't say whether figures are all-time cumulative or point-in-time, which an agent might want when reporting them.

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 takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It uses the space instead to explain the units of the returned values, which is the closest analogue to parameter meaning here.

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 ('Get') and a specific resource ('Milli.gold's headline numbers') and enumerates exactly what comes back: users, trades, gold traded, gold held, branches. This is clearly distinguishable from the sibling price tools, which the description also acknowledges.

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 away for price data ('For prices use mg_get_price'), which is the main ambiguity risk given the sibling tools. It doesn't mention mg_price_history, so routing is not fully exhaustive, but the primary when-to-use is stated clearly.

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/openWorld, so the safety profile is covered; the description adds real value beyond that with the unit convention (Rial per milligram, with a worked conversion to Toman per gram), the Tehran timezone of the series, and the fact that points are evenly thinned rather than raw. It does not mention freshness/lag or rate limits, but the disclosed constraints are the ones an agent would otherwise get wrong.

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 what is returned and followed by the two facts most likely to cause downstream errors. The parenthetical conversion example is slightly verbose but justifies itself as disambiguation between Rial and Toman.

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 does state the return shape (series with high, low and change) plus units and timezone, which covers what an agent needs to interpret results. It stops short of describing ordering, point timestamps, or how empty/short ranges behave, which is a modest gap for a small read-only tool.

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 fully documented, including the enum meanings and the 2-50 range. The description only echoes points-thinning and timezone, adding little the schema does not already carry; 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: retrieves the Milli.gold 18k gold price *series* over a day/week/month with high, low and change. That clearly separates it from a plain price reader, but the description never names mg_get_price, so the agent must infer the history-vs-current split from the tool name alone.

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 is implied rather than stated: the period windows make it obvious this is for historical series, but there is no explicit 'use this when you need a trend, use mg_get_price for the current price' routing despite that sibling existing. No exclusions or prerequisites are given.

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 and non-destructive, so the bar is lower; the description still adds real value by disclosing the output shape (tables flattened to pipe-delimited lines), the language of the text (Persian), and that digits are preserved as written rather than normalized. It doesn't describe failure behavior for disallowed URLs, which is the remaining gap.

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 output transformation, then the input restriction, then a language/output caveat. No filler and nothing 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?

With no output schema, the description carries the burden of describing the return value and does so concretely (flattened tables, Persian text, verbatim digits). It is nearly complete for a simple 2-parameter read tool; only error handling for invalid URLs is unaddressed.

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%, with both url and max_chars fully documented including ranges, so the baseline is 3. The description adds only a marginal constraint on the url parameter (only news/mag/help milli.gold URLs), and says nothing about max_chars truncation beyond what the schema already states.

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 the text of one post) plus a concrete output trait (tables flattened to 'a | b | c' lines). This clearly distinguishes it from the sibling listing tools mg_latest_posts and mg_help_topics, which surface posts rather than their 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?

Gives an explicit eligibility constraint: only milli.gold news, mag and help URLs are accepted, reinforced by the schema note that URLs come from mg_latest_posts or mg_help_topics. It doesn't state what to do when a non-matching URL is passed or point to an alternative for other content types, 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?

The annotations already establish readOnly, idempotent and non-destructive behaviour, but the description adds material context: the fee is the larger of `min` and `percent` (today 1 mg or 0.5 %), new-user waivers and wallet withdrawal fees are not applied, and the price moves. That is substantive disclosure 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?

Four sentences, front-loaded with the purpose before invocation details and caveats. Every sentence carries unique information: what it returns, how to invoke it, how the fee works, and what is excluded.

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, yet the description names the relevant outputs (`pay_toman` for a buy, `receive_toman` for a sale) and qualifies the result as an estimate subject to waivers and price movement. Nothing an agent needs in order to call it correctly or interpret the result 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 coverage is 100%, so the baseline is 3; the description adds the either/or relationship between `grams` and `toman` and clarifies that `toman` is a fee-inclusive buy budget. The gain over the schema is modest, since the schema already describes each parameter and marks `toman` as buy-only.

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 opens with a specific verb and resource: 'Estimate what a gold trade on Milli.gold costs or pays out right now, fee included, at the live price.' It also distinguishes itself from the sibling mg_fees, so an agent can tell the two apart without opening either 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?

It states the conditional parameter usage directly ('Give `grams` for a buy or a sale, or `toman` ... for a buy') and names the alternative for a related need ('For the fee table itself use mg_fees'). The condition that selects between the tool and its sibling is explicit.

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