Skip to main content
Glama

mcp-fssp

PyPI License: MIT MCP Python 3.11+

Russian FSSP (Federal Bailiff Service) debt lookups via MCP — check enforcement proceedings (исполнительные производства) for individuals and legal entities directly from Cursor, Claude Desktop, Cline, Goose, and any MCP client.

MCP-сервер для проверки задолженностей в ФССП (Федеральная служба судебных приставов). Позволяет AI-агентам в Cursor / Claude Desktop / Cline / Goose / Kiro делать запросы в базу долгов ФССП и получать структурированный JSON с открытыми исполнительными производствами (ИП): суммы, статусы, реквизиты приставов, основания взыскания.

Покрывает:

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

  • Юридических лиц (по ИНН-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

4 tools
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.

TDQS

A3.9/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: individual vs legal entity debt checks, detail retrieval by proceeding number, and a diagnostic ping. No overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., check_individual_debts), with 'ping' as a standard diagnostic, maintaining uniformity.

Tool Count5/5

With 4 tools, the server is well-scoped for its domain—covering main debt checks and details—without being too sparse or overloaded.

Completeness4/5

Core operations for checking debts (individual and legal entity) and retrieving details are present. Missing search by other criteria, but no significant dead ends.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Related MCP Connectors

Related MCP Servers

  • 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/)
  • 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
    57
    MIT
  • 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
  • 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

Latest Blog Posts

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-fssp'

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