Look up Russian companies by INN (tax ID) directly from Claude Desktop, Cursor and any MCP-compatible client. A thin wrapper over the public KontragentPro API v2, serving data from Russian open registries: EGRUL (company registry), Federal Tax Service financial statements, bankruptcy register, state inspections, trademarks, sanctions and foreign-agent lists.
Works without an API key — anonymous free tier is enabled by default, so you can try it in under a minute.
Русское описание — ниже.
Tool | What it does |
| Filter legal entities by annual income (FNS open data), region, industry code, headcount, bankruptcy status |
| Full company card by INN in a single call |
| Multi-year financial history from official tax filings |
| Event feed: bankruptcies, inspections, trademarks, official gazette |
| Balance, plan and daily quota (requires API key) |
Related MCP server: checko-mcp
Run without installing, via uv:
uvx kontragentpro-mcpOr with pip:
pip install kontragentpro-mcp
kontragentpro-mcpOpen Settings → Developer → Edit Config and add to mcpServers:
{
"mcpServers": {
"kontragentpro": {
"command": "uvx",
"args": ["kontragentpro-mcp"]
}
}
}Restart Claude Desktop — the tools will appear in the list. To raise rate limits,
add "env": {"KONTRAGENTPRO_API_KEY": "your_key"}.
Settings → MCP → Add new server, type command:
{
"command": "uvx",
"args": ["kontragentpro-mcp"]
}"Check the company with INN 7736207543 and show its revenue over the last 5 years"
The client calls get_company and get_company_financials, returning the company
card and the financial series.
Variable | Default | Purpose |
| — | Bearer key from your account (optional) |
|
| API base URL |
|
| HTTP timeout, seconds |
Get a free key at https://kontragentpro.ru/developers.
All data comes from official Russian open registries — EGRUL/EGRIP, the Federal Tax Service (financial statements, tax regimes), the federal bankruptcy register, the Prosecutor General's inspection registry, Rospatent trademarks, and public sanctions lists. Each block on a company card carries its source and retrieval date.
Проверка российских контрагентов по ИНН прямо в Claude Desktop, Cursor и любом MCP-совместимом клиенте. Тонкая обёртка над публичным API KontragentPro v2 — данные из открытых реестров: ЕГРЮЛ, ФНС (ГИР БО и открытые данные), ЕФРСБ (банкротства), Генпрокуратура (проверки), Роспатент, реестры санкций и иноагентов.
Ключ необязателен: без него сервер работает в анонимном free-tier
с пониженным лимитом запросов — попробовать можно сразу. Ключ для повышенных
лимитов и check_account выдаётся в личном кабинете:
https://kontragentpro.ru/developers
Инструмент | Что делает |
| Подбор списка ЮЛ по фильтрам: годовой доход (открытые данные ФНС), регион, ОКВЭД, штат, статус банкротства |
| Сводная карточка компании одним запросом по ИНН |
| Многолетняя динамика из ГИР БО ФНС; при её отсутствии — годовой снимок открытых данных ФНС |
| Лента событий: банкротства, проверки, иноагенты, ТЗ, Вестник |
| Баланс депозита, план, дневная квота (нужен ключ) |
uvx kontragentpro-mcp # запуск без установки
pip install kontragentpro-mcp # либо через pip«Проверь контрагента с ИНН 7736207543 и покажи динамику выручки за 5 лет»
Клиент вызовет get_company и get_company_financials, вернёт карточку
и финансовый ряд.
MIT. Данные предоставляются «как есть» из открытых источников; сервис не является заменой официальной выписки.
MIT. Data is provided as-is from public sources and is not a substitute for an official registry extract.
Состояние API-счёта по текущему ключу: баланс депозита, тарифный план, дневная квота и её использование, список ключей. Требует KONTRAGENTPRO_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral disclosure burden. It does add useful context by stating the KONTRAGENTPRO_API_KEY requirement and listing the returned account details. However, it does not explicitly state that this is a read-only operation, nor does it mention error behavior or what happens if the key is invalid.
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 dense sentence that front-loads the tool's purpose and immediately follows with the required environment variable. Every clause contributes useful information, and there is no filler or redundant restatement of the tool name.
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 no-input account status tool, the description covers the purpose, the returned data categories, and the authentication requirement. It does not describe the response format or error conditions, but given the low complexity and absence of an output schema, the remaining gaps are minor.
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 naturally 100%, so there is no parameter ambiguity to compensate for. The baseline for a zero-parameter tool is 4, and the description adds the necessary authentication 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 clearly identifies the resource (API account tied to the current key) and enumerates the exact information returned: deposit balance, tariff plan, daily quota usage, and key list. This is specific enough to distinguish it from the sibling company lookup 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 intended use is implied by the account-specific content and the authentication requirement, but the description does not explicitly say when to use this tool versus alternatives or mention any exclusions. It also does not name any sibling tool for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Сводная карточка компании одним запросом по ИНН: идентичность (название, ОГРН, адрес), финансы, налоговый режим, риск-флаги (банкротство, санкции, иноагент), товарные знаки и связи. Поле completeness показывает, какие блоки заполнены. Всегда 200 для валидного ИНН.
| Name | Required | Description | Default |
|---|---|---|---|
| inn | Yes | ИНН юрлица — 10 цифр. |
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 that the response always returns HTTP 200 for a valid INN, and that a 'completeness' field indicates which blocks are filled. This is useful context. However, it does not mention error behavior for invalid INN, authentication requirements, rate limits, or the response structure beyond the block list. Some transparency is present but not exhaustive.
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, dense sentence that front-loads the core purpose ('summary card by INN') and then lists the included blocks. It is efficient with no redundant filler, though slightly long due to the enumerated content. It earns a 4 for clarity and compactness.
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 complex, returning multiple data sections, and there is no output schema. The description lists the main blocks and mentions the 'completeness' field and status code behavior, which helps an agent anticipate the response. However, it lacks details on error cases (e.g., invalid INN) and a more explicit structure of each block. For the complexity, it is fairly complete but not exhaustive.
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 full description for the only parameter 'inn' ('ИНН юрлица — 10 цифр.'). The tool description adds no new meaning about the parameter; it only restates that it queries by INN. With 100% schema coverage, the baseline is 3, and the description does not elevate 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 clearly states the tool's purpose: it returns a comprehensive company summary card in one request by INN. It lists the content blocks (identity, finances, tax regime, risk flags, trademarks, connections) and implicitly differentiates from siblings like get_company_financials (only financials) or search_companies (search). The verb 'get' and resource 'company card' are specific.
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 it is a one-stop-shop for full company data ('summary card in one request'), which suggests using it when a complete overview is needed. However, it does not explicitly state when to use alternatives, nor does it mention any exclusions. It doesn't reference sibling tools at all, so an agent might not know that for financials alone it could use get_company_financials. Guidance is implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Многолетняя финансовая динамика компании по ИНН (выручка, прибыль, активы, коэффициенты) из ГИР БО ФНС плюс годовой снимок. Для новых компаний многолетний ряд может быть пуст — тогда возвращается годовой снимок и предупреждение (warnings).
| Name | Required | Description | Default |
|---|---|---|---|
| inn | Yes | ИНН юрлица — 10 цифр. | |
| year_to | No | Верхняя граница года (включительно). | |
| year_from | No | Нижняя граница года (включительно). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does a good job: it discloses the data source, the output composition (multi-year series plus annual snapshot), and an important edge case where newer companies may return an empty series with a warning. This goes beyond what the tool name alone suggests.
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 with no filler. The core purpose is front-loaded, and the important fallback behavior is provided as a concise second sentence.
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 read-oriented tool with fully documented parameters and no output schema, the description gives enough return-semantics context: multi-year financials, annual snapshot, and warning behavior. It does not describe exact response fields, but the essential calling context is present.
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 schema already documents all three parameters. The description adds no additional meaning about the parameters themselves, but it does not need to compensate for missing schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving multi-year financial dynamics and an annual snapshot by INN from a specific source (ГИР БО ФНС), listing covered fields (revenue, profit, assets, ratios). It is specific but does not explicitly differentiate from siblings like get_company or get_company_timeline.
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 usage context is only implied: an agent can infer it should be used when financial dynamics for a company are needed. There is no explicit when-to-use guidance, no exclusions, and no mention of alternative tools such as get_company_timeline.
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 | ИНН юрлица — 10 цифр. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does add useful behavioral information: the events are sorted from newest to oldest and includes specific event sources. But it does not mention pagination, output shape, limits, or any access considerations, leaving moderate gaps.
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 with no wasted words. The first sentence front-loads the purpose and enumerates event types; the second adds sorting behavior. Every sentence contributes useful 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?
The tool is simple (single parameter) but has no output schema and no annotations. The description explains what events are included and the sorting order, yet it does not specify the structure of the returned events, pagination, or how dates are represented, so the description is adequate but not 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 description coverage is 100% and the only parameter, inn, is already described as a 10-digit legal entity INN. The tool description adds no further parameter-level meaning, so the schema carries the full load; the baseline score of 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 clearly identifies a specific verb and resource: retrieving a company's event timeline. It enumerates the exact event categories included (bankruptcy, foreign-agent registry, inspections, publication in state register, trademarks), which distinguishes it from sibling tools like get_company or get_company_financials.
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 when to use the tool: any time a date-ordered timeline of corporate events is needed. However, it does not explicitly mention sibling alternatives, when not to use the tool, or how it should be selected over get_company or get_company_financials.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Подобрать список российских юрлиц по фильтрам (доходы, регион, ОКВЭД, штат, статус банкротства). Возвращает items[] с ИНН, названием, финансовыми показателями и флагами риска. Для деталей по одному ИНН зовите get_company.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Сколько компаний вернуть (1–500). | |
| okved | No | CSV префиксов ОКВЭД (напр. '47.1,47.2'). | |
| offset | No | Смещение для пагинации. | |
| status | No | Фильтр по статусу: 'active' (действующие, по умолчанию) или 'bankrupt' (в процедуре банкротства). | |
| order_by | No | Сортировка: revenue_desc | revenue_asc | random | recent_bankruptcy. | revenue_desc |
| region_code | No | CSV кодов субъектов РФ (напр. '77,78') — для active. | |
| revenue_max | No | Максимальный годовой доход в рублях (открытые данные ФНС). | |
| revenue_min | No | Минимальный годовой ДОХОД в рублях (открытые данные ФНС). Это совокупные доходы — выручка плюс прочие, — а не строка 2110 бухотчётности; они больше выручки из ГИР БО. | |
| revenue_year | No | Год годового снимка ФНС для фильтра по доходам. | |
| employees_min | 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 does disclose the return shape ('items[] с ИНН, названием, финансовыми показателями и флагами риска') and scope (Russian legal entities), but it does not mention pagination behavior, default status filtering, or any other side effects; those are left to the inline schema or agent inference.
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: the first fronts the purpose with filter types, the second summarizes the return format and points to the complementary tool. There is zero wasted wording, and the most important routing information is placed at the end of the second sentence.
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 10 optional parameters, no annotations, and no output schema, the description provides the core purpose, output shape, and a pointer to the sibling for detail retrieval. The 100% parameter schema coverage fills in the parameter semantics, so the main missing piece is a bit more detail on the returned fields or constraints like default status, making it nearly complete but not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, and the description only summarizes existing filters (revenue, region, OKVED, headcount, bankruptcy status) without adding new semantic meaning. The parameter descriptions themselves already cover semantics like revenue_min being total income rather than just revenue, and region_code being for active status only.
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 explicitly states a specific verb and resource: 'Подобрать список российских юрлиц по фильтрам' (select a list of Russian legal entities by filters), and lists concrete filter dimensions. It also differentiates itself from the sibling get_company by directing single-INN detail requests there, so an agent can distinguish the tools without inspecting schemas.
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 an explicit alternative: 'Для деталей по одному ИНН зовите get_company' (for details on a single INN, call get_company), which clearly indicates when not to use this tool. It does not mention other siblings like get_company_financials, but the list-vs-detail distinction is enough for most use cases.
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.
v0.3.0check_accountget_companyget_company_financialsget_company_timelinesearch_companiesScored across 5 tools
Every tool targets a distinct purpose: searching, retrieving a company summary, detailed financials, event timeline, or checking account status. Overlap between get_company and get_company_financials is minimal and clearly separated by summary vs. multi-year dynamics.
All tools follow a consistent verb_noun snake_case pattern: search_companies, check_account, get_company, get_company_financials, get_company_timeline. The shared get_company_ prefix for company-specific detail views makes the API predictable.
Five tools is well-scoped for a business intelligence API: search, general company card, financials, event timeline, and account management. No tool is redundant or missing at this abstraction level.
The toolset covers the core lifecycle of company investigation: finding candidates via search, retrieving a full company card, diving into financial history, exploring event timelines, and managing API access. No obvious dead ends or required missing operations.
Russian company lookup (EGRUL/INN), Cyrillic search, RU page to Markdown. Pay per call in USDC.
RU INN/OGRN, banks, geo, WHOIS. Agent self-registers via register_agent. 20 free/day.
CompanyLens is a remote MCP server giving AI agents instant access to official company registry data across 19 jurisdictions in Europe, the Americas, and Asia-Pacific. Eighteen read-only tools let you search companies and people, look up officers and beneficial owners, map corporate networks through shared directors, screen names against the UK disqualified directors register, find every company at a registered address, and pull filing history — all from a single connector. Visit our website: https://companylens.io
European business verification for AI agents: registry, VAT, sanctions, IBAN. Pay-per-call x402.
