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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds substantial behavioral context beyond this: no authentication required, rate limit of 60 requests/min, error response for unknown region, data source (МФОХА) and attribution requirement, plus detailed explanation of the 'top' field's semantics (pre-made selections with specific criteria). No contradiction with 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?

While the description is lengthy (approximately 150 words), every sentence contributes essential information. It front-loads the core purpose and mode behavior, then systematically covers slug sourcing, alternatives, top field semantics, special-case handling for Kyiv, error behavior, data source, and attribution. No filler or redundancy; the density is justified by the tool's complexity.

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?

Given the absence of an output schema, the description must convey return structure and behavior. It covers both region and city modes, the contents of the showcase (MFO table with conditions, canonical_url, markdown_url), the 'top' field with its three sub-selections, the Kyiv special case, error handling, language behavior, and usage constraints. An agent has everything needed to call this tool correctly and interpret its results.

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% (all three parameters have descriptions). The description adds meaning beyond the schema by explaining the effect of omitting 'city' (region page with city list) versus including it (city page with canonical_url and markdown_url), and clarifies that 'lang' only changes language, not data set. This is a meaningful augmentation over the schema's 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?

The description opens with a specific verb and resource: 'Витрина області або міста за slug' (showcase of region or city by slug). It clearly distinguishes the two modes (region vs city) and explicitly names the alternatives search_offers and get_mfo, making it easy for an agent to select the correct tool among siblings.

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 description gives explicit when-to-use scenarios ('кредит у Львові', 'МФО Одеської області'), tells the agent exactly where to source slugs (list_regions and get_city responses), and names the alternatives for other use cases (search_offers for amount/term, get_mfo for single MFO details). No ambiguity remains about when to invoke this tool.

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