mcp-fssp
Enables sending debt monitoring alerts to Telegram via webhook integration.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@mcp-fsspcheck debts for Ivan Ivanov"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
mcp-fssp
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-fssp2. Получить ключ провайдера
Минимум один из:
Damia (https://api-fssp.damia.ru) — основной кандидат для prod. От 7 000 ₽/год за 1 000 запросов; 100 запросов бесплатно на тест.
Checko (https://api.checko.ru) — до 50 запросов/день бесплатно. Хорош для onboarding.
NewDB (https://newdb.net/fssp/api) — бюджетная альтернатива, 2 ₽/запрос, 100 free.
api-cloud (https://api-cloud.ru/api/fssp.php) — per-request оплата.
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": "ваш_ключ"
}
}
}
}Доступные инструменты
Инструмент | Назначение |
| Проверка готовности сервера и текущего провайдера. |
| Список открытых ИП по физ.лицу. |
| Список открытых ИП по юр.лицу или ИП-предпринимателю. |
| Детальная карточка одного ИП по номеру. |
В Pro-версии (Phase 3+, требует ATOMNO_API_KEY):
summarize_debts(...)— AI-summary долгов с категоризацией и risk-score.monitor_debts_changes(...)— подписка на изменения с webhook/Telegram-алёртами.
Переменные окружения
Переменная | Назначение | По умолчанию |
| Провайдер: |
|
| Ключ Damia API-ФССП | — |
| Ключ Checko v2 | — |
| Ключ NewDB | — |
| Ключ api-cloud.ru | — |
| Ключ Pro-режима (api.atomno-mcp.ru/fssp/) | — |
| URL Pro-backend |
|
| Таймаут одного запроса в секундах |
|
| Лимит запросов в минуту со стороны клиента |
|
| User-Agent для запросов |
|
| Путь к SQLite-аудит-логу |
|
| Уровень логов: |
|
Безопасность и ПДн
ПДн (ФИО, дата рождения) не сохраняются в 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 коммерческих провайдеров.
Ссылки
Спецификация ФССП API (исторически): api-ip.fssp.gov.ru (отключён с 10.03.2022).
Web-сервис ФССП: fssp.gov.ru/iss/ip.
Каталог MCP: glama.ai/mcp/servers.
MCP-спецификация: modelcontextprotocol.io.
Available Tools
4 toolscheck_individual_debtsA
Проверить открытые исполнительные производства на физ.лицо.
Запрос содержит ПДн — используйте только в законных целях (due-diligence, скоринг по согласию субъекта) с соблюдением 152-ФЗ.
| Name | Required | Description | Default |
|---|---|---|---|
| fio | Yes | ФИО полностью на кириллице. Пример: "Иванов Иван Иванович". | |
| region | No | Опционально — код или название субъекта РФ для ускорения поиска. | |
| birth_date | Yes | Дата рождения в формате "YYYY-MM-DD" или "dd.mm.yyyy". |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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.
check_legal_entity_debtsB
Проверить открытые исполнительные производства на юр.лицо или ИП-предпринимателя.
| Name | Required | Description | Default |
|---|---|---|---|
| inn | No | ИНН (10 цифр для юр.лица или 12 для ИП-предпринимателя). | |
| ogrn | No | ОГРН (13 цифр) или ОГРНИП (15 цифр). Хотя бы один из двух параметров должен быть передан. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It implies a read operation but does not state safety, side effects, authentication needs, or idempotency. The Russian text is also a barrier.
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 concise sentence that immediately states purpose. However, it could be expanded slightly to improve completeness without losing conciseness.
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 an output schema exists, return values need not be explained, but the description omits important context such as the fact that both parameters are optional but at least one must be provided (implied by schema but not in description). Also, the tool's geographic scope (Russia) is implicit through language.
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 baseline is 3. The description adds no extra meaning beyond the schema; it only restates the overall purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks open enforcement proceedings for legal entities and individual entrepreneurs. The verb 'check' and resource 'debts' are specific, and it distinguishes from sibling 'check_individual_debts' which targets individuals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'check_individual_debts' or 'get_proceeding_details'. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_proceeding_detailsA
Получить детальную карточку конкретного ИП по его номеру.
| Name | Required | Description | Default |
|---|---|---|---|
| proceeding_id | Yes | Номер ИП в формате "12345/22/74033-ИП". |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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
Диагностика: сервер жив, сообщает версию и текущий провайдер.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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
Each tool has a clearly distinct purpose: individual vs legal entity debt checks, detail retrieval by proceeding number, and a diagnostic ping. No overlap.
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.
With 4 tools, the server is well-scoped for its domain—covering main debt checks and details—without being too sparse or overloaded.
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
Related MCP Connectors
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceAn MCP server for FixPayment creditors that simplifies account management, status updates, and reporting through plain-English AI interactions (https://fixpayment.org/)
- AlicenseAqualityDmaintenanceMCP 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.657MIT
- AlicenseAqualityBmaintenanceMCP 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).815MIT
- AlicenseAqualityAmaintenanceMCP 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.82MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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