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

Beyond the readOnlyHint/idempotentHint/destructiveHint annotations, the description discloses the rate limit (60 requests/min), no-auth requirement, the no-pagination cap ('типово і максимум 10, без пагінації'), and both edge cases: an MFO without reviews returns an empty list with total: 0, and an unknown slug produces an error with a hint to use list_mfo. Nothing contradicts the 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?

The description is four dense sentences, each earning its place: purpose and return fields, usage routing, safety/rate-limit info, then return behavior with edge cases. Core purpose is front-loaded before alternatives and edge behavior, with zero filler or redundancy.

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 compensates by specifying every returned element (rating, date, text, author name, total) as well as the empty-list and error response shapes. Combined with full annotations and 100% parameter coverage, nothing an agent needs to invoke this tool correctly 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 description coverage is 100%, so the schema already fully documents slug (with format guidance and the /mfo/{slug} example), lang (with enum and default), and limit (1–10, default 10). The description adds only marginal context beyond the schema — the no-pagination consequence of limit and the error behavior for a bad slug — which keeps it at the baseline of 3.

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+resource+scope: 'Останні відгуки позичальників про одну МФО за slug' (latest borrower reviews about one MFO by slug), and enumerates the returned fields (rating 1–5, date, text, author name, total). It explicitly distinguishes itself from siblings by noting that get_mfo or list_mfo suffice for an average rating, so an agent can tell this tool apart from the other read-only tools.

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 routing: 'Використовуйте після get_mfo, коли потрібна думка клієнтів словами' (use after get_mfo when you need clients' opinions in words), and names get_mfo/list_mfo as the alternatives when only an average rating is needed. It even references list_mfo again for recovering from an unknown-slug error, leaving no ambiguity about when to use this tool vs its siblings.

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