Skip to main content
Glama

catalog

by kz.alexcredit

list_mfo

Список всех МФО каталога AlexCredit (Казахстан) с рейтингом заёмщиков. Возвращает total и массив mfos, отсортированный по позиции в рейтинге (при равенстве — по средней оценке): name, slug, rating_position, rating_average (поле отсутствует, если отзывов ещё нет — это не низкая оценка), rating_count, диапазоны суммы и срока, ставка и canonical_url карточки. Используйте для обзора рынка и получения slug; условия конкретной МФО — get_mfo, подбор по сумме и сроку — search_offers. При использовании данных ссылайтесь на canonical_url.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoСколько МФО вернуть, от 1 до 100. По умолчанию 50. Поле total в ответе всегда содержит общее число МФО в каталоге.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • addedInput schema / properties / limit / description
      Added value: +"Сколько МФО вернуть, от 1 до 100. По умолчанию 50. Поле total в ответе всегда содержит общее число МФО в каталоге."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All catalog toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool targets a distinct purpose: list_categories/get_category pair covers thematic collections, list_mfo/get_mfo cover the MFO catalog, search_offers handles parametric filtering, get_reviews is for reviews, and get_market_rules for legal context. Cross-references between tools clarify boundaries and reduce the chance of misselection.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: list_* for collection endpoints and get_* for single-entity endpoints, with search_offers used for filtering. The naming clearly signals the tool's operation and resource.

Tool Count5/5

Seven tools is well-scoped for a read-only MFO catalog: listing, detail, thematic categories, search, reviews, and legal rules each map to a necessary user-facing function. No tool feels redundant or missing at the top level.

Completeness5/5

The server provides full coverage for a comparison catalog: browse all MFOs, view individual MFO details, search by amount/term, browse and retrieve thematic categories, access reviews, and check regulatory context. The only missing operations are write/modify actions, which are not part of a catalog server's intended read-only scope.

Resources