Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@checko-mcp search company by INN 7707083893"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP-сервер для Checko.ru API v2 — проверка российских компаний, ИП, физлиц и юридических данных прямо из любого AI-ассистента, поддерживающего Model Context Protocol.
Неофициальный community-проект. Не аффилирован с ООО «Чекко». Использует публичный API Checko.ru — нужен собственный API-ключ.
Этот сервер — MCP-инструмент, а не самостоятельный агент. Данные берутся из API Checko.ru, но интерпретирует и излагает их AI-ассистент, к которому вы подключили сервер. AI-модели могут ошибаться: путать поля ответа, делать неверные выводы, галлюцинировать факты или пропускать важные детали. Перед принятием любых деловых, юридических или финансовых решений самостоятельно проверяйте ключевые сведения в первоисточниках (ЕГРЮЛ/ЕГРИП на сайте ФНС, КАД.Арбитр, ЕФРСБ и т. д.).
Сервер выставляет три типа возможностей MCP:
12 инструментов (tools) — прямой доступ к эндпоинтам Checko API.
6 готовых сценариев (prompts) — типовые workflow с уже зашитой последовательностью вызовов: check_counterparty, verify_bank_details, assess_bankruptcy_risk, audit_person, evaluate_tender_participant, analyze_finances.
5 справочных ресурсов (resources) — agent guide, правовая справка (152-ФЗ), методология аудита физлица.
Инструмент | Описание |
| Поиск компаний и ИП по названию, ИНН, ОГРН, ОКВЭД и другим критериям |
| Данные ЕГРЮЛ по организации (ОГРН или ИНН) |
| Данные ЕГРИП по индивидуальному предпринимателю |
| Информация о физическом лице по ИНН |
| Финансовая отчётность организации (Росстат, ГИР БО ФНС) |
| Арбитражные дела с фильтрацией по роли, датам и сумме иска |
| Государственные контракты по 44-ФЗ и 223-ФЗ |
| Проверки организации или ИП |
| Информация о банке по БИК |
| История изменений организации, ИП или физлица |
| Сообщения Федресурса (ЕФРСФДЮЛ) |
| Записи ЕФРСБ (реестр банкротств) |
Related MCP server: @theyahia/casebook-mcp
checko.ru/user/account/api — потребуется регистрация.
Самый простой способ — через uvx (не нужен git clone, Docker или venv). Добавьте запись в конфиг MCP вашего AI-клиента:
{
"mcpServers": {
"checko": {
"command": "uvx",
"args": ["checko-mcp"],
"env": { "CHECKO_API_KEY": "ваш_ключ" }
}
}
}Перезапустите MCP-клиент — сервер появится в списке доступных инструментов.
Нет
uvx? Установитеuv— он включаетuvx.
git clone https://github.com/Nymaxxx/checko-mcp.git
cd checko-mcp
cp .env.example .env
# отредактируйте .env: CHECKO_API_KEY=ваш_ключ
docker compose build{
"mcpServers": {
"checko": {
"command": "docker",
"args": [
"compose",
"-f", "/абсолютный/путь/checko-mcp/docker-compose.yml",
"run", "--rm", "-i", "checko-mcp"
]
}
}
}CHECKO_API_KEY подхватится из .env автоматически.
docker build -t checko-mcp:latest .{
"mcpServers": {
"checko": {
"command": "docker",
"args": [
"run", "--rm", "-i",
"-e", "CHECKO_API_KEY=ваш_ключ",
"checko-mcp:latest"
]
}
}
}git clone https://github.com/Nymaxxx/checko-mcp.git
cd checko-mcp
python -m venv .venv
source .venv/bin/activate # Linux / macOS
# .venv\Scripts\activate # Windows
pip install -e .{
"mcpServers": {
"checko": {
"command": "/абсолютный/путь/checko-mcp/.venv/bin/python",
"args": ["-m", "checko_mcp"],
"env": {
"CHECKO_API_KEY": "ваш_ключ"
}
}
}
}На Windows путь до интерпретатора выглядит так:
C:\\путь\\checko-mcp\\.venv\\Scripts\\python.exe.
В большинстве случаев ручной pipeline не нужен — вызовите подходящий prompt, в котором уже зашита правильная последовательность инструментов и шаблон финального ответа.
Prompt | Аргументы | Назначение |
|
| Комплексная проверка контрагента: search → company → finances → legal_cases → fedresurs → bankruptcy |
|
| Проверка платёжных реквизитов: get_company/get_entrepreneur + get_bank |
|
| Оценка риска банкротства по 4 источникам сигналов |
|
| Полный аудит физлица по методологии (требует законного основания) |
|
| Оценка участника тендера: контракты, проверки, иски, финансы |
|
| Динамика выручки, прибыли, капитала за N лет |
В большинстве MCP-клиентов prompts видны как явные команды (slash-меню) и появляются в списке после подключения сервера.
Сервер также экспонирует markdown-справочники, которые AI-клиент может подгрузить в контекст:
URI | Содержание |
| Agent guide: правила, поля ответов, факторы риска, анти-паттерны |
| Правовые ограничения (152-ФЗ, 149-ФЗ) |
| Полная методология аудита физлица |
| Чеклист аномалий с приоритизацией |
| Шаблон отчёта аудита |
Переменная | Обязательная | Описание |
| да | API-ключ Checko.ru |
| нет | Базовый URL (по умолчанию |
| нет | Таймаут запроса в секундах (по умолчанию |
docs/examples.md — комплексные примеры использования (распутывание схемы, batch-фильтрация, анализ номинала, реконструкция нарратива)
docs/api/ — справочник по эндпоинтам Checko API
docs/instructions/agent-guide.md — agent guide (он же экспонируется как ресурс checko://docs/agent-guide)
playbooks/audit/ — методология и шаблоны аудита физлица (экспонируется как ресурсы checko://playbooks/audit/*)
AGENTS.md — соглашения по коду и инструкции для разработчика
CHANGELOG.md — история версий
CONTRIBUTING.md — как внести вклад
SECURITY.md — как сообщить об уязвимости
LEGAL.md — правовые основания (152-ФЗ, 149-ФЗ)
git clone https://github.com/Nymaxxx/checko-mcp.git
cd checko-mcp
python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"
ruff check src/ tests/
pytest -qCI прогоняет lint + тесты на Python 3.10–3.13 для каждого PR.
Сервер предоставляет доступ к публично раскрытым сведениям государственных реестров (ЕГРЮЛ, ЕГРИП, ГИР БО ФНС, Росстат, КАД, ЕФРСФДЮЛ, ЕФРСБ).
Использование данных о физических лицах регулируется Федеральным законом от 27.07.2006 № 152-ФЗ «О персональных данных». Пользователь самостоятельно обеспечивает соответствие своей деятельности требованиям законодательства.
Сервер является программной обёрткой над API Checko.ru. Пользователь обязан ознакомиться с условиями использования Checko.ru и соблюдать их.
Массовый автоматизированный сбор персональных данных физических лиц без законного основания недопустим.
Подробнее — LEGAL.md.
MIT.
Получить информацию о банке или кредитной организации РФ по БИК. Возвращает наименование, адрес, корреспондентский и расчётные счета.
| Name | Required | Description | Default |
|---|---|---|---|
| bic | Yes | БИК банка или кредитной организации (9 цифр) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, yet the description fails to disclose any behavioral traits such as read-only nature, authentication requirements, rate limits, or error conditions. It only describes basic functionality.
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?
Single sentence is concise and front-loaded with the core action. However, the Russian text is slightly longer than necessary, but still efficient.
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 lookup tool with one parameter and no output schema, the description provides sufficient context: purpose, parameter, and return fields. It is complete enough for this simplicity.
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 the bic parameter. The description adds no additional meaning beyond restating that BIK is used, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'get' and resource 'bank info by BIK', listing specific return fields (name, address, accounts). It distinguishes from sibling tools that cover different entities like bankruptcy, companies, and contracts.
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?
Description implies usage via BIK but provides no explicit guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Получить записи ЕФРСБ (Единого федерального реестра сведений о банкротстве) по организации, ИП или физлицу. Поддерживает фильтрацию по датам и постраничный вывод. (v2.4)
| Name | Required | Description | Default |
|---|---|---|---|
| ogrn | No | ОГРН организации или ОГРНИП предпринимателя | |
| inn | No | ИНН организации, предпринимателя или физлица | |
| date_from | No | Дата от (формат YYYY-MM-DD) | |
| date_to | No | Дата до (формат YYYY-MM-DD) | |
| limit | No | Количество элементов на страницу (макс. 100) | |
| page | No | Номер страницы | |
| sort | No | Сортировка: 'date' (по возрастанию) или '-date' (по убыванию) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention whether the tool is read-only, destructive, requires authentication, or has rate limits. The only behavioral hint is that it supports filtering and pagination.
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 extremely concise, using two sentences with no extraneous words. It is front-loaded with the core purpose and includes version info 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?
Given the tool has 7 parameters and no output schema, the description is brief. It explains the resource and basic features but lacks details on return format, error handling, or pagination specifics. It is functional but not comprehensive.
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 all parameters. The description adds context by specifying support for filtering by dates and pagination, but does not elaborate on individual parameter details beyond what the schema provides.
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 verb 'Получить' (get), the specific resource 'записи ЕФРСБ' (bankruptcy records), and the scope for organizations, individual entrepreneurs, or individuals. It distinguishes from siblings like 'get_fedresurs' by explicitly focusing on bankruptcy data.
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 mentions supported features (date filtering and pagination) but does not provide explicit guidance on when to use this tool versus alternatives like 'get_company' or 'get_person'. No exclusions or prerequisites are stated.
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 |
|---|---|---|---|
| ogrn | No | ОГРН организации (13 цифр) | |
| inn | No | ИНН организации (10 цифр) | |
| source | No | Если true — возвращает исходные XML-данные ЕГРЮЛ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does not disclose non-obvious behaviors such as rate limits, error handling, or whether the tool is read-only. It does list the types of data returned (managers, founders, licenses, taxes, etc.), which provides some context but lacks critical behavioral details.
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 Russian sentence that efficiently conveys the tool's purpose and output, without unnecessary fluff. It could be slightly more structured by splitting into two sentences for readability, but it remains clear.
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 lack of output schema and annotations, the description covers core aspects: purpose, input parameters, and output categories. However, it does not clarify whether at least one of OGRN or INN is required, nor does it mention error cases or performance characteristics.
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 describes all three parameters (ogrn, inn, source). The description adds value by specifying that OGRN must be 13 digits and INN 10 digits, and that the 'source' parameter returns raw XML data. This clarifies usage beyond 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 verb 'Получить' (get), the resource 'сведения об организации из ЕГРЮЛ' (company data from EGRUL), and the input methods 'по ОГРН или ИНН' (by OGRN or INN). It lists the types of data returned, distinguishing it from sibling tools like get_entrepreneur (individual entrepreneurs) and get_person (individuals).
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 indicates when to use the tool: to get company information by OGRN or INN. It implicitly distinguishes from siblings by specifying that it returns data about organizations (not individuals). However, it does not explicitly state when not to use it or mention alternatives like the search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Получить государственные контракты по 44-ФЗ или 223-ФЗ с участием организации или ИП. Параметр law обязателен — API возвращает контракты только по одному закону за вызов.
| Name | Required | Description | Default |
|---|---|---|---|
| ogrn | No | ОГРН организации | |
| inn | No | ИНН организации | |
| law | Yes | Закон о госзакупках: '44' (44-ФЗ) или '223' (223-ФЗ). Обязателен. | |
| role | No | Роль: 'customer' (заказчик) или 'supplier' (поставщик) | |
| limit | No | Количество элементов на страницу (макс. 100) | |
| page | 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 of behavioral disclosure. It correctly states the mandatory 'law' parameter and the single-law-per-call behavior. However, it does not mention whether the operation is read-only, authentication requirements, or any rate limits. For a simple retrieval tool, this is adequate but not rich.
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 extremely concise with two sentences, no redundant words, and directly communicates the essential information. Every sentence serves a 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?
Given the tool has 6 parameters, no output schema, and no annotations, the description is adequate for basic usage but could be improved by mentioning pagination defaults, response structure, or any rate limits. It covers the core functionality but leaves some gaps for an agent to infer.
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 value by explaining that 'law' is mandatory and that the API returns contracts for one law, which is extra context beyond the schema. However, it does not elaborate on other parameters beyond what the schema already provides.
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 verb 'get' and resource 'государственные контракты' (government contracts) with specific laws (44-FZ or 223-FZ) and participants (organization or individual entrepreneur). It distinguishes well from sibling tools which cover different entities (company, bank, etc.).
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 that the 'law' parameter is mandatory and returns contracts for one law per call. While it does not mention when not to use or alternatives, the context is clear and the sibling tools are distinct, so usage is well 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 |
|---|---|---|---|
| ogrnip | No | ОГРНИП индивидуального предпринимателя (15 цифр) | |
| inn | No | ИНН физического лица — индивидуального предпринимателя (12 цифр) | |
| okpo | No | Код ОКПО предпринимателя | |
| source | No | Если true — возвращает исходные XML-данные ЕГРИП |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It describes the returned data categories but does not mention side effects, permissions, or operational constraints (e.g., whether it is read-only, has rate limits, or requires authentication). The tool name implies read-only behavior, which partially compensates.
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 sentences, front-loaded with the purpose and ending with a list of returned data. No extraneous information. Every sentence 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?
The description lists high-level return categories (USRIP data, licenses, taxes, risk factors, affiliated persons) but lacks details on the structure or format of the response. Since there is no output schema, this is a gap. For a tool with 4 optional parameters, the description is adequate but not comprehensive.
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% (all parameters have descriptions). The description adds no additional meaning beyond the schema; it simply lists identifier types in the first sentence. The source parameter is described in the schema, and no new constraints or relationships are 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 states the tool's purpose: retrieve information about an individual entrepreneur from ЕГРИП by OGRNIP, INN, or OKPO. It lists the types of data returned (USRIP data, licenses, taxes, risk factors, affiliated persons). This distinguishes it from sibling tools like get_company (legal entities) and get_person (individuals), which cover different entities.
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 clear context that the tool is for individual entrepreneurs, enabling an agent to infer when to use it over alternatives (e.g., use get_company for legal entities). However, it does not explicitly state when not to use it or specify prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Получить сообщения Федресурса (ЕФРСФДЮЛ) по организации или ИП. Поддерживает фильтрацию по типу сообщения, роли, датам и постраничный вывод. (v2.4)
| Name | Required | Description | Default |
|---|---|---|---|
| ogrn | No | ОГРН организации или ОГРНИП предпринимателя | |
| inn | No | ИНН организации или предпринимателя | |
| type | No | Тип сообщения Федресурса (например, 'CreditorIntentionGoToCourt') | |
| role | No | Роль: 'all' (все, по умолчанию) или 'publisher' (только публикатор) | |
| date_from | No | Дата от (формат YYYY-MM-DD) | |
| date_to | No | Дата до (формат YYYY-MM-DD) | |
| limit | No | Количество элементов на страницу (макс. 100) | |
| page | No | Номер страницы | |
| sort | No | Сортировка: 'date' (по возрастанию) или '-date' (по убыванию) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions filtering and pagination but does not disclose read-only nature, authentication needs, rate limits, or behavior when no results are found.
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 concise (one sentence) and front-loaded with the main purpose. The version number is minor but acceptable. No 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?
Given 9 parameters and no output schema, the description is too minimal. It does not explain that ogrn or inn is likely required, nor does it provide guidance on parameter combinations or expected output structure.
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 covers 100% of parameters with descriptions, achieving baseline. The description adds high-level context about filtering but no parameter-specific meaning beyond 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 Fedresurs messages for a company or individual entrepreneur, with filtering and pagination. It is specific and distinguishes from sibling tools that deal with other data types.
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 use for Fedresurs messages but does not explicitly state when to use this tool versus alternatives like get_company or get_entrepreneur. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Получить финансовую отчётность российской организации по ОГРН или ИНН (данные Росстата и ГИР БО ФНС, 2011–2023 гг.).
| Name | Required | Description | Default |
|---|---|---|---|
| ogrn | No | ОГРН организации | |
| inn | No | ИНН организации | |
| extended | No | Если true — расширенная версия отчётности с детализацией по строкам |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, yet the description fails to disclose behavioral traits beyond the data source scope. It omits auth requirements, rate limits, response format, or whether results are paginated. For a read tool, safety is assumed but not confirmed.
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?
A single, well-structured sentence with all essential information. No redundancy or filler. Front-loaded with the verb and resource.
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 3 parameters and no output schema, the description provides some context (data sources, time range) but lacks detail on output structure, default behavior, and edge cases. Adequate for a simple retrieval but not fully comprehensive.
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% with baseline at 3. The description adds context (data sources and years) but does not elaborate on parameter semantics beyond what the schema provides. The 'extended' parameter remains undefined.
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 financial statements of Russian organizations using OGRN or INN, specifying data sources and date range. This distinguishes it from sibling tools focused on other entity details like bank, company, or entrepreneur.
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 by specifying input identifiers but does not contrast with alternative tools or state when to use this over others. No explicit when-not-to-use guidance is provided.
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 |
|---|---|---|---|
| ogrn | No | ОГРН организации | |
| inn | No | ИНН организации | |
| limit | No | Количество элементов на страницу (макс. 100) | |
| page | No | Номер страницы |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states purpose, not behavioral traits like read-only nature, rate limits, or authentication needs. Does not disclose response format or pagination behavior.
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?
Single, direct sentence in Russian with no unnecessary words. Efficiently conveys core functionality.
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 tool with no output schema or annotations, description explains the query parameters (identifiers) but omits pagination parameter usage (limit, page) and expected return structure. 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?
Schema coverage is 100%, providing baseline 3. Description adds context by indicating OGRN or INN are alternatives and mentions scheduled/unscheduled inspections, adding meaning beyond 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?
Description clearly states verb 'get', resource 'inspections', and specifies entity type (organization or IP) and identifiers (OGRN or INN). It distinguishes from sibling tools that target other entities.
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 explicit when-to-use or alternatives mentioned. However, sibling tools cover different resources, so usage is implied by entity type. Missing guidance on which identifier to use or pagination best practices.
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 |
|---|---|---|---|
| ogrn | No | ОГРН организации или ОГРНИП предпринимателя | |
| inn | No | ИНН организации или предпринимателя | |
| role | No | Роль в деле: 'plaintiff' (истец) или 'defendant' (ответчик) | |
| actual | No | Если true — только актуальные дела (без отклонённых и прекращённых) | |
| active | No | Если true — только активные (незавершённые) дела | |
| date_from | No | Дата от (формат YYYY-MM-DD) | |
| date_to | No | Дата до (формат YYYY-MM-DD) | |
| claim_amount_from | No | Минимальная сумма исковых требований, руб. | |
| claim_amount_to | No | Максимальная сумма исковых требований, руб. | |
| limit | No | Количество элементов на страницу (макс. 100) | |
| page | No | Номер страницы | |
| sort | No | Сортировка: 'date' (по возрастанию) или '-date' (по убыванию) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden for behavioral transparency. It only describes inputs and filtering, but fails to disclose any behavioral traits such as side effects, authentication needs, rate limits, error handling, or return data structure. This is a significant gap for a tool with 12 parameters.
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, well-structured sentence in Russian that efficiently lists the core functionality and key filters. It is concise and front-loaded, but could be slightly more structured (e.g., bullet points) for readability.
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 12 parameters and no output schema, the description is too brief. It does not explain pagination behavior beyond 'постраничный вывод', nor does it clarify required vs optional parameters (e.g., OGRN/INN), error cases, or the shape of the response. This lack of completeness hinders 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 each parameter has a description. The tool description provides a high-level overview of supported filters but adds minimal semantic value beyond what the schema already provides. For example, it mentions filtering by role and dates but does not clarify interactions (e.g., both role and actual filters). Baseline 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?
Description clearly states the tool retrieves arbitration cases for an organization or sole proprietor using OGRN/OGRNIP or INN. It lists supported filters (role, dates, status, claim amount) and pagination. Distinct from sibling tools like get_company or get_person, which focus on different entities.
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?
Description provides clear context on what the tool does and its filtering capabilities. However, it does not explicitly state when to use it versus alternatives or mention required parameters (e.g., at least one of OGRN or INN is needed). Exclusions or prerequisites are absent.
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 |
|---|---|---|---|
| inn | Yes | ИНН физического лица (12 цифр) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It lists the types of information returned but does not disclose behavioral traits such as data freshness, rate limits, side effects, or that the operation is read-only.
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 front-loads the main purpose and then lists specific data types. It is somewhat long but efficient, with no 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?
Given the single parameter, no output schema, and no annotations, the description provides a fairly complete list of returned data categories. However, it lacks explanation of the response format or any usage constraints.
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 provides a description for the 'inn' parameter ('ИНН физического лица (12 цифр)'), and the description does not add further meaning beyond that. Baseline 3 is appropriate since schema coverage is 100%.
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 information about an individual by TIN and lists specific data categories (organizations, trademarks, bankruptcies, etc.), making it distinct from siblings like get_company or get_entrepreneur.
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 for individual data lookup but provides no explicit guidance on when to use this versus alternatives like get_entrepreneur or search. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Получить историю основных изменений организации, ИП или аффилированного физлица по ОГРН/ОГРНИП или ИНН. Для физлица укажите ИНН, чтобы получить полную историю. (v2.4)
| Name | Required | Description | Default |
|---|---|---|---|
| ogrn | No | ОГРН организации или ОГРНИП предпринимателя | |
| inn | 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 for behavioral disclosure. It only states that the tool retrieves history, but fails to mention any behavioral traits such as read-only nature, authentication requirements, rate limits, or what constitutes 'main changes'. The hint about INN for individuals adds minimal behavioral context.
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 concise: one main sentence in Russian with a clarifying follow-up. It is front-loaded with the core purpose and contains no redundant information.
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 no output schema and no annotations, the description covers the basic purpose and a usage hint but lacks details on return format, pagination, or scope of 'main changes'. It is minimally adequate for a simple tool with two optional parameters.
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% with both parameters described. The description adds value by explaining the combined use of parameters (OGRN/OGRNIP or INN) and a specific usage hint for individuals to use INN for complete history, which goes beyond the schema strings.
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 the history of major changes for organizations, individual entrepreneurs, or affiliated individuals using OGRN/OGRNIP or INN. It specifies the entity types and identifiers, distinguishing it from sibling tools that likely fetch current details (e.g., get_company, get_person).
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 for obtaining change history and adds a conditional hint for individuals to use INN for complete history. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Поиск организаций и ИП в реестрах ЕГРЮЛ/ЕГРИП. Обязательно укажите критерий поиска by (например, 'name' — по названию, 'okved' — по коду деятельности) и тип объекта obj ('org' — юрлицо). Для поиска юрлица по ОГРН/ИНН используйте get_company, не search.
| Name | Required | Description | Default |
|---|---|---|---|
| by | Yes | Критерий поиска. Проверенные значения: 'name' — по наименованию, 'okved' — по коду ОКВЭД-2. Другие критерии могут быть отвергнуты API. | |
| obj | Yes | Тип объекта поиска. Сейчас API стабильно поддерживает 'org' (юрлицо). | |
| query | Yes | Строка поиска: название (для by='name') или код (для by='okved'). | |
| region | No | Код региона РФ (например, '77' для Москвы) — дополнительный фильтр | |
| codes | No | Передайте 'all' для поиска по дополнительным кодам ОКВЭД-2 (v2.4) | |
| date_from | No | Дата регистрации от (формат YYYY-MM-DD) | |
| date_to | No | Дата регистрации до (формат YYYY-MM-DD) | |
| limit | No | Количество элементов на страницу (макс. 100) | |
| page | No | Номер страницы |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It does warn that other criteria may be rejected by API, but lacks details on read-only nature, pagination behavior, or return format. Adequate but not comprehensive.
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 sentences, front-loaded with purpose and usage. Every clause adds value—no filler. Efficient and well-structured.
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 9 parameters and no output schema, the description provides essential context: what it searches, required fields, and a sibling alternative. Missing details on output format and pagination limits, but overall complete enough for a search tool.
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 has 100% coverage, so baseline is 3. Description adds value beyond schema by explaining required parameters with examples, and clarifying that 'codes' parameter accepts 'all' for additional OKVED codes.
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 searches for organizations and individual entrepreneurs in specific registers (EGRUL/EGRIP). It specifies required parameters (by, obj) with examples, distinguishing it from sibling get_company.
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 tells when to avoid this tool: 'Для поиска юрлица по ОГРН/ИНН используйте get_company, не search.' Also instructs to specify by and obj criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct entity or data type: bank, company, entrepreneur, person, bankruptcies, contracts, inspections, legal cases, finances, timeline, and a general search. No overlap in purpose.
All tool names follow a consistent 'get_<entity>' pattern, with only 'search' deviating slightly but still a verb. Snake_case and descriptive naming make the set predictable.
12 tools is reasonable for the breadth of Russian business data covered. While on the higher end, each tool serves a clear, non-redundant purpose.
The set covers major data categories for entities: registration, finance, inspections, legal cases, bankruptcies, contracts, and timeline. No obvious gaps for a read-only data provider.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Russian company lookup (EGRUL/INN), Cyrillic search, RU page to Markdown. Pay per call in USDC.
Global B2B intelligence for AI agents: 35M+ companies, 1.6M sanctions, KYB pack. 78 tools.
Web search, page reading and structured extraction for AI agents, with strong RU coverage
Agent-native API for Finnish public company data via YTJ. Pay-per-call $0.01 USDC over x402.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Nymaxxx/checko-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
