Read-only catalog of Russian MFOs: loan terms, Bank of Russia registry data, ratings, reviews.
Подборка займов: критерий попадания, сортировка, таблица предложений МФО с условиями.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives minimal behavioral context. It mentions eligibility criteria, sorting, and a table of offers, but does not disclose read-only nature, error behavior, pagination, or any side effects. The description carries the full burden but does not fulfill it.
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 a single concise sentence, but it lacks front-loading of the main purpose and is under-specified. While there is no wasted verbiage, the information provided is insufficient for selecting or invoking the tool correctly.
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 one parameter, no output schema, and no annotations, the description should explain the tool's behavior and return value comprehensively. It does not even mention that the tool retrieves a category by slug, nor does it describe the output structure beyond vague content mentions. Incomplete for an agent to use correctly.
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 defines a single required parameter 'slug' with minLength 1, but the description does not mention 'slug' at all. Schema description coverage is 0%, and the description fails to compensate by explaining what the parameter represents or how to use it.
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 'Подборка займов' translates to 'Loan selection', which describes the content of the result rather than the tool's action. It does not explicitly state that this tool retrieves a category by slug, and it fails to distinguish itself from the sibling tool list_categories. The verb is missing, making the purpose vague.
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?
There is no guidance on when to use this tool versus alternatives like list_categories or get_market_rules. No context or exclusions are provided, so the agent cannot infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Правовой контекст микрозаймов в России (ставка 0,8%/день, лимит переплаты 100%, 151-ФЗ/353-ФЗ, самозапрет, период охлаждения) с датой последней проверки.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral transparency. It discloses the content and the presence of a 'date of last check,' but does not mention side effects, permissions, network calls, update behavior, or any other operational traits. This is a significant gap for a tool with no structural safety hints.
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 a single, compact sentence that front-loads the core topic and packs key details without any fluff. It is appropriately sized for a tool with no parameters and an output that can be summarized in one line.
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 lists the main elements of the legal context and mentions the date of last check, giving a good sense of the returned content. However, it does not specify the return format (e.g., structured JSON vs. plain text), and since there is no output schema, this ambiguity leaves a notable gap.
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 input schema has zero properties, so schema coverage is 100% vacuously. The description adds no parameter semantics, but with no parameters to document, a baseline of 4 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 clearly identifies the resource as 'legal context of microfinance loans in Russia' and enumerates specific details (rate, overpayment limit, laws, etc.), distinguishing it from sibling tools about categories, MFOs, or reviews. However, it lacks an explicit verb, relying on the tool name 'get' to imply the retrieval action.
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?
There is no guidance about when to use this tool versus alternatives. The description does not mention any usage context, exclusions, or reference to sibling tools, leaving the agent to infer the tool's purpose without any comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Карточка МФО: условия для новых и повторных клиентов, требования, комиссии, юрданные (ОГРН, реестр ЦБ РФ), рейтинг по 4 критериям, дата актуализации записи.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the diverse data fields included (conditions, requirements, commissions, legal data, rating, actualization date), which is useful. However, it omits response format, error behavior, and whether it returns a single object or collection.
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 a single efficient sentence that packs many content categories. It is concise, though a structured list could improve scannability. Every phrase contributes substance.
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 simple get-by-slug tool, the description offers a strong overview of the response content but lacks practical details like how to find the slug and what the output shape is. It is adequate but not fully complete.
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 has one parameter (slug) with zero documentation, and the description never mentions it. While the slug name is self-explanatory, the description adds no value for understanding how to supply or obtain the slug. Low schema coverage demands compensation that is not provided.
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 indicates the tool returns a detailed MFO card with specific content categories (conditions, commissions, legal data, rating). The verb is implied by the resource type but not explicitly stated. It effectively distinguishes from list_mfo by focusing on a single card's detailed content.
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?
No guidance is provided about when to use this tool versus sibling tools like list_mfo or search_offers. The description only outlines the content returned, not the selection criteria or business context for choosing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Последние отзывы заёмщиков о МФО: оценка, дата, текст (только публичные данные сайта).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does add useful context by mentioning that only public site data is returned and specifies the fields (rating, date, text). However, it omits details about pagination, ordering, or response format, so the transparency is partial.
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 a single, focused sentence that directly conveys the tool's purpose and scope. It contains no filler or redundant information, earning a high conciseness score.
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 tool is relatively simple, but the description is minimal. It does not explain parameter meanings, usage scenarios, or return value structure. With no output schema and no annotations, the description should provide more detail to be considered complete.
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 defines a required 'slug' and optional 'limit', but the description provides no explanation or added meaning for these parameters. With 0% schema coverage, the description fails to compensate, leaving parameter semantics entirely to 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 clearly states the tool retrieves latest borrower reviews of MFOs, specifying contained data (rating, date, text). This clearly distinguishes it from sibling tools like get_category, list_mfo, and search_offers, which serve different purposes.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention other tools or any exclusions, leaving the usage context entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Все подборки займов каталога с группировкой (популярные, по способу получения, по сумме и сроку, по категориям заёмщиков) и критерием попадания.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It effectively discloses the output structure (grouping and inclusion criterion), giving the agent insight into what will be returned. While it does not explicitly state that it is read-only or describe side effects, the nature of a list operation makes this largely self-evident.
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 a single sentence that efficiently captures the tool's scope and output grouping. It is front-loaded with the main object ('all catalog loan selections') and includes necessary details without any wasted words.
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 list operation without an output schema, the description is quite complete: it states what is listed and how the results are grouped and the inclusion criterion. It could theoretically mention sibling tools, but that is covered under usage guidelines. The simplicity of the tool makes this description sufficient.
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 input schema has zero parameters, so the description has no parameter details to add. With empty schema coverage at 100%, the baseline of 4 is appropriate since there is no parameter information to elaborate on.
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 catalog loan selections with grouping by various criteria (popular, by method, amount/term, borrower categories) and the inclusion criterion. This specific resource and grouping logic distinguish it from siblings like get_category, which likely targets a single category.
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 no guidance on when to use this tool versus alternatives such as get_category or list_mfo. It does not mention exclusions or specific contexts, leaving the agent without clear usage direction relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Список всех МФО каталога с рейтингом заёмщиков и canonical_url карточек. Данные zaimhub.com, при использовании ссылайтесь на canonical_url.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It adds useful context about the data source (zaimhub.com) and attribution requirement (refer to canonical_url). However, it does not disclose pagination behavior, the effect of the limit parameter, or any default ordering, which are relevant for a list endpoint.
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 two sentences and fully front-loaded with the core purpose. The second sentence adds an important attribution requirement without verbosity. No wasted words 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 simple list tool with one optional parameter and no output schema, the description covers the basic functionality and attribution. However, it lacks details about pagination, the meaning of 'all' relative to the limit parameter, and the structure of the response, leaving moderate ambiguity for an agent.
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 has 0% description coverage for the only parameter (limit). The description does not mention the limit parameter or explain how it controls results (e.g., pagination, max count). While the parameter name is self-explanatory, the description adds no semantic value or usage nuance beyond the raw schema constraints.
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 lists all MFOs in the catalog, with a specific verb ('list'), resource ('MFOs'), and scope ('all'). It distinguishes from sibling get_mfo by emphasizing the plural full-catalog nature, and from list_categories by naming a different entity type.
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 implies usage when you need the full MFO list, but it does not explicitly contrast with get_mfo for a single entry or search_offers for filtering. No exclusions or alternative guidance is provided, leaving the 'when-not-to-use' undocumented.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Подбор предложений МФО по сумме (₽), сроку (дней) и признаку «первый займ под 0%» (first_loan_zero_percent: true/false/null, null = не подтверждено). Call without filters returns the full catalog (use limit); prefer passing amount/term for targeted results.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| amount | No | ||
| term_days | No | ||
| first_loan_zero | No |
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 the full-catalog behavior when unfiltered and explains the null semantics of first_loan_zero. However, it omits details about output format, pagination, or any side effects beyond reading.
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?
Two concise sentences deliver purpose, filter semantics, and usage guidance without any filler. The most important information 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 4-parameter search tool with no output schema or annotations, the description covers the main filter dimensions, the unfiltered-call consequence, and the limit suggestion. It could further explain the limit parameter and return shape, but it is sufficient for confident 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?
With 0% schema description coverage, the description compensates by explaining amount (₽), term (days), and the first_loan_zero flag including its true/false/null meaning. The limit parameter is only referenced as a hint ('use limit') but not fully documented, leaving a small gap.
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 specifies that the tool selects MFO offers by amount, term, and the first-loan-zero flag. These distinct filter dimensions differentiate it from sibling read-only tools like get_mfo or 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?
It explicitly warns that calling without filters returns the full catalog and advises using limit, and recommends filtering by amount/term for targeted results. It doesn't list alternative tools, but the guidance is clear enough for basic usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
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
Read-only U.S. mortgage market, lender, GSE performance, and servicing analytics.
Read-only data on 3.9M Romanian companies: search, profiles, financials, status, CAEN.
Add one secure layer between your agents and this server.
Each tool has a distinct primary function: listing vs. retrieving single entities, searching offers, and retrieving rules/reviews. The only potential ambiguity is between get_category (curated collections) and search_offers (parameter-based search), but their descriptions clarify the purpose.
All tool names follow a consistent verb_noun pattern: get_ for single items, list_ for collections, and search_ for query-based retrieval. No mixed conventions or vague verbs.
Seven tools is well-scoped for a read-only catalog server, covering all major resources without redundancy or bloat.
The surface covers the full domain: categories, MFO details, reviews, market rules, and search. As a read-only catalog, no CRUD operations are needed, and no obvious gaps exist.
