catalog

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It compensates well by detailing the response fields (title, canonical_url, criterion, sorting, total, offers), explaining the meaning of criterion and sorting, and specifying the isError response with 'Не найдено' for a missing slug. It does not discuss authorization or side effects, but the resource is clearly a read operation with enough behavioral detail.

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?

Despite being dense, every sentence serves a distinct role: purpose, response contract, error behavior, and sibling routing. There is no filler or redundant schema repetition, and the core purpose is front-loaded before the detailed field list.

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 single-parameter read tool with no output schema, the description covers the full response shape including nested offer attributes, error semantics, and usage boundaries. The only minor gap is the exact meaning of 'total' (likely the count of offers), but this does not impair 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 description coverage is 100%, and the schema already thoroughly documents slug with format guidance, an example, and an explicit instruction to take the value from list_categories. The description only restates 'по slug' and adds no new parameter-specific semantics, so the baseline of 3 applies.

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 'Одна тематическая подборка каталога по slug' — a clear statement that the tool fetches a single catalog category by slug. It distinguishes this tool from siblings by explicitly naming search_offers and get_mfo as alternatives for different use cases, making its purpose unambiguous.

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 provides explicit routing: use get_category when the question matches a ready-made collection, with an example ('микрокредиты пенсионерам'), and states that search_offers is for amount/term matching and get_mfo for full MFO cards. This covers when-to-use and when-not-to-use with named alternatives.

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 provided, the description carries the full burden and does well: it explains what the tool returns, includes a reviewed_at date with an explicit warning to verify freshness, and notes that the content is based on the last editorial review. It does not discuss side effects or rate limits, but for a zero-parameter read-only context tool this is adequate.

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 dense but well-organized: substantive legal facts come first, followed by return fields, freshness caveat, and usage guidance. Every sentence adds value, and the alternative tool is mentioned only at the end where it belongs.

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 tool without an output schema, the description is remarkably complete: it names all return fields, explains the meaning of reviewed_at, lists the covered topics, and provides usage criteria. An agent can confidently decide when to call this tool and what to expect from it.

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 has zero parameters and the schema coverage is 100%, so there is nothing for the description to add. It even states 'Параметров нет' (no parameters), which removes any doubt. This meets the baseline expected for a parameterless tool.

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 clearly states the tool's resource (legal context of microcredits in Kazakhstan) and enumerates its specific content: regulator, licensing, GESV limits, short-term microloan regime, MRP, eGov refusal, and signs of illegal lenders. It also distinguishes itself from the sibling get_mfo by stating that data on a specific MFO should come from get_mfo.

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 explicitly says to use this tool for questions about rate legality, limits, and borrower protection, and directly names get_mfo as the alternative for specific MFO data. This gives an agent clear routing guidance with no ambiguity.

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 full burden, and it is highly transparent. It explains what happens on missing slug ('isError' with text 'Не найдено'), clarifies the semantic of null for first_loan_zero_percent, details the meaning of legal.license_registry_url as a primary source, and adds the attribution requirement for canonical_url. This goes well beyond a basic summary.

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 long but information-dense; every clause adds a distinct detail about the returned data or behavior. It is front-loaded with the core purpose, then systematically covers data groups, edge cases, routing, and attribution. No filler or repetition is present.

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 there is no output schema, the description thoroughly covers the return value composition: conditions, summary, requirements, commissions, rating, legal data, and actualization date. It also covers error handling, null semantics, a direct registry link, and the relationship to sibling tools. This is sufficient for an agent to call the tool correctly and interpret its output.

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 schema already covers the slug parameter fully with detailed description, including example and source instructions, so the baseline is 3. The tool description adds only the phrase 'по slug', which restates the schema. It does not materially expand parameter semantics beyond the schema, so a 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 opens with a clear verb+resource statement: 'Полная карточка одной МФО по slug' (full card of one MFO by slug). It enumerates the specific data groups returned (conditions, summary, requirements, commissions, rating, legal data, actualization date), which makes the tool's purpose concrete. It also distinguishes itself from siblings by stating that reviews are obtained via get_reviews.

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 explicitly tells the agent when this tool is NOT for reviews and routes to get_reviews: 'Отзывы — через get_reviews.' It also instructs the agent to take the slug from list_mfo, search_offers, or get_category and not guess it, which is a direct usage guideline. This is clear and actionable.

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 present, the description carries the full behavioral burden and meets it: it discloses the exact return shape (mfo_slug, canonical_url, total, reviews ordered new-to-old with author/rating/date/text), and guards against misinterpretation for both edge cases — empty reviews means total=0 and 'это не низкая оценка', and a nonexistent slug yields isError with 'Не найдено'. The read-only nature is conveyed through 'Возвращает' and the edge-case 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?

The description is longer than minimal, but every sentence earns its place: scope, return format, two edge-case clarifications, and usage routing to get_mfo. The core purpose is front-loaded in the first clause. It is appropriately sized for a tool with no output schema, though the middle field enumeration is dense and could be slightly more compact.

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?

Since there is no output schema, the description must explain return values, and it does so comprehensively: all fields, ordering, and both edge cases are covered. It also includes sibling routing and notes where the slug should come from. For a 2-parameter read tool, nothing essential an agent needs to call it 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 baseline is 3. The description reinforces the slug parameter's role ('по slug') and the new-to-old ordering that affects limit, but it does not add syntax or format details beyond what the schema already documents for either slug or limit. The schema does the heavy lifting 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?

The description opens with a specific verb+resource: 'Последние отзывы заёмщиков об одной МФО по slug' — fetching recent borrower reviews for a single MFO identified by slug, and further narrows scope to public, site-published reviews only. It explicitly differentiates from get_mfo by stating that summary rating and terms belong to that sibling, so an agent can disambiguate without opening the 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?

Provides explicit when-to-use guidance: 'Используйте для вопросов о репутации и опыте клиентов' (use for reputation and client-experience questions). It also gives a clear exclusion by routing 'сводный рейтинг и условия — get_mfo' (summary rating and conditions → get_mfo), naming the specific alternative and the condition that selects 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?

Even with no annotations, the description discloses the return shape, the meaning of the 'criterion' field, and explicitly notes it does not promise loan approval. This is strong behavioral context for a read-only list operation, though it does not mention possible side effects or data freshness, which are minor for this 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?

The description is compact and well-structured: it opens with the resource, describes the return value, and ends with concrete usage guidance. Every sentence contributes useful information without 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?

For a tool with no parameters and no output schema, the description is fully sufficient. It explains what is returned, the field semantics, the purpose, and how it relates to sibling tools, so an agent can invoke it correctly and use its results effectively.

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?

There are zero parameters, and the description explicitly states 'Параметров нет', matching the empty schema. With no parameters to document, the baseline of 4 is appropriate; the description adds no ambiguity.

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 clearly states that the tool lists all thematic catalog collections grouped by sections, and specifies the exact returned structure (sections[], categories) and their fields. It also distinguishes itself from sibling tools like get_category and search_offers by explaining what this tool is for versus the others.

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 explicitly tells when to use this tool: to find a collection slug for get_category or to suggest a page matching a user's situation. It also names search_offers as the alternative when filtering by a specific amount and term, providing clear usage routing.

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 burden, and it does so well: it discloses sorting behavior, the meaning of a missing rating_average field, the returned fields, and the canonical_url attribution requirement. This goes well beyond a generic 'list' description.

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 dense but every sentence earns its place: purpose, return shape with edge cases, usage alternatives, and attribution. It is front-loaded with the core action and uses the remaining space for high-value semantic details.

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 there is no output schema, the description compensates by specifying total, array contents, sorting, and the optional rating field. It also covers sibling routing, which is the key selection context. The only implicit detail, default limit and pagination, is already fully specified in the schema.

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 description itself does not explain the limit parameter, but the schema covers it 100% with min, max, default, and the guarantee that total always contains the catalog count. With full schema coverage, baseline 3 is appropriate; no compensation is needed.

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 names a specific verb and resource: listing all MFIs in the AlexCredit Kazakhstan catalog with borrower ratings. It clearly distinguishes itself from siblings by explicitly routing condition details to get_mfo and amount/term matching to search_offers, so an agent can disambiguate without opening other 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?

It states the intended use ('для обзора рынка и получения slug'), explicitly names alternatives (get_mfo for specific MFI conditions, search_offers for matching by amount and term), and includes an attribution instruction for canonical_url. This is complete when-to-use 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?

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: ordering by rating, unfiltered behavior returning the entire catalog, truncation semantics, the meaning of total=0 with empty offers, the null meaning of first_loan_zero_percent, and volatility of conditions.

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 dense but well-structured: purpose, matching behavior, response fields, empty-result guidance, usage guidance, and caveat. It could be slightly tightened, but every section 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?

With no output schema and no annotations, the description fully enumerates the response shape (query, total, truncated, offers fields), explains edge cases like total=0 and truncated=true, and provides usage and caveat context. Nothing essential for correct invocation 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 valuable meaning beyond the schema by explaining how filters interact: an MFI matches only if requested amount and term fall within its ranges, and an empty offers result with total=0 should trigger relaxing the filters.

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 clearly states the tool's function: selecting MFIs by borrower request based on amount, term, and first-loan-zero flag. It also distinguishes itself from siblings by naming get_category for ready thematic collections and get_mfo for a single MFI card.

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 explicitly says when to use the tool ('where to get N tenge for M days') and names alternatives with their contexts (get_category for curated selections, get_mfo for a single MFI card). This is strong routing guidance for an agent.

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