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

No annotations are supplied, so the description carries the behavioral burden. It correctly signals a single-record read ('Full detail for one ... product'), and the output schema covers the response shape, but it says nothing about behavior for an unknown/invalid id (empty result vs error), authentication, or rate limits. For a low-risk id lookup this is acceptable but not rich.

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 sentence, front-loaded with the core purpose ('Full detail for one Migros product'), with the id requirement and its source appended as a qualifier. No filler wording to trim.

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 an output schema present, the description does not need to enumerate return fields, and for a one-required-parameter lookup it covers the essentials: what it returns, for what key, and where the key comes from. Only edge-case behavior (invalid or non-existent id) 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?

The single parameter has 0% schema description coverage (schema only says 'integer / Product Id'), and the description compensates by defining it as a numeric identifier and stating where to obtain it — from search results. That provenance hint is the key operational detail the schema omits; only failure behavior for a bad id is left unaddressed.

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+resource+scope combo: retrieve the full detail record for exactly one Migros product, keyed by numeric id. The word 'one' and the '(from search results)' clause implicitly separate it from the sibling migros_search_products, so an agent can distinguish the pair 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?

The parenthetical 'from search results' implies you call this only after a search has produced an id, which is real but implicit guidance. There is no explicit when-to-use/when-not statement and no named alternative (e.g. use migros_search_products first if you only have a name), leaving the agent to infer the workflow.

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?

With no annotations, the description carries the full behavioral burden, yet it only lists the returned fields (id, name, link slug) — information an output schema already covers. It never states that the call is read-only, whether results are ordered, how many categories exist, or whether the hierarchy has deeper levels, all of which matter for a discovery tool.

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 compact phrase with zero filler, and the scope qualifier ('top-level') is front-loaded. It is a sentence fragment rather than a statement of action, which slightly reduces clarity but wastes no words.

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 zero-parameter list tool with an output schema present, the description need not explain return values, so the core is covered. Still missing is any hint of the category hierarchy or the intended workflow (discover categories, then search within them), which would make this a genuinely complete definition.

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 there is no parameter meaning to convey; baseline is 4. The description correctly implies a no-argument call, and there are no filters or options that would need explanation.

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?

Names the resource precisely ('top-level Migros store categories') and enumerates the fields returned, so an agent knows this is a category-listing call rather than a search or product fetch. It stops short of explicitly contrasting itself with siblings like migros_search_products or migros_list_promotions, but the noun 'categories' is distinctive enough to separate it.

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?

No when-to-use guidance at all: nothing says to call this first to obtain category ids/slugs before searching products, and no alternatives or exclusions are mentioned. The only hint of usage is the word 'top-level', which implies it is an entry point but does not state it.

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?

With no annotations, the description carries the burden and usefully discloses the ordering ('best discount first') and an important semantic caveat about money_discount_pct being a loyalty discount rather than a price cut. It does not explicitly state read-only safety or rate/permission behavior, which prevents 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?

The description is short and front-loads the core purpose, ordering, and caveat. The 'see the server instructions' reference is compact, though it relies on external context rather than being self-contained.

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 two-parameter list tool with an output schema, the description covers purpose, ordering, and discount semantics adequately. However, with no annotations and zero schema descriptions, it leaves gaps around the limit parameter and read-only/permission behavior.

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 0%, so the description must compensate. It provides helpful query examples ('süt', 'çay', 'deterjan') but gives no meaning for the limit parameter beyond the schema default of 10.

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 resource and filter: discounted products for a keyword, sorted best discount first. It distinguishes promotions from general product search implicitly, but does not name the sibling tool it replaces.

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 by 'discounted products for a keyword', but there is no explicit guidance on when to use this instead of migros_search_products or migros_price_stats. No exclusions or alternatives are named.

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?

With no annotations, the description carries the full behavioral burden. It does disclose an important non-obvious trait — statistics cover only the first page, capped at 36 products — which prevents the agent from treating results as catalog-wide. However, it says nothing about read-only nature, whether a live search is triggered per call, or failure behavior when a query returns no matches.

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 listing the metrics, the target, and the sampling limit with zero redundant wording. Every clause earns its place.

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?

An output schema exists, so return values need not be explained, and the description enumerates the computed statistics. What remains thin is the parameter and error-path context, but for a one-parameter statistical helper this is close to 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?

The single parameter 'query' has no schema description (0% coverage), so the description must compensate. It does clarify that the value is a search keyword whose first page is analyzed, but does not specify language, matching semantics, or formatting for the query string.

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 resource and operation: computes price statistics (min/median/max/mean, cheapest and priciest) over a keyword's first page of Migros search results. This implicitly distinguishes it from migros_search_products (which returns products) without naming that sibling explicitly.

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 only implied: an agent can infer this is for summarizing price distribution rather than listing products. There is no explicit when-to-use/when-not-to-use guidance and no mention of the sibling tools that would be the alternative for getting the underlying products.

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?

No annotations exist, so the description carries the full burden. It usefully discloses a page size cap (up to 36 products) and the currency of returned prices (TRY), which is real behavioral context. It does not cover the read-only nature, what happens at the end of results, total-count behavior, or any error/empty-result handling.

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, then sort options, then return characteristics. No filler or repetition; every clause carries information an agent needs.

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?

An output schema exists, so return-value structure need not be described, and the description still adds the page size and currency. Combined with full sort enumeration and query language guidance, it is nearly complete for a 3-parameter search tool; only pagination termination 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 coverage is 0%, so the description must compensate, and it mostly does: it enumerates all seven accepted sort values (which the schema does not constrain at all) and specifies that query is a Turkish keyword with examples. Only 'page' is left implicit via the phrase 'per page' rather than explained directly.

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+resource (search Migros products by keyword) and scopes it to Turkish-language queries with concrete examples. It is clearly distinguishable from migros_get_product and migros_list_categories, though it never names those siblings explicitly.

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 only implied: the reader infers this is for keyword-driven product discovery and that migros_get_product is for a single known item. There is no explicit when-to-use/when-not statement or named alternative, so an agent must reason about sibling selection on its own.

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