Read-only catalog of Russian MFOs: loan terms, Bank of Russia registry data, ratings, reviews.
Scored across 7 tools
Each tool targets a distinct resource or action: categories, market rules, MFO details, reviews, and search. No overlapping purposes; descriptions clarify when to use each, such as get_category for thematic collections vs search_offers for numeric filters.
All tool names follow a consistent verb_noun pattern: get_* for single resources, list_* for collections, and search_offers for filtering. The style is uniform and predictable.
Seven tools are well-scoped for a catalog server covering listing, searching, details, reviews, categories, and legal info. Each tool has a clear purpose, and the count is within the ideal range.
The surface covers the full read-only lifecycle: browsing all MFOs (list_mfo), filtering offers (search_offers), accessing categories (list_categories, get_category), retrieving detailed information (get_mfo), reading reviews (get_reviews), and getting legal context (get_market_rules). No significant gaps for the domain.
Возвращает одну тематическую подборку (витрину) каталога по её slug (slug берите из list_categories): критерий попадания, порядок сортировки и полный список предложений МФО в ней. Ответ: JSON {title, slug, canonical_url, criterion, sorting, total, top, offers[]}, у каждого предложения: name, slug, amount_range, term_range, rate, rating_average и canonical_url карточки МФО. top — три автотаблицы витрины (условия для нового клиента, до 10 строк каждая, note и дата updated): best_value — беспроцентный первый займ по убыванию дней без процентов, max_amount — по максимальной сумме, max_term — по максимальному сроку; те же таблицы показаны на странице подборки, берите их вместо собственной сортировки. Постраничной навигации нет — возвращаются все МФО подборки. Используйте, когда вопрос пользователя совпадает с темой подборки (займ на карту, без отказа, с плохой кредитной историей, пенсионерам и т.п.); подбор по конкретной сумме или сроку — search_offers, подробности по одной МФО — get_mfo. Несуществующий slug → ответ с isError и текстом «Не найдено». Только чтение, без авторизации и побочных эффектов; лимит 60 запросов в минуту с одного IP (при превышении HTTP 429). При использовании данных ссылайтесь на canonical_url.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Slug подборки, например «zaim-na-kartu»; берите из list_categories |
| Name | Required | Description |
|---|---|---|
| top | No | Автотаблицы «Топ-N …» витрины, те же, что на странице и в её .md-версии (до 10 строк каждая, условия для нового клиента) |
| slug | Yes | |
| title | No | |
| total | Yes | Число МФО в подборке |
| offers | No | |
| sorting | No | Порядок сортировки |
| criterion | No | Критерий попадания МФО в подборку |
| canonical_url | Yes | Страница подборки на zaimhub.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses no pagination (returns all), a rate limit of 60 req/min with HTTP 429, an error response shape for non-existent slug (isError + 'Не найдено'), and a requirement to reference canonical_url when using data. It also explains the 'top' tables and instructs to use them instead of own sorting. 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?
The description is substantial but every sentence contributes: purpose, response structure, 'top' details, usage guidance, error handling, rate limit, and attribution. It is front-loaded with the core purpose, then expands logically. There is no fluff 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?
For a single-parameter tool with a rich output, the description fully covers the response shape, error handling, rate limits, and usage conditions. It also explains the 'top' tables in detail, ensuring the agent knows exactly what to expect and how to use the data. Nothing critical 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% and the schema already describes the 'slug' parameter with an example. The description adds crucial context that the slug should be taken from list_categories, which is not in the schema, and reinforces the format. This extra guidance elevates it above the baseline 3 for full coverage.
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 verb ('Возвращает') and resource ('тематическую подборку каталога') with its key attributes (критерий, сортировка, список предложений). It distinguishes itself from siblings by naming search_offers and get_mfo as alternatives for other intents, making the tool's scope 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?
Explicitly specifies when to use this tool: when the user's question matches a category topic, with concrete examples (займ на карту, без отказа, etc.). It also states when not to use it and what to use instead (search_offers for specific sum/term, get_mfo for single MFO details), and instructs to obtain slug from list_categories. No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает справку по регулированию микрозаймов в России: предельная ставка 0,8% в день, лимит переплаты 100% по займам до года с 01.04.2026, законы 151-ФЗ и 353-ФЗ, самозапрет на кредиты, период охлаждения, права заёмщика при взыскании. Параметров нет. Ответ: JSON {country, reviewed_at (дата последней редакционной проверки правового блока), summary (краткий текст), details_markdown (полный блок в Markdown), source (URL первоисточника на zaimhub.com)}. Используйте для вопросов о законах, лимитах ставок и правах заёмщика; условия конкретных МФО — get_mfo, подбор предложений — search_offers. Правовые лимиты актуальны на reviewed_at. Только чтение, без авторизации и побочных эффектов и внешних сетевых вызовов; лимит 60 запросов в минуту с одного IP (при превышении HTTP 429).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| source | Yes | Первоисточник — llms-full.txt на zaimhub.com |
| country | Yes | |
| summary | Yes | Краткий правовой контекст |
| reviewed_at | Yes | Дата последней проверки правового блока, YYYY-MM-DD |
| details_markdown | Yes | Полный блок «Ключевые факты» в Markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive hints, and the description goes beyond them by stating no authorization is needed, no side effects occur, no external network calls are made, and there is a 60 requests/minute rate limit with HTTP 429 on exceeding it. It also clarifies that legal limits are valid as of reviewed_at, adding temporal context. 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?
Every sentence delivers useful information: purpose, content scope, output format, usage guidance, alternatives, validity timing, and rate limit. The description is dense but not bloated, and the core purpose 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?
For a parameterless informational tool with an output schema and safety annotations, the description covers everything an agent needs: what data is returned, when to use it, how it differs from siblings, freshness of legal limits, and operational constraints like rate limiting. No significant gap remains.
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 is empty with 100% coverage, so parameter semantics barely apply. The description explicitly notes 'Параметров нет', which is sufficient; no additional parameter detail is necessary. The baseline of 4 for zero-parameter tools 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 specific verb and resource: 'Возвращает справку по регулированию микрозаймов в России' — it says exactly what the tool returns and lists concrete content (rate cap, overpayment limit, laws, borrower rights). It also distinguishes itself from get_mfo and search_offers, making the tool's unique role clear.
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 states when to use the tool: 'Используйте для вопросов о законах, лимитах ставок и правах заёмщика'. It also names the alternatives for different cases: 'условия конкретных МФО — get_mfo, подбор предложений — search_offers'. This leaves no ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает подробную карточку одной МФО по её slug (slug берите из list_mfo, search_offers или get_category). Ответ: JSON с полями name, slug, canonical_url, data_updated_at; summary (диапазоны суммы, срока, ставки и ПСК; first_loan_zero_percent: true/false/null, где null — «не подтверждено»; interest_free_days, decision_time_minutes, processing_24_7); conditions.new_client и conditions.repeat_client (сумма, срок, ставка, полная стоимость кредита); rating (average, reviews_count, position, criteria[] по 4 критериям); requirements (возраст, гражданство, документы, занятость, регистрация, доход); fees (комиссии и штрафы); legal (legal_entity, ogrn, cbr_registry_number, cbr_registry_url — прямая ссылка на запись организации в госреестре МФО Банка России, первоисточник для проверки легальности; legal_address, phone, email). Пустые поля не возвращаются. Используйте, когда нужны условия, требования или юрданные конкретной МФО; список нескольких МФО — list_mfo, отзывы клиентов — get_reviews, подбор по сумме и сроку — search_offers. Несуществующий slug → ответ с isError и текстом «Не найдено». Только чтение, без авторизации и побочных эффектов; лимит 60 запросов в минуту с одного IP (при превышении HTTP 429). При использовании данных ссылайтесь на canonical_url.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Slug МФО, например «zaymer»; берите из list_mfo, search_offers или get_category |
| Name | Required | Description |
|---|---|---|
| fees | No | |
| name | Yes | |
| slug | Yes | |
| legal | No | |
| rating | No | |
| summary | No | |
| conditions | No | |
| requirements | No | |
| canonical_url | Yes | Карточка МФО на zaimhub.com |
| data_updated_at | No | Дата актуализации записи (ISO 8601) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavior beyond them: rate limit of 60 requests/minute with HTTP 429, no authorization required, empty fields omitted, non-existent slug returns isError with «Не найдено», and guidance to cite canonical_url. It also clarifies semantic details like first_loan_zero_percent null meaning «не подтверждено».
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 well-organized and front-loaded with the core purpose, but it is verbose: it enumerates the entire response structure in prose even though an output schema exists. Several sentences duplicate what the schema already states. It would be tighter if it summarized the response shape and relied on the output schema for field 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?
The description is exceptionally complete for a tool of this complexity: it covers success response fields, special values, error behavior, rate limiting, authentication (none), idempotent read-only nature, citation requirements, and sibling tool routing. Nothing an agent needs to invoke 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 coverage is 100%, and the schema already documents slug with an example and source tools. The description repeats the same slug guidance but adds no new parameter syntax or format beyond what the schema provides. Per the baseline for high schema coverage, 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 specific verb and resource: «Возвращает подробную карточку одной МФО по её slug». It explicitly differentiates from siblings by noting that list_mfo returns multiple MFOs, get_reviews returns reviews, and search_offers filters by amount and term. The scope is 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?
Usage guidance is explicit and actionable: «Используйте, когда нужны условия, требования или юрданные конкретной МФО», followed by explicit alternatives for list_mfo, get_reviews, and search_offers. It also tells the agent where to obtain the slug, covering both tool selection and prerequisite behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает последние отзывы заёмщиков о конкретной МФО по её slug, от новых к старым. Параметр limit — сколько отзывов вернуть (по умолчанию 10, максимум 50); поле total — общее число отзывов на сайте, постраничной навигации нет. Ответ: JSON {mfo_slug, canonical_url, total, reviews[]}, у каждого отзыва: author, rating (1–5), date, text — только публичные данные сайта, без персональных. Используйте для мнений реальных клиентов и примеров их опыта; средняя оценка и место в рейтинге есть в get_mfo (поле rating), сравнение МФО по рейтингу — list_mfo. Несуществующий slug → ответ с isError и текстом «Не найдено». Только чтение, без авторизации и побочных эффектов; лимит 60 запросов в минуту с одного IP (при превышении HTTP 429). При цитировании ссылайтесь на canonical_url.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Slug МФО, например «zaymer»; берите из list_mfo или search_offers | |
| limit | No | Сколько отзывов вернуть, 1–50 (по умолчанию 10) |
| Name | Required | Description |
|---|---|---|
| total | No | Всего отзывов на сайте |
| reviews | No | |
| mfo_slug | Yes | |
| canonical_url | Yes | Страница отзывов о МФО на zaimhub.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, and the description adds substantial context beyond that: rate limiting with HTTP 429, the isError response for a nonexistent slug, no pagination, public-data-only content, new-to-old ordering, and the citation requirement for canonical_url. 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 information-dense but every sentence earns its place: result order, limit semantics, response shape, use-case routing, error behavior, access constraints, and citation guidance. It is front-loaded with the core purpose before the supporting 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 the tool has an output schema, the description does not need to restate return values, yet it still does so. It covers error handling, absence of pagination, public-data constraints, rate limits, and sibling differentiation, leaving no practical gap for 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 coverage is 100%, so the schema already documents both slug and limit, including limit's default and 1-50 range. The description repeats the limit default/maximum and explains the total field, but it adds no new parameter-level meaning that an agent could not already read from the schema.
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 precise verb-resource pair: it returns the latest borrower reviews for a specific MFO by slug, ordered newest to oldest. It also distinguishes itself by naming get_mfo for average rating and list_mfo for rating comparison, so an agent can tell it apart from 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?
It explicitly states when to use the tool: for real client opinions and examples of their experience. It also provides alternatives and exclusions: get_mfo gives the average rating and place in rating, while list_mfo handles rating comparison, so an agent knows which sibling to route to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает все тематические подборки (витрины) каталога ZaimHub, сгруппированные по разделам: популярные, по способу получения, по сумме и сроку, по категориям заёмщиков, другие. Параметров нет. Ответ: JSON {sections[]}, в каждой секции section (название раздела) и categories[] с полями title, slug, criterion (критерий попадания МФО в подборку) и canonical_url страницы. Используйте, чтобы найти подходящую подборку и её slug, например «займ на карту», «займ без отказа», «займы пенсионерам»; содержимое подборки с предложениями МФО возвращает get_category, подбор по числовым параметрам — search_offers. Только чтение, без авторизации и побочных эффектов; лимит 60 запросов в минуту с одного IP (при превышении HTTP 429).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| sections | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds meaningful behavioral context beyond them: no authentication required, no side effects, and a concrete rate limit of 60 requests per minute per IP with HTTP 429 on overflow. This gives the agent actionable expectations for invocation.
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 not bloated; each sentence contributes either behavior, response shape, usage guidance, or constraints. It is slightly longer than strictly necessary because it details the response JSON, which overlaps with the existing output schema, but it remains well-organized and front-loaded with the core purpose.
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 parameterless read-only listing tool, the description covers everything an agent needs: what is returned, how sections are grouped, key fields, sample use cases, sibling routing, authentication expectations, and rate limiting. No important operational gap remains.
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 effectively 100% because the schema is empty. The description explicitly states 'Параметров нет', which is sufficient for this dimension; no additional parameter semantics are 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?
Description opens with a specific verb and resource: returns all thematic collections (витрины) of the ZaimHub catalog, grouped by named sections. It explicitly distinguishes itself from siblings by pointing to get_category and search_offers, so an agent can tell it apart without inspecting 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?
The description gives an explicit use case: find a suitable collection and its slug, with concrete examples. It also names alternatives and when they apply — get_category for collection contents and search_offers for numeric filtering — providing clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает список всех МФО каталога ZaimHub (только организации из государственного реестра Банка России), отсортированный по месту в рейтинге заёмщиков. Параметр limit — сколько МФО вернуть (по умолчанию 50, максимум 100); поле total показывает общее число, постраничной навигации нет. Ответ: JSON {total, mfos[]}, у каждой МФО: name, slug, rating_position, rating_average (0–5), rating_count, текстовые диапазоны amount_range / term_range / rate и canonical_url карточки. Используйте для обзора каталога, сравнения МФО по рейтингу и получения slug; подробная карточка одной МФО — get_mfo, подбор по сумме и сроку — search_offers, тематические подборки — list_categories. Только чтение, без авторизации и побочных эффектов; лимит 60 запросов в минуту с одного IP (при превышении HTTP 429). При использовании данных ссылайтесь на canonical_url.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Сколько МФО вернуть, 1–100 (по умолчанию 50) |
| Name | Required | Description |
|---|---|---|
| mfos | Yes | |
| total | Yes | Всего МФО в каталоге |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Аннотации уже дают readOnlyHint, idempotentHint и destructiveHint, но описание добавляет важный контекст: отсутствие авторизации и побочных эффектов, лимит 60 запросов в минуту, HTTP 429 при превышении, отсутствие пагинации и особенность с полем total. Это выходит за рамки аннотаций и помогает агенту корректно обрабатывать ошибки и ограничения.
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?
Описание плотное, но не перегруженное: сначала назначение, затем параметр, формат ответа, варианты использования и ограничения. Каждое предложение несёт полезную информацию, структура логична и не содержит повторов схемы или аннотаций.
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?
Для инструмента с одним необязательным параметром, выходной схемой и аннотациями описания достаточно: раскрыты критерии возвращаемых данных, состав полей, лимиты, альтернативы и требование атрибуции через canonical_url. Агенту не нужно обращаться к документации за дополнительными деталями.
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?
Схема параметра limit уже полностью документирует тип, минимум, максимум и значение по умолчанию, поэтому базовая оценка 3 оправдана. Описание дополнительно объясняет, как limit взаимодействует с полем total и что постраничной навигации нет, что добавляет смысл, отсутствующий в схеме.
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?
Описание начинается с конкретного глагола «Возвращает» и ресурса «список всех МФО каталога ZaimHub», уточняет источник (реестр Банка России) и порядок сортировки. Чётко отличается от соседних инструментов: перечислены get_mfo, search_offers и list_categories как альтернативы.
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?
Явно указано, когда использовать инструмент: для обзора каталога, сравнения по рейтингу и получения slug. Также названы альтернативы для других сценариев — get_mfo для детальной карточки, search_offers для подбора по сумме и сроку, list_categories для тематических подборок.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Подбирает предложения МФО для новых клиентов по сумме займа (amount, ₽), сроку (term_days, дней) и признаку первого займа под 0% (first_loan_zero: true — только МФО с беспроцентным первым займом). Все фильтры необязательны; без них возвращается весь каталог, поэтому задавайте amount и/или term_days и ограничивайте limit (по умолчанию 15, максимум 100). Результат отсортирован по месту в рейтинге заёмщиков. Ответ: JSON {query, total, truncated, note, offers[]}, у каждого предложения: name, slug, amount_range, term_range, rate, interest_free_days, first_loan_zero_percent (true/false/null, null — не подтверждено), rating_average, canonical_url. Используйте, когда у пользователя есть конкретная сумма или срок; весь каталог по рейтингу — list_mfo, тематические подборки (займ на карту, без отказа и т.п.) — list_categories и get_category, подробности по МФО — get_mfo. Только чтение, без авторизации и побочных эффектов; лимит 60 запросов в минуту с одного IP (при превышении HTTP 429). Условия волатильны — финальные смотрите на canonical_url.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Сколько предложений вернуть, 1–100 (по умолчанию 15) | |
| amount | No | Нужная сумма займа в рублях, например 15000 | |
| term_days | No | Нужный срок в днях, например 30 | |
| first_loan_zero | No | true — только МФО с первым займом под 0% для новых клиентов |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| query | Yes | Применённые фильтры |
| total | Yes | Сколько предложений подошло всего |
| offers | Yes | |
| truncated | Yes | true — вернулась не вся выборка, увеличьте limit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description reinforces this with 'Только чтение, без авторизации и побочных эффектов'. It adds genuinely useful behavioral details: rate limit of 60 requests/minute per IP with HTTP 429 on exceed, sorting by rating, possible truncation, and volatility of terms with final conditions on canonical_url. 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?
The description is long but dense, with the core purpose and usage front-loaded. The response-shape section partly duplicates what an output schema likely provides, so a small deduction is warranted, but the rest — alternatives, rate limits, volatility warning — 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?
For a search tool with four optional parameters, no required fields, and existing annotations, the description covers everything an agent needs: parameter semantics, filtering behavior, result shape, sorting, sibling routing, authentication, rate limits, and caveats about data volatility. Nothing critical 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 base expectation is met. The description adds value beyond the schema by clarifying that all filters are optional, that omitting them returns the entire catalog, and that limit should be constrained (default 15, max 100). It also explains the meaning of first_loan_zero flags more concretely in the response context.
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 action — 'Подбирает предложения МФО для новых клиентов' — and precisely defines the filtering dimensions (amount, term_days, first_loan_zero). It also distinguishes itself from siblings by naming list_mfo, list_categories/get_category, and get_mfo as the tools for related but different use cases.
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 to use this tool ('когда у пользователя есть конкретная сумма или срок') and when to use alternatives ('весь каталог по рейтингу — list_mfo', thematic collections — list_categories/get_category, details — get_mfo). It also warns that all filters are optional and recommends setting amount/term_days and limiting the result.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_category1 field changedOutput schema / properties / topAdded value: +{
+ "additionalProperties": false,
+ "description": "Автотаблицы «Топ-N …» витрины, те же, что на странице и в её .md-версии (до 10 строк каждая, условия для нового клиента)",
+ "properties": {
+ "best_value": {
+ "additionalProperties": false,
+ "description": "Беспроцентный первый займ для нового клиента, по убыванию дней без процентов",
+ "properties": {
+ "criteria": {
+ "description": "Критерий отбора и сортировки",
+ "type": "string"
+ },
+ "rows": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "amount_to_rub": {
+ "description": "Максимальная сумма для нового клиента, ₽",
+ "type": "number"
+ },
+ "canonical_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "interest_free_days": {
+ "description": "Беспроцентный период для нового клиента, дней",
+ "type": "number"
+ },
+ "mfo": {
+ "type": "string"
+ },
+ "rank": {
+ "type": "number"
+ },
+ "rate_per_day_percent": {
+ "description": "% в день для нового клиента, 0 — первый займ под 0 %",
+ "type": "number"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "term_to_days": {
+ "description": "Максимальный срок для нового клиента, дней",
+ "type": "number"
+ }
+ },
+ "required": [
+ "rank",
+ "mfo",
+ "slug",
+ "canonical_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "title": {
+ "description": "Заголовок таблицы, как на странице («Топ-N …»)",
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "criteria",
+ "rows"
+ ],
+ "type": "object"
+ },
+ "max_amount": {
+ "additionalProperties": false,
+ "description": "По максимальной сумме для нового клиента",
+ "properties": {
+ "criteria": {
+ "description": "Критерий отбора и сортировки",
+ "type": "string"
+ },
+ "rows": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "amount_to_rub": {
+ "description": "Максимальная сумма для нового клиента, ₽",
+ "type": "number"
+ },
+ "canonical_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "interest_free_days": {
+ "description": "Беспроцентный период для нового клиента, дней",
+ "type": "number"
+ },
+ "mfo": {
+ "type": "string"
+ },
+ "rank": {
+ "type": "number"
+ },
+ "rate_per_day_percent": {
+ "description": "% в день для нового клиента, 0 — первый займ под 0 %",
+ "type": "number"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "term_to_days": {
+ "description": "Максимальный срок для нового клиента, дней",
+ "type": "number"
+ }
+ },
+ "required": [
+ "rank",
+ "mfo",
+ "slug",
+ "canonical_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "title": {
+ "description": "Заголовок таблицы, как на странице («Топ-N …»)",
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "criteria",
+ "rows"
+ ],
+ "type": "object"
+ },
+ "max_term": {
+ "additionalProperties": false,
+ "description": "По максимальному сроку для нового клиента",
+ "properties": {
+ "criteria": {
+ "description": "Критерий отбора и сортировки",
+ "type": "string"
+ },
+ "rows": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "amount_to_rub": {
+ "description": "Максимальная сумма для нового клиента, ₽",
+ "type": "number"
+ },
+ "canonical_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "interest_free_days": {
+ "description": "Беспроцентный период для нового клиента, дней",
+ "type": "number"
+ },
+ "mfo": {
+ "type": "string"
+ },
+ "rank": {
+ "type": "number"
+ },
+ "rate_per_day_percent": {
+ "description": "% в день для нового клиента, 0 — первый займ под 0 %",
+ "type": "number"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "term_to_days": {
+ "description": "Максимальный срок для нового клиента, дней",
+ "type": "number"
+ }
+ },
+ "required": [
+ "rank",
+ "mfo",
+ "slug",
+ "canonical_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "title": {
+ "description": "Заголовок таблицы, как на странице («Топ-N …»)",
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "criteria",
+ "rows"
+ ],
+ "type": "object"
+ },
+ "note": {
+ "description": "Что это за списки и как ими пользоваться",
+ "type": "string"
+ },
+ "updated": {
+ "description": "Дата изменения страницы, ГГГГ-ММ-ДД",
+ "type": "string"
+ }
+ },
+ "required": [
+ "note"
+ ],
+ "type": "object"
+}get_category2 fields changedInput schema / properties / slug / descriptionAdded value: +"Slug подборки, например «zaim-na-kartu»; берите из list_categories"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "canonical_url": {
+ "description": "Страница подборки на zaimhub.com",
+ "format": "uri",
+ "type": "string"
+ },
+ "criterion": {
+ "description": "Критерий попадания МФО в подборку",
+ "type": "string"
+ },
+ "offers": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "amount_range": {
+ "type": "string"
+ },
+ "canonical_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "rate": {
+ "type": "string"
+ },
+ "rating_average": {
+ "type": "number"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "term_range": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "slug",
+ "canonical_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "sorting": {
+ "description": "Порядок сортировки",
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "total": {
+ "description": "Число МФО в подборке",
+ "type": "number"
+ }
+ },
+ "required": [
+ "slug",
+ "canonical_url",
+ "total"
+ ],
+ "type": "object"
+}get_market_rules1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "country": {
+ "type": "string"
+ },
+ "details_markdown": {
+ "description": "Полный блок «Ключевые факты» в Markdown",
+ "type": "string"
+ },
+ "reviewed_at": {
+ "description": "Дата последней проверки правового блока, YYYY-MM-DD",
+ "type": "string"
+ },
+ "source": {
+ "description": "Первоисточник — llms-full.txt на zaimhub.com",
+ "format": "uri",
+ "type": "string"
+ },
+ "summary": {
+ "description": "Краткий правовой контекст",
+ "type": "string"
+ }
+ },
+ "required": [
+ "country",
+ "reviewed_at",
+ "summary",
+ "details_markdown",
+ "source"
+ ],
+ "type": "object"
+}get_mfo2 fields changedInput schema / properties / slug / descriptionAdded value: +"Slug МФО, например «zaymer»; берите из list_mfo, search_offers или get_category"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "canonical_url": {
+ "description": "Карточка МФО на zaimhub.com",
+ "format": "uri",
+ "type": "string"
+ },
+ "conditions": {
+ "additionalProperties": false,
+ "properties": {
+ "new_client": {
+ "additionalProperties": false,
+ "properties": {
+ "amount": {
+ "description": "Сумма, ₽",
+ "type": "string"
+ },
+ "full_cost_of_credit": {
+ "description": "Полная стоимость кредита (ПСК), % годовых",
+ "type": "string"
+ },
+ "rate": {
+ "description": "Ставка, % в день",
+ "type": "string"
+ },
+ "term": {
+ "description": "Срок",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "repeat_client": {
+ "additionalProperties": false,
+ "properties": {
+ "amount": {
+ "description": "Сумма, ₽",
+ "type": "string"
+ },
+ "full_cost_of_credit": {
+ "description": "Полная стоимость кредита (ПСК), % годовых",
+ "type": "string"
+ },
+ "rate": {
+ "description": "Ставка, % в день",
+ "type": "string"
+ },
+ "term": {
+ "description": "Срок",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "type": "object"
+ },
+ "data_updated_at": {
+ "description": "Дата актуализации записи (ISO 8601)",
+ "type": "string"
+ },
+ "fees": {
+ "additionalProperties": false,
+ "properties": {
+ "early_repayment": {
+ "description": "Досрочное погашение",
+ "type": "string"
+ },
+ "issuance": {
+ "description": "Комиссия за выдачу",
+ "type": "string"
+ },
+ "penalty": {
+ "description": "Штраф при просрочке",
+ "type": "string"
+ },
+ "service": {
+ "description": "Комиссия за обслуживание",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "legal": {
+ "additionalProperties": false,
+ "properties": {
+ "cbr_registry_number": {
+ "description": "Номер записи в госреестре МФО Банка России",
+ "type": "string"
+ },
+ "cbr_registry_url": {
+ "description": "Запись организации в госреестре МФО на cbr.ru — первоисточник для проверки легальности",
+ "format": "uri",
+ "type": "string"
+ },
+ "email": {
+ "type": "string"
+ },
+ "legal_address": {
+ "type": "string"
+ },
+ "legal_entity": {
+ "description": "Юридическое лицо",
+ "type": "string"
+ },
+ "ogrn": {
+ "description": "ОГРН",
+ "type": "string"
+ },
+ "phone": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "name": {
+ "type": "string"
+ },
+ "rating": {
+ "additionalProperties": false,
+ "properties": {
+ "average": {
+ "description": "Средняя оценка, 0–5",
+ "type": "number"
+ },
+ "criteria": {
+ "description": "Оценки по 4 критериям: скорость, условия, поддержка, сайт",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "label": {
+ "type": "string"
+ },
+ "value": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "position": {
+ "description": "Место в рейтинге",
+ "type": "number"
+ },
+ "reviews_count": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "requirements": {
+ "additionalProperties": false,
+ "properties": {
+ "age_max": {
+ "type": "number"
+ },
+ "age_min": {
+ "type": "number"
+ },
+ "citizenship": {
+ "type": "string"
+ },
+ "documents": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ ]
+ },
+ "employment": {
+ "type": "string"
+ },
+ "income_proof": {
+ "type": "string"
+ },
+ "registration": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "summary": {
+ "additionalProperties": false,
+ "properties": {
+ "amount_range": {
+ "type": "string"
+ },
+ "decision_time_minutes": {
+ "type": "number"
+ },
+ "first_loan_zero_percent": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Первый займ под 0%: true / false / null (не подтверждено)"
+ },
+ "full_cost_of_credit_range": {
+ "description": "Диапазон ПСК, % годовых",
+ "type": "string"
+ },
+ "interest_free_days": {
+ "description": "Беспроцентный период первого займа, дней",
+ "type": "number"
+ },
+ "processing_24_7": {
+ "description": "Приём заявок круглосуточно",
+ "type": "boolean"
+ },
+ "rate": {
+ "type": "string"
+ },
+ "term_range": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "first_loan_zero_percent"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "name",
+ "slug",
+ "canonical_url"
+ ],
+ "type": "object"
+}get_reviews3 fields changedInput schema / properties / limit / descriptionAdded value: +"Сколько отзывов вернуть, 1–50 (по умолчанию 10)"Input schema / properties / slug / descriptionAdded value: +"Slug МФО, например «zaymer»; берите из list_mfo или search_offers"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "canonical_url": {
+ "description": "Страница отзывов о МФО на zaimhub.com",
+ "format": "uri",
+ "type": "string"
+ },
+ "mfo_slug": {
+ "type": "string"
+ },
+ "reviews": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "author": {
+ "type": "string"
+ },
+ "date": {
+ "description": "Дата публикации (ISO 8601)",
+ "type": "string"
+ },
+ "rating": {
+ "description": "Оценка 1–5",
+ "type": "number"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "description": "Всего отзывов на сайте",
+ "type": "number"
+ }
+ },
+ "required": [
+ "mfo_slug",
+ "canonical_url"
+ ],
+ "type": "object"
+}list_categories1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "sections": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "categories": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "canonical_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "criterion": {
+ "description": "Критерий попадания МФО в подборку",
+ "type": "string"
+ },
+ "slug": {
+ "description": "Идентификатор подборки для get_category",
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "slug",
+ "canonical_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "section": {
+ "description": "Название раздела",
+ "type": "string"
+ }
+ },
+ "required": [
+ "section",
+ "categories"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "sections"
+ ],
+ "type": "object"
+}list_mfo2 fields changedInput schema / properties / limit / descriptionAdded value: +"Сколько МФО вернуть, 1–100 (по умолчанию 50)"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "mfos": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "amount_range": {
+ "description": "Диапазон суммы займа, ₽",
+ "type": "string"
+ },
+ "canonical_url": {
+ "description": "Карточка МФО на zaimhub.com",
+ "format": "uri",
+ "type": "string"
+ },
+ "name": {
+ "description": "Название МФО",
+ "type": "string"
+ },
+ "rate": {
+ "description": "Ставка для новых клиентов, % в день",
+ "type": "string"
+ },
+ "rating_average": {
+ "description": "Средняя оценка заёмщиков, 0–5",
+ "type": "number"
+ },
+ "rating_count": {
+ "description": "Число отзывов",
+ "type": "number"
+ },
+ "rating_position": {
+ "description": "Место в рейтинге заёмщиков (1 — лучшее)",
+ "type": "number"
+ },
+ "slug": {
+ "description": "Идентификатор МФО для get_mfo и get_reviews",
+ "type": "string"
+ },
+ "term_range": {
+ "description": "Диапазон срока, дни",
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "slug",
+ "canonical_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "description": "Всего МФО в каталоге",
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "mfos"
+ ],
+ "type": "object"
+}search_offers5 fields changedInput schema / properties / amount / descriptionAdded value: +"Нужная сумма займа в рублях, например 15000"Input schema / properties / first_loan_zero / descriptionAdded value: +"true — только МФО с первым займом под 0% для новых клиентов"Input schema / properties / limit / descriptionAdded value: +"Сколько предложений вернуть, 1–100 (по умолчанию 15)"Input schema / properties / term_days / descriptionAdded value: +"Нужный срок в днях, например 30"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "note": {
+ "type": "string"
+ },
+ "offers": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "amount_range": {
+ "type": "string"
+ },
+ "canonical_url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "first_loan_zero_percent": {
+ "anyOf": [
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "interest_free_days": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ },
+ "rate": {
+ "type": "string"
+ },
+ "rating_average": {
+ "type": "number"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "term_range": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "slug",
+ "canonical_url",
+ "first_loan_zero_percent"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "query": {
+ "additionalProperties": false,
+ "description": "Применённые фильтры",
+ "properties": {
+ "amount": {
+ "type": "number"
+ },
+ "first_loan_zero": {
+ "type": "boolean"
+ },
+ "term_days": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "total": {
+ "description": "Сколько предложений подошло всего",
+ "type": "number"
+ },
+ "truncated": {
+ "description": "true — вернулась не вся выборка, увеличьте limit",
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "query",
+ "total",
+ "truncated",
+ "note",
+ "offers"
+ ],
+ "type": "object"
+}get_categoryget_market_rulesget_mfoget_reviewslist_categorieslist_mfosearch_offersRead-only catalog of licensed Kazakhstan MFOs: microloan terms, ARDFM licenses, ratings and reviews.
Read-only catalog of licensed Ukrainian MFOs: loan terms, NBU licenses, ratings and reviews.
Search and analytics for Russian public procurement (44-FZ/223-FZ): tenders, contracts, market data
RU merchant catalog for AI agents: live price, stock, choices and controlled checkout. Not x402.
Add one secure layer between your agents and this server.
