What can you do with this server?

This server provides access to Russian Federal Tax Service (FNS) public registries — EGRUL (legal entities) and EGRIP (individual entrepreneurs) — allowing you to look up and retrieve company/entrepreneur data. Search & Lookup: * search_by_inn: Find a legal entity (10-digit INN) or individual entrepreneur (12-digit INN) by INN. * search_by_ogrn: Find an entity by OGRN (13 digits) or OGRNIP (15 digits). * search_by_name: Fuzzy full-text search (FTS5) across entity names, with optional result limit (1–50, default 10) and filtering by active status. Data Retrieval: * get_full_card: Retrieve a complete profile including requisites, OKVED activity codes, founders, and director — using either INN or OGRN. * get_founders: Get the list of founders with ownership shares for a legal entity (10-digit INN only). * get_director: Get the current director of a legal entity (10-digit INN only). Bulk Operations: * bulk_cards: Fetch up to 100 entity cards in a single request by INN list; returns successful cards and per-INN errors separately so one bad INN doesn't break the whole batch. Diagnostics: * ping: Check that the server is alive and retrieve its current version and local data snapshot size. Hosting & Data: * Supports self-hosting via SQLite with official FNS open-data dumps (imported manually or via daily automated updates). * When an ATOMNO_API_KEY is provided, all tools are proxied to a hosted API (api.atomno-mcp.ru) for more up-to-date data and additional Pro features.

de en ja ko ru zh

mcp-egrul

by atomno-mcp

Overview Schema Related Servers Score Discussions

Python

Hybrid

mcp-egrul

MCP server (Model Context Protocol — an open protocol for connecting AI assistants to external tools) for working with EGRUL (Unified State Register of Legal Entities of the Russian Federation) and EGRIP (Unified State Register of Individual Entrepreneurs). Source — official open-data dumps from the FTS (Federal Tax Service).

Status: v0.1.2 — open version (self-host via SQLite) is fully ready + hosted Pro client side (HTTP client HostedClient for api.atomno.ru). Published on PyPI, indexed in Glama and Smithery. The hosted Pro infrastructure itself is in active development. Coverage 100.00% (345 tests, ruff clean, fastmcp 3.2.4, enforced via --cov-fail-under=100).

Companion project: mcp-fns-check (risk-check layer over EGRUL).

What it is

Seven MCP tools visible to an AI assistant (Cursor, Claude Desktop, Cline, any MCP client):

Tool	Description	Arguments
`search_by_inn`	Search by INN (10 digits — legal entity, 12 — IE)	`inn: str`
`search_by_ogrn`	Search by OGRN (13) or OGRNIP (15)	`ogrn: str`
`search_by_name`	Fuzzy search by name (FTS5)	`query: str, limit?: int, only_active?: bool`
`get_full_card`	Full card with all sections	`inn?: str, ogrn?: str`
`get_founders`	Founders with shares only	`inn: str`
`get_director`	Current director only	`inn: str`
`bulk_cards`	Bulk check (up to 100 INNs)	`inns: list[str]`

Plus a diagnostic ping to check if the server is alive.

Full payload specification — in src/mcp_egrul/schemas.py (Pydantic models CompanyCard, IECard, SearchResult, BulkResult).

Related MCP server: onec-meta-mcp

Installation

Option 1 — via PyPI (recommended for users)

# Без локального clone — работает «из коробки»
uvx atomno-mcp-egrul

# Или установка глобально
pipx install atomno-mcp-egrul
atomno-mcp-egrul

# Или классический pip в venv
pip install atomno-mcp-egrul
atomno-mcp-egrul

Option 2 — dev-mode (for developers)

Requires Python 3.11+ and uv (fast pip replacement, optional).

git clone https://github.com/atomno-labs/mcp-egrul
cd mcp-egrul
uv venv
uv pip install -e ".[dev]"

Alternatively via pip:

python -m venv .venv
.venv/Scripts/activate    # Windows
# source .venv/bin/activate  # Linux/macOS
pip install -e ".[dev]"

Running

atomno-mcp-egrul

Default transport is stdio (standard input/output JSON-RPC). Suitable for connecting to Cursor / Claude Desktop / Claude Code.

Claude Desktop (`claude_desktop_config.json`)

{
  "mcpServers": {
    "egrul": {
      "command": "uvx",
      "args": ["atomno-mcp-egrul"]
    }
  }
}

Cursor (`.cursor/mcp.json` in the project or `~/.cursor/mcp.json` globally)

{
  "mcpServers": {
    "egrul": {
      "command": "uvx",
      "args": ["atomno-mcp-egrul"]
    }
  }
}

If you are not using uv, replace "command": "uvx", "args": ["atomno-mcp-egrul"] with "command": "atomno-mcp-egrul" (requires pip install atomno-mcp-egrul or pipx install atomno-mcp-egrul).

Docker (self-host) — quick start

# 1. Скачайте дампы ФНС (acceptance на сайте ФНС — раз в жизни).
#    Источники:
#      ЕГРЮЛ — https://www.nalog.gov.ru/opendata/7707329152-egrul/
#      ЕГРИП — https://www.nalog.gov.ru/opendata/7707329152-egrip/
#    Положите их в структуру:
mkdir -p dumps/egrul/2026-04-24 dumps/egrip/2026-04-24
cp ~/Downloads/EGRUL_*.zip dumps/egrul/2026-04-24/
cp ~/Downloads/EGRIP_*.zip dumps/egrip/2026-04-24/

# 2. Первоначальный полный импорт (однократно, ~30-60 минут):
docker compose --profile import run --rm \
    mcp-egrul-import atomno-mcp-egrul-import --registry egrul --full
docker compose --profile import run --rm \
    mcp-egrul-import atomno-mcp-egrul-import --registry egrip --full

# 3. Запустите сервер + фоновый cron-демон:
docker compose up -d
docker compose logs -f mcp-egrul-scheduler

About 10 minutes after import, all tools (search_by_inn, search_by_name, etc.) will respond with data from the local FTS snapshot.

Volume schema /data inside the container:

/data/
├── mcp_egrul_data.sqlite     # SQLite + FTS5
└── dumps/                    # read-only монтируется из ./dumps
    ├── egrul/
    │   └── YYYY-MM-DD/*.zip
    └── egrip/
        └── YYYY-MM-DD/*.zip

Cron-daemon (atomno-mcp-egrul-scheduler) automatically fetches the freshest dump after you place it in dumps/<registry>/<YYYY-MM-DD>/ — at night at 03:00 Europe/Moscow. If there is nothing new, the job will finish with nothing_to_import and will not make any unnecessary entries in import_log.

Importing FTS dumps (manual mode)

Sources:

EGRUL open-data: https://www.nalog.gov.ru/opendata/7707329152-egrul/
EGRIP open-data: https://www.nalog.gov.ru/opendata/7707329152-egrip/

Format: daily XML archives in ZIP, ~15 GB for a full snapshot. Legally, you must download them from the FTS website after accepting the license — the server does not download archives itself (strictly).

CLI:

# Полный первоначальный импорт (однократно):
atomno-mcp-egrul-import --registry egrul --full
atomno-mcp-egrul-import --registry egrip --full

# Инкремент (cron / ручной): загружается только если появилась более
# свежая YYYY-MM-DD-папка, чем последний успешный `import_log.source_dump_date`.
# Если новее нет — exit-code 5 и сообщение `nothing_to_import`.
atomno-mcp-egrul-import --registry egrul --incremental

# Фоновой cron-демон с ежедневным 03:00 MSK (вызывать вручную редко;
# обычно запускается сервисом mcp-egrul-scheduler в docker-compose).
atomno-mcp-egrul-scheduler --run-now

Exit-codes atomno-mcp-egrul-import:

Code	Meaning
0	Import successful
2	Invalid config / CLI argument
4	Ingest error (corrupt XML, missing dumps directory, DB error)
5	`nothing_to_import` — freshest date already in DB (incremental)

Pro / hosted-mode (proxy to `api.atomno.ru`)

When the user sets ATOMNO_API_KEY, all seven tools are automatically proxied to the hosted Pro API (SPEC §5.4, §5.4.1). Local SQLite is not used in this mode — hosted Pro provides:

Up-to-date data for today (without the daily delay of open-data dumps): direct scrape of egrul.nalog.ru + Dadata fallback on the server side.
Bulk-endpoint without rate-limit (POST /companies/bulk) — one request instead of N local gathers.
AI-summary of the card, change history, search by director's full name (Pro-only tools — arrive with the hosted server in Phase 2, see §5.4.1).

Price: Pro — $10/mo separately or $15/mo bundled with mcp-fns-check (bundle-key). Free tier: 30 requests/day/IP without registration (SPEC §1).

Configuration in Cursor (.cursor/mcp.json):

{
  "mcpServers": {
    "egrul": {
      "command": "uvx",
      "args": ["atomno-mcp-egrul"],
      "env": {
        "ATOMNO_API_KEY": "your-pro-key-here"
      }
    }
  }
}

Behavior and errors — no silent fallback: if the hosted API is unavailable, the client raises a typed exception instead of silently returning data from an outdated local dump. Mapping HTTP ↔ MCP error code — in SPEC §5.4.1:

HTTP-response hosted API	Client exception	`error.code`
200	—	—
400	`ValidationError`	`invalid_input`
401	`HostedAuthError`	`auth_required`
403	`ProRequiredError`	`pro_required`
404 (code=not_found)	`NotFoundError`	`not_found`
404 (wrong route)	`SourceUnavailableError`	`source_unavailable`
413	`BulkTooLargeError`	`bulk_too_large`
429	`RateLimitedError` (+ `Retry-After`)	`rate_limit`
5xx	`SourceUnavailableError`	`source_unavailable`
timeout / DNS fail	`SourceUnavailableError` (cause=`timeout`/`ConnectError`)	`source_unavailable`

INN/OGRN validation remains client-side (check digits are verified before the HTTP request — saving round-trip on invalid identifiers).

Configuration (environment variables)

Variable	Description	Default
`MCP_EGRUL_DB`	Path to SQLite file with EGRUL/EGRIP snapshot	`./mcp_egrul_data.sqlite`
`MCP_EGRUL_USER_AGENT`	HTTP client User-Agent	`mcp-egrul/0.1 (+https://github.com/atomno-labs/mcp-egrul)`
`MCP_EGRUL_HTTP_TIMEOUT`	HTTP timeout in seconds	`30`
`MCP_EGRUL_DUMPS_DIR`	Directory with FTS dumps, structure `<dir>/<registry>/<YYYY-MM-DD>/*.zip`	`./dumps`
`MCP_EGRUL_LOG_LEVEL`	Logging level	`INFO`
`TZ`	Timezone for scheduler (cron 03:00)	`Europe/Moscow`
`ATOMNO_API_KEY`	(Pro) hosted-subscription key — enables proxying to `api.atomno.ru`	not set
`ATOMNO_API_BASE`	(Pro) hosted-API base URL	`https://api.atomno.ru/mcp-egrul/v1`

Example — see .env.example.

Structure

apps/mcp-egrul/
├── pyproject.toml
├── LICENSE                             # MIT
├── README.md                           # ЭТОТ ФАЙЛ
├── Dockerfile
├── docker-compose.yml
├── .env.example
├── .gitignore
├── src/mcp_egrul/
│   ├── __init__.py
│   ├── server.py                       # FastMCP entrypoint, регистрация 7 тулзов + ping
│   ├── context.py                      # ServiceContext (DI: SQLiteStore + HTTP-клиент)
│   ├── config.py                       # Чтение env-vars в типизированные поля
│   ├── constants.py                    # Все магические числа и enum'ы
│   ├── validators.py                   # Контрольные цифры ИНН (10/12) и ОГРН (13/15)
│   ├── schemas.py                      # Pydantic-модели CompanyCard/IECard/SearchResult/...
│   ├── errors.py                       # McpEgrulError и подклассы
│   ├── db/
│   │   ├── __init__.py
│   │   └── sqlite.py                   # Async-клиент (aiosqlite), init/query/upsert/search + import_log
│   ├── sources/
│   │   ├── __init__.py
│   │   ├── base.py                     # Абстрактный интерфейс Source
│   │   ├── opendata.py                 # ФНС open-data адаптер (read-local → SQLite upsert)
│   │   ├── opendata_parser.py          # Потоковый lxml.iterparse парсер ЕГРЮЛ/ЕГРИП XML
│   │   └── hosted_adapter.py           # HTTP-клиент hosted Pro API (SPEC §5.4.1)
│   ├── tools/
│   │   ├── __init__.py
│   │   ├── search_by_inn.py
│   │   ├── search_by_ogrn.py
│   │   ├── search_by_name.py
│   │   ├── get_full_card.py
│   │   ├── get_founders.py
│   │   ├── get_director.py
│   │   └── bulk_cards.py
│   └── scripts/
│       ├── __init__.py
│       ├── import_opendata.py          # CLI `atomno-mcp-egrul-import` (ручной / одноразовый)
│       └── scheduler.py                # CLI `atomno-mcp-egrul-scheduler` (apscheduler cron 03:00 MSK)
└── tests/
    ├── __init__.py
    ├── conftest.py
    ├── fixtures/
    │   ├── egrul_sample.xml            # Мини-ЕГРЮЛ (2 валидных + 1 skip на неизвестный статус)
    │   └── egrip_sample.xml            # Мини-ЕГРИП (active + closed)
    ├── test_validators.py
    ├── test_schemas.py
    ├── test_config.py                  # Config.from_env + _parse_float_env (валидация env)
    ├── test_sqlite_store.py
    ├── test_cards.py                   # _cards.py: parse_iso_date/datetime + build_*card
    ├── test_server_ping.py             # FastMCP tool-layer + server.main()
    ├── test_tools.py                   # 7 тулзов: happy-path + validation + not_found
    ├── test_opendata_parser.py         # XML-парсер (zip, xml, skip-на-неизвестный-статус)
    ├── test_opendata_source.py         # OpenDataSource.run_ingest (full/incremental)
    ├── test_integration_import.py      # Полный цикл import → search → get_card
    ├── test_import_cli.py              # CLI `atomno-mcp-egrul-import`
    ├── test_scheduler_cli.py           # CLI `atomno-mcp-egrul-scheduler` + _run_scheduler
    └── test_hosted_adapter.py          # HostedClient + маршрутизация тулзов (respx-моки)

Tests

pytest -v --cov=src/mcp_egrul

Current coverage: 100.00% (345 tests passed, ruff clean, 1529 statements + 382 branches, 0 misses). Enforced by --cov-fail-under=100 policy — any regression will break CI. Tests cover:

INN/OGRN/OGRNIP validators (check digits);
Config.from_env + float-env-variable parser (validation, not silent fallback);
all 7 MCP tools (happy-path + validation + not_found + bulk partial);
SQLite store + FTS5 + import_log;
XML-parser for EGRUL/EGRIP (zip, xml, skip-record with unknown status);
OpenDataSource.run_ingest (full/incremental/nothing_to_import);
full integration cycle import fixture → search → get_card → bulk;
both CLIs (atomno-mcp-egrul-import, atomno-mcp-egrul-scheduler) — cron-job registration, argument parsing, _run_daily_ingest on all-happy/nothing_to_import/McpEgrulError, full cycle _run_scheduler with mock-ed asyncio.Event;
FastMCP tool-layer via mcp.call_tool() — error serialization into structured dicts, server.main() with valid and invalid env;
HostedClient (hosted Pro API proxy) — happy-path of all 7 methods, all HTTP errors from SPEC §5.4.1 (401/403/404/413/429/5xx), timeout/ConnectError, invalid JSON/payload from server, client-side bulk validation, async with-context; plus routing from tools in hosted-mode (when ATOMNO_API_KEY is set — request goes to api.atomno.ru, not SQLite, INN validation before HTTP);
edge-cases of XML-parser (75 separate unit-tests on _parse_company/_parse_ie/_parse_share/_parse_director/_parse_founders/address fallbacks/legacy-attributes/invalid INN/OGRN/KPP lengths);
private SQLite-store helpers (_wrap, _prepare_row, _row_to_dict, _normalize_bm25, auto-init via _ensure, rejecting invalid finish_import statuses);
ServiceContext reentry-idempotency, atexit-cleanup, Config.from_env ValidationError → exit-code 2 from atomno-mcp-egrul-import CLI.

External APIs are never called directly from tests — only via respx (HTTP-mocking) and local XML-fixtures (tests/fixtures/).

Security and legal status

All sources are publicly open FTS data (EGRUL / EGRIP open-datasets), the distribution of which is permitted by the Federal Law "On Information..." and EGRUL-specific norms (see SPEC §8).
Legal entities do not fall under 152-FZ (On Personal Data).
Full names of individual directors and founders are published by the FTS itself in the open registry — forwarding this data is legal.
No write-operations to any external API.
Secrets — only via environment variables, in the repository — .env.example without values.

Disclaimer

The service is an aggregator and a convenient interface over public FTS data. Not affiliated with the FTS. Use at your own risk. Information in the service's responses is not a substitute for a full legal or financial assessment.

License

MIT. LICENSE file in the root folder.

Available Tools

8 tools

bulk_cardsA

Массовая выгрузка до 100 карточек за один вызов.

Вернёт объект с полями cards (успешные) и errors (точечные ошибки по отдельным ИНН) — один плохой ИНН не ломает весь bulk.

ParametersJSON Schema

Name	Required	Description	Default
`inns`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses important behavioral aspects like returning both successful cards and per-TIN errors, and that one bad TIN doesn't break the whole call. However, it omits whether the operation is read-only or has side effects, and no mention of authorization or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no fluff. The first sentence front-loads the core purpose and capacity, and the second explains the return structure and error handling. Every word contributes value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple input schema (one parameter) and the existence of an output schema (not provided but implied), the description sufficiently covers maximum batch size, return format (cards/errors), and partial failure behavior. It is complete for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema has no description for the 'inns' parameter, the description mentions 'отдельным ИНН' (individual TINs), clarifying that the array contains Russian tax identifiers. With 0% schema coverage, the description adds meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs a massive upload of up to 100 cards per call, specifying the action (выгрузка) and resource (карточек). It distinguishes itself from siblings like search_by_inn by handling multiple INNs and returning partial errors.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates usage for batch card retrieval with a capacity limit of 100, but does not explicitly state when not to use it or list alternatives. However, the context of sibling tools and the capacity hint provide implicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_directorB

Текущий руководитель юр.лица по ИНН (только 10-значный ИНН).

ParametersJSON Schema

Name	Required	Description	Default
`inn`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It only states it returns the current director, but fails to mention aspects like error handling, data freshness, auth requirements, or side effects. This is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, very concise and front-loaded with the key action and constraint. Every word earns its place, though it could be slightly expanded for additional clarity without losing brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple single-parameter tool and the existence of an output schema, the description is minimally adequate but lacks details on edge cases or error responses. It covers the basic purpose but not the full context of usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage. The tool description adds value by specifying that the INN must be exactly 10 digits. However, it doesn't fully compensate for missing schema descriptions, e.g., no mention of format beyond digit count.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the current director of a legal entity by INN. It specifies the exact resource (director), action (get), and constraint (10-digit INN for legal entities). This distinguishes it from siblings like get_founders or search_by_inn.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus alternatives such as get_founders or search_by_inn. It only describes what it does without contextual or comparative usage advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_foundersB

Учредители юр.лица по ИНН (только 10-значный ИНН).

ParametersJSON Schema

Name	Required	Description	Default
`inn`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It only mentions the TIN length constraint but does not disclose whether this is a read-only operation, error handling, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that conveys the core purpose and a key constraint without any unnecessary words. It is efficiently structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (not shown), the description does not need to detail return values. However, it lacks information on error handling, input validation details, or the structure of the founders data, which could be incomplete for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, leaving the 'inn' property undocumented. The description adds the crucial constraint that only a 10-digit TIN is accepted, which is valuable beyond the schema definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves founders of a legal entity by TIN and specifies the requirement of a 10-digit TIN. This distinguishes it from siblings like get_director which targets a different role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool over alternatives like search_by_inn or get_director. It does not state prerequisites or exclusions, leaving the agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_full_cardA

Полная карточка (все секции: реквизиты, ОКВЭД, учредители, директор).

Хотя бы один из inn / ogrn обязателен. Если переданы оба — используется inn.

ParametersJSON Schema

Name	Required	Description	Default
`inn`	No
`ogrn`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

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 at least one of inn/ogrn is required and inn takes precedence, but does not mention read-only nature, authentication needs, or error handling for missing parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences and front-loads the purpose. It is concise with no unnecessary words, though structure could be improved with bullet points for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and only two parameters, the description covers the primary requirements: purpose and parameter constraints. It lacks mention of error cases or usage limitations, but is largely complete for a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the description adds meaning by clarifying that inn and ogrn are alternative identifiers, at least one is mandatory, and inn is used if both are provided. This significantly compensates for the schema's lack of parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Full card (all sections: details, OKVED, founders, director)', clearly indicating it retrieves a complete company card. This distinguishes it from sibling tools like get_director and get_founders, which target specific sections.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving full card data, but does not explicitly contrast with siblings or state when to use this tool over alternatives like search_by_inn or get_director. No exclusion criteria or context is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pingA

Диагностика: сервер жив, сообщает версию и размер локального слепка.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description takes full burden. It discloses that the tool reports version and snapshot size, which is useful. However, it does not mention read-only nature, safety, or potential side effects, though for a ping tool these are minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that front-loads the main purpose ('Диагностика') and immediately specifies what the tool reports. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters, an output schema exists (not shown but referenced), and a set of sibling tools, the description is complete for this simple tool: it tells the agent exactly what the tool returns and its role as a health check.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so the description need not add parameter info. Baseline for zero parameters is 4, and the description appropriately focuses on the tool's output rather than parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool is for diagnostics: checking server liveness, version, and snapshot size. It uses a specific verb ('диагностика') and resource ('сервер'), and is distinct from sibling tools that handle cards, directors, or searches.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for health checks but does not explicitly state when to use this tool vs alternatives, nor does it mention exclusions or prerequisites. Given the clear purpose, usage is implied but not guided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_by_innA

Карточка юр.лица или ИП по ИНН (10 цифр — ООО/АО, 12 — ИП/физлицо).

ParametersJSON Schema

Name	Required	Description	Default
`inn`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must cover behavioral traits. It only states the searchby TIN and format, omitting any details on error handling, rate limits, or return behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (one short phrase) and front-loaded with the core purpose, containing no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple lookup tool with an output schema, the description is minimally complete but lacks details on error cases and what the card contains, leaving some gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameter descriptions (0% coverage), but the description adds critical semantic meaning by explaining the TIN length and entity mapping, significantly aiding correct usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns a card of a legal entity or individual entrepreneur by TIN, and distinguishes it from siblings by specifying TIN format (10/12 digits) and entity types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for TIN-based lookup, distinct from siblings like search_by_name or search_by_ogrn, but provides no explicit when-to-use or when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_by_nameB

Fuzzy-поиск юр.лиц по названию через FTS5.

ParametersJSON Schema

Name	Required	Description
`limit`	No	максимум результатов (1..50).
`query`	Yes	строка запроса (минимум 2 символа).
`only_active`	No	фильтровать только записи со статусом 'active'.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions fuzzy search via FTS5 but omits details like matching behavior, result ordering, or handling of misspellings.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is a single sentence, concise but lacking structure. It could benefit from additional context without being lengthy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and only input schema provided, the description omits important behavioral traits and result format expectations. Even with an output schema, more context would be helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for all parameters. The description adds no new meaning beyond 'fuzzy', so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it is a fuzzy search of legal entities by name using FTS5, which is specific and distinguishes from siblings like search_by_inn and search_by_ogrn.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. It implicitly targets name-based searches, but without stating exclusions or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_by_ogrnB

Карточка по ОГРН (13 цифр) или ОГРНИП (15 цифр).

ParametersJSON Schema

Name	Required	Description	Default
`ogrn`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must fully disclose behavior. It only states what the tool does (retrieve a card) but omits details about error handling, side effects, or what happens for invalid inputs. This is insufficient for an agent to fully anticipate behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is highly concise and front-loaded. However, it could be structured with separate sentences for clarity, but for a simple tool it is appropriately sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema (not shown), the description may not need to detail return values. It provides the parameter format but lacks any mention of error handling or usage context. For a simple lookup tool, it is minimally adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must compensate. It adds meaningful format constraints: 13 digits for OGRN and 15 digits for OGRNIP, which is valuable beyond the plain string type in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool retrieves a card by OGRN (13 digits) or OGRNIP (15 digits), making the purpose and resource specific. It distinguishes itself from sibling tools like search_by_inn and search_by_name by indicating the identifier type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers no explicit guidance on when to use this tool versus alternatives or when not to use it. The context is only implied by the tool name and description, with no mention of prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct query type: bulk export, specific fields (director, founders), full card, health check, and three search methods (INN, name, OGRN). No overlapping purposes.

Naming Consistency4/5

Most tools use a verb_noun pattern (get_director, get_founders, search_by_inn, etc.). Ping and bulk_cards are minor deviations but still clear.

Tool Count5/5

Eight tools cover a complete set of operations for a business registry: multiple search methods, specific field lookups, bulk export, and health check. No extraneous tools.

Completeness4/5

Covers essential read operations for a registry: search by various identifiers, retrieval of full cards and specific fields, bulk export. Missing filtering or advanced search (e.g., by region) but acceptable for a focused server.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

ahel
io.ahel
Hosted MCP server for real-world data: business registries, sanctions, companies, domains, crypto.
Government Data Cryptocurrency Open Data
2
Nursing Home Database A
com.nursinghomedatabase
MCP server for US nursing facility search and ownership lookup (NursingHomeDatabase).
Government Data Health & Wellness Search
62
RU Books MCP
io.github.books-service
MCP server for Russian books search, details, and recommendation candidates.
Search Art & Culture Entertainment & Media
2
nonprofit-explorer-mcp-server A
io.github.cyanheads
MCP server for nonprofit financials via ProPublica — IRS Form 990 data for 1.8M+ nonprofits.
Finance Government Data Open Data
322

Related MCP Servers

mcp-fns-check
Government Data Legal & Compliance Open Data
atomno-mcp
A
license
A
quality
B
maintenance
MCP server for verifying Russian counterparties (legal entities and individual entrepreneurs) via public Federal Tax Service data: EGRUL/EGRIP, bankruptcy registry (EFRSB), Transparent Business, bailiff service (FSSP), and arbitration courts (KAD).
Updated 2 months ago (2026-07-14 19:07 UTC)
8
15
MIT
onec-meta-mcp
Code Analysis Databases Developer Tools
gsbelarus
F
license
Not graded
quality
B
maintenance
MCP server for searching and analyzing 1C enterprise metadata and BSL code using a SQLite backend. Enables querying configuration structure, code routines, and performing compliance checks via natural language.
Updated 16 days ago (2026-08-19 18:28 UTC)
mcp-sudact
Legal & Compliance Government Data
atomno-mcp
A
license
A
quality
A
maintenance
MCP server for Russian court practice (Sudact): full-text case search by law article, court, instance and dates, with access to full decision texts.
Updated 2 months ago (2026-07-14 19:08 UTC)
2
2
MIT
mcp-fssp
Government Data Legal & Compliance
atomno-mcp
A
license
A
quality
A
maintenance
MCP server for checking Russian FSSP (Federal Bailiff Service) debts, enabling AI agents to look up enforcement proceedings for individuals and legal entities through MCP clients like Cursor and Claude Desktop.
Updated 2 months ago (2026-07-14 19:07 UTC)
4
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/atomno-mcp/mcp-egrul'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

mcp-egrul

What it is

Installation

Option 1 — via PyPI (recommended for users)

Option 2 — dev-mode (for developers)

Running

Claude Desktop (claude_desktop_config.json)

Cursor (.cursor/mcp.json in the project or ~/.cursor/mcp.json globally)

Docker (self-host) — quick start

Importing FTS dumps (manual mode)

Pro / hosted-mode (proxy to api.atomno.ru)

Configuration (environment variables)

Structure

Tests

Security and legal status

Disclaimer

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Claude Desktop (`claude_desktop_config.json`)

Cursor (`.cursor/mcp.json` in the project or `~/.cursor/mcp.json` globally)

Pro / hosted-mode (proxy to `api.atomno.ru`)