Skip to main content
Glama
atomno-mcp

mcp-fssp

by atomno-mcp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

mcp-fssp

MCP-сервер ФССП: проверка исполнительных производств по людям, компаниям и ИП — суммы, статусы, данные пристава и основание взыскания. Подключается к Cursor, Claude и любому клиенту MCP.

Russian bailiff debt lookup for AI agents.

PyPI License: MIT MCP Python 3.11+

Покрывает:

  • Физических лиц (по ФИО + дате рождения).

  • Юридических лиц (по ИНН-10 / ОГРН-13).

  • Индивидуальных предпринимателей (по ИНН-12 / ОГРНИП-15).

Часть семейства MCP-серверов atomno для due-diligence по российским контрагентам: mcp-egrul (реквизиты юр.лиц) · mcp-fns-check (налоговая благонадёжность) · mcp-cbr-rates (курсы ЦБ) · mcp-fssp (долги в ФССП).

Зачем

Официальный API ФССП (api-ip.fssp.gov.ru) отключён с 10 марта 2022 года и не планируется к восстановлению. Единственная официальная точка — публичный web-сервис fssp.gov.ru/iss/ip с CAPTCHA. Это создаёт нишу: MCP-обёртка с поддержкой нескольких коммерческих провайдеров (Damia / Checko / NewDB / api-cloud) и нормализованной моделью данных.

Главные кейсы:

  • AI-агент в Cursor / Claude Desktop делает due-diligence контрагента в чате за 30 секунд вместо 10 минут на ручной обход сайта ФССП.

  • Юристы / банки / скоринг интегрируют единый check_*_debts вызов в свои Python-скрипты или 1С, не разбирая сырые ответы 3-4 разных провайдеров.

  • Self-host энтузиасты ставят клиент локально со своим ключом Damia/Checko и работают без зависимости от стороннего SaaS — снимает паранойю об утечке ПДн.

Related MCP server: opensanctions-mcp

Quick start

1. Установить

# Через pipx (рекомендуется для CLI):
pipx install atomno-mcp-fssp

# Или через uv (быстрее):
uvx atomno-mcp-fssp

# Или классически через pip:
pip install atomno-mcp-fssp

2. Получить ключ провайдера

Минимум один из:

3. Конфиг

Создай .env в рабочей директории (или передай переменные через MCP-конфиг):

MCP_FSSP_PROVIDER=damia
MCP_FSSP_DAMIA_KEY=ваш_ключ_от_Damia

Полный список переменных — см. .env.example.

4. Подключить к Cursor

Открой ~/.cursor/mcp.json (или Settings → MCP) и добавь:

{
  "mcpServers": {
    "fssp": {
      "command": "uvx",
      "args": ["atomno-mcp-fssp"],
      "env": {
        "MCP_FSSP_PROVIDER": "damia",
        "MCP_FSSP_DAMIA_KEY": "ваш_ключ"
      }
    }
  }
}

Перезапусти Cursor. Теперь AI-агент может вызывать fssp.check_individual_debts(...), fssp.check_legal_entity_debts(...) и fssp.get_proceeding_details(...).

5. Подключить к Claude Desktop

Открой claude_desktop_config.json и добавь:

{
  "mcpServers": {
    "fssp": {
      "command": "uvx",
      "args": ["atomno-mcp-fssp"],
      "env": {
        "MCP_FSSP_PROVIDER": "damia",
        "MCP_FSSP_DAMIA_KEY": "ваш_ключ"
      }
    }
  }
}

Доступные инструменты

Инструмент

Назначение

ping

Проверка готовности сервера и текущего провайдера.

check_individual_debts(fio, birth_date, region?)

Список открытых ИП по физ.лицу.

check_legal_entity_debts(inn?, ogrn?)

Список открытых ИП по юр.лицу или ИП-предпринимателю.

get_proceeding_details(proceeding_id)

Детальная карточка одного ИП по номеру.

В Pro-версии (Phase 3+, требует ATOMNO_API_KEY):

  • summarize_debts(...) — AI-summary долгов с категоризацией и risk-score.

  • monitor_debts_changes(...) — подписка на изменения с webhook/Telegram-алёртами.

Переменные окружения

Переменная

Назначение

По умолчанию

MCP_FSSP_PROVIDER

Провайдер: damia / checko / newdb / api_cloud / self_parser / atomno_pro

damia

MCP_FSSP_DAMIA_KEY

Ключ Damia API-ФССП

—

MCP_FSSP_CHECKO_KEY

Ключ Checko v2

—

MCP_FSSP_NEWDB_KEY

Ключ NewDB

—

MCP_FSSP_API_CLOUD_KEY

Ключ api-cloud.ru

—

ATOMNO_API_KEY

Ключ Pro-режима (api.atomno-mcp.ru/fssp/)

—

ATOMNO_API_BASE

URL Pro-backend

https://api.atomno-mcp.ru/mcp-fssp/v1

MCP_FSSP_HTTP_TIMEOUT

Таймаут одного запроса в секундах

15

MCP_FSSP_RPS

Лимит запросов в минуту со стороны клиента

30

MCP_FSSP_USER_AGENT

User-Agent для запросов

mcp-fssp/0.1 (...)

MCP_FSSP_AUDIT_DB

Путь к SQLite-аудит-логу

./audit.sqlite

MCP_FSSP_LOG_LEVEL

Уровень логов: DEBUG/INFO/WARNING/ERROR

INFO

Безопасность и ПДн

  • ПДн (ФИО, дата рождения) не сохраняются в plain-text. Audit-лог хранит только sha256(fio_lower + birth_date).

  • Согласно 229-ФЗ ст. 6.1, сведения из банка данных исполнительных производств являются открытыми и доступны без согласия должника.

  • Тем не менее, при использовании в коммерческих целях оператор обязан соблюдать 152-ФЗ. Использование в законных целях (например, due-diligence перед сделкой, скоринг по согласию заёмщика) — на стороне пользователя.

Disclaimer

Сервис — агрегатор и удобный интерфейс над публичными данными ФССП (229-ФЗ ст. 6.1). Не аффилирован с ФССП России, Damia, Checko, NewDB, api-cloud и другими провайдерами. Используется на ваш риск.

Информация, возвращаемая инструментами, носит справочный характер и не заменяет официальные документы, выдаваемые ФССП. Авторы не отвечают за актуальность, полноту и точность данных провайдеров. Ответственность за законность использования сведений (в т.ч. соблюдение 152-ФЗ при обработке ПДн) — на пользователе.

При принятии юридически значимых решений (например, об отказе в кредите) необходимо запрашивать первичные документы у самого должника или через официальные каналы (запрос в подразделение приставов).

Roadmap

  • v0.1 (текущая) — Phase 0 scaffold + Damia-провайдер + check_individual_debts.

  • v0.2 — multi-provider (+Checko, NewDB, api-cloud), check_legal_entity_debts, get_proceeding_details, локальный кэш L1.

  • v0.3+ — self_parser через CAPTCHA-solver.

  • v0.5 — интеграция с Pro-backend (api.atomno-mcp.ru/fssp/): summarize_debts, monitor_debts_changes, кэш L2 на 30 дней, fallback по 3 провайдерам.

Документация по инструментам и переменным окружения — в этом README и в CHANGELOG.md. После публикации — также на GitHub: atomno-mcp/mcp-fssp.

Лицензия

MIT © 2026 atomno.

Pro-backend (atomno-mcp/mcp-fssp-server) — запланирован на Phase 2 (приватный hosted-сервис с проприетарной лицензией). Open-клиент полностью функционален без него — пользователь подставляет свой ключ любого из 4 коммерческих провайдеров.

Ссылки

Available Tools

5 tools
check_debtor_wantedA

Проверить розыск должника в банке ФССП (fssp.gov.ru/iss/wanted).

Запрос содержит ПДн — используйте только в законных целях compliance / due-diligence с согласия субъекта (152-ФЗ).

Отличается от check_individual_debts: здесь ищем именно факт постановки в розыск по исполнительным производствам, а не список открытых ИП.

ParametersJSON Schema
NameRequiredDescriptionDefault
fioYesФИО полностью на кириллице. Пример: "Иванов Иван Иванович".
birth_dateYesДата рождения в формате "YYYY-MM-DD" или "dd.mm.yyyy".

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/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 behavioral burden. It discloses that the request contains personal data and imposes a legal-consent constraint, and it implies a read-only check against an external FSSP database. However, it does not explicitly state that no data is modified, nor does it address response behavior, availability, 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 compact and front-loaded with the main purpose, followed by the legal caveat and the sibling distinction. Every sentence earns its place; there is no fluff or repetition.

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?

For a two-parameter lookup tool with an output schema, the description covers purpose, legal constraints, and the key alternative. It lacks only an explicit no-side-effects/read-only statement and minor operational details (e.g., external service behavior), but the legal notice and sibling differentiation make the definition largely complete.

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 description coverage is 100%: both fio and birth_date already have clear descriptions with formats and examples. The tool description adds no parameter-level meaning beyond the schema, so 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.

Purpose5/5

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

Description opens with a specific verb and resource: 'Проверить розыск должника в банке ФССП' and names the exact source fssp.gov.ru/iss/wanted. It then distinguishes itself from check_individual_debts, making the purpose unmistakable even without seeing the sibling schemas.

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

Usage Guidelines5/5

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

Explicitly contrasts with check_individual_debts: this tool checks the fact of being placed on the wanted list under enforcement proceedings, not the list of open proceedings. It also gives a conditional rule—use only for lawful compliance/due-diligence with 152-FZ consent—giving the agent clear selection and legal guards.

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

check_individual_debtsA

Проверить открытые исполнительные производства на физ.лицо.

Запрос содержит ПДн — используйте только в законных целях (due-diligence, скоринг по согласию субъекта) с соблюдением 152-ФЗ.

ParametersJSON Schema
NameRequiredDescriptionDefault
fioYesФИО полностью на кириллице. Пример: "Иванов Иван Иванович".
regionNoОпционально — код или название субъекта РФ для ускорения поиска.
birth_dateYesДата рождения в формате "YYYY-MM-DD" или "dd.mm.yyyy".

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. Mentions personal data handling but lacks details on behavior like pagination, timeouts, or what happens when no proceedings found. Adequate for a simple tool but could be more specific.

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?

Two sentences with no fluff; first sentence states purpose, second adds legal context. Efficient and front-loaded.

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 simple tool and existence of output schema, the description covers purpose and legal usage. Could elaborate on what 'open enforcement proceedings' means, but overall sufficient.

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 description coverage is 100%, so the description does not add new parameter meaning beyond the schema. Baseline score of 3 is appropriate.

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 states 'Check open enforcement proceedings for an individual' with a clear verb and resource. It distinguishes from sibling 'check_legal_entity_debts' by specifying individuals.

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?

Provides legal context and purpose (due diligence, scoring with consent) and compliance with Russian law. Does not explicitly state when not to use or name alternatives, but sibling differentiation is clear.

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

get_proceeding_detailsA

Получить детальную карточку конкретного ИП по его номеру.

ParametersJSON Schema
NameRequiredDescriptionDefault
proceeding_idYesНомер ИП в формате "12345/22/74033-ИП".

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.6/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 describes a read operation ('get'), implying no destructive side effects. However, it does not mention authentication requirements, rate limits, or any other behavioral traits. For a simple read tool, this is minimally adequate.

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, concise sentence that conveys the essential purpose. It is front-loaded and contains no unnecessary words.

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 low complexity (1 parameter, output schema present), the description is reasonably complete. It identifies the resource and action. The output schema likely explains the return value, so the description does not need to. Minor missing context: what exact details are included, but not critical.

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 100% description coverage, and the description reiterates that the parameter is the proceeding number. The description adds no new meaning beyond what the schema already provides (e.g., format example). Baseline 3 is appropriate.

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

Purpose4/5

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

The description clearly states the tool retrieves a detailed card ('детальную карточку') for a specific enforcement proceeding (IP) by its number. This distinguishes it from sibling tools like check_individual_debts and check_legal_entity_debts which focus on debt checking. However, 'детальную карточку' is slightly vague; a more precise term like 'full details' would improve clarity.

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 does not explicitly state when to use this tool versus alternatives. The sibling tool names imply different purposes (checking debts vs. getting details), so usage context is implicitly clear, but no explicit guidance 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
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description must fully disclose behavior. It accurately describes the tool as non-destructive diagnostics returning version and provider, which is transparent for a simple health check.

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 concise sentence that front-loads the core purpose, with no unnecessary 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, simple read-only behavior, and an existing output schema, the description is fully sufficient for an agent to understand and invoke the tool correctly.

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 parameters, so no param info is needed. The description adds value by explaining what the tool returns (version and provider), beyond the empty 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 it is a diagnostics tool that checks if the server is alive and reports version and provider, distinguishing it from the sibling tools which deal with debts and proceedings.

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 server health checks but does not explicitly state when to use it versus alternatives or provide exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.1.8
    • Addedcheck_debtor_wanted
  2. 4 tool updatesv0.1.7
    • First observedcheck_individual_debts
    • First observedcheck_legal_entity_debts
    • First observedget_proceeding_details
    • First observedping
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Scored across 5 tools

Disambiguation5/5

Each tool maps to a distinct resource and action: wanted status, individual debts, legal entity debts, proceeding details, and health check. The descriptions explicitly separate the wanted search from the open proceedings search, eliminating confusion.

Naming Consistency4/5

The naming follows a clear check_* pattern for searches and get_ for detail retrieval. The only deviation is ping, which is a standard health-check name but does not match the verb_noun convention.

Tool Count5/5

With 5 tools, the server is tightly scoped to the FSSP domain and every tool serves a clear purpose. The count feels appropriate for a focused read-only compliance server.

Completeness5/5

The core FSSP query surface is covered: individual debts, legal entity debts, wanted persons, and detailed proceeding lookup. A user can list proceedings and then fetch details by number, so the workflow has no obvious dead ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • FixPayment

    prmail
    F
    license
    Not graded
    quality
    D
    maintenance
    An MCP server for FixPayment creditors that simplifies account management, status updates, and reporting through plain-English AI interactions (https://fixpayment.org/)
    -

  • opensanctions-mcp

    scka-de
    A
    license
    A
    quality
    D
    maintenance
    MCP server for sanctions screening and PEP checks via OpenSanctions API. Search entities, match against 320+ sanctions lists, and run compound compliance investigations with AI agents.
    6
    30
    MIT

  • mcp-fns-check

    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).
    8
    15
    MIT

  • mcp-egrul

    atomno-mcp
    A
    license
    A
    quality
    A
    maintenance
    MCP server for the Russian state registries EGRUL (legal entities) and EGRIP (individual entrepreneurs), built on official Federal Tax Service open-data dumps. Self-hosted via local SQLite.
    8
    2
    MIT