This server enables AI agents to search and retrieve Russian court decisions (судебная практика РФ) via the sudact.ru database.
search_cases: Full-text search of Russian court cases with filters for:
Court type: Supreme Court (ВС РФ), arbitration, general jurisdiction, Constitutional Court, or all
Instance: first, appeal, cassation, supervision, or any
Legal norms/articles (статьи закона)
Date range (date_from / date_to in YYYY-MM-DD format)
Number of results (1–50)
Returns total_found count plus a list of cases with case_id and url
get_citation: Retrieves the full text of a court decision by url (from sudact.ru) or case_id, with optional anonymization at three levels:
none — as published
physical_persons — mask names of individuals
all_persons — mask both individuals and legal entities
Судебная практика РФ для AI-агентов — Russian court case-law search for AI agents (Cursor, Claude, and any MCP client).
MCP-сервер (Model Context Protocol) для поиска по судебной практике России: полнотекстовый поиск по текстам решений — по тексту документа, статье закона, суду, инстанции и датам — и получение полного текста решения по выбранному делу.
Работает через hosted-API atomno-mcp: движок поиска, кэш и анонимизация ПДн — на нашей стороне, вам не нужно ничего парсить или поднимать, данные всегда свежие. Нужен только API-ключ (тариф Pro) — atomno-mcp.ru/pricing.
pipx install atomno-mcp-sudact
# или: uvx atomno-mcp-sudactRelated MCP server: mcp-egrul
Переменная | Описание | Где взять | Обязательна |
| API-ключ (заголовок | да | |
| Базовый URL бэкенда | по умолчанию прод | нет |
| Таймаут HTTP, сек (default 60) | — | нет |
mcp.json){
"mcpServers": {
"sudact": {
"command": "uvx",
"args": ["atomno-mcp-sudact"],
"env": { "MCP_SUDACT_TOKEN": "ваш-ключ" }
}
}
}claude_desktop_config.json){
"mcpServers": {
"sudact": {
"command": "uvx",
"args": ["atomno-mcp-sudact"],
"env": { "MCP_SUDACT_TOKEN": "ваш-ключ" }
}
}
}Тул | Вход | Выход | Описание |
|
|
| Полнотекстовый поиск как на sudact.ru |
|
| Полный текст решения (+ опц. анонимизация) | Полный текст решения по карточке/ id |
Проект не аффилирован с sudact.ru. Данные — из открытых источников; используете на свой риск. Полнотекстовый доступ предоставляется как hosted-сервис по подписке.
MIT — см. LICENSE.
Полный текст судебного решения по url карточки sudact.ru или case_id.
Тянет полный текст решения (с сервера), с опциональной анонимизацией ФИО. Нужно указать url или case_id. Требуется ключ MCP_SUDACT_TOKEN (тариф Pro).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL карточки sudact.ru (из выдачи search_cases). | |
| case_id | No | case_id из выдачи (если дело уже в кэше). | |
| anonymize_level | No | none — как опубликовано; physical_persons — маскировать ФИО физлиц; all_persons — и физлиц, и юрлиц. | none |
| include_full_text | No | Вернуть полный текст решения. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool fetches from server, supports optional anonymization, and requires authentication. It does not detail potential errors or behavior when both parameters are provided, but covers essential traits.
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 three sentences, front-loaded with the main purpose, and contains no extraneous information. Every sentence serves a clear function.
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 tool has an output schema and all parameters are described, the description is fairly complete. It covers the core functionality, required auth, and input options. Missing details like rate limits or error handling are 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?
Schema coverage is 100%, so the description adds limited value beyond the schema. It mentions anonymization and the need for url or case_id, which are already documented in the 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 the tool retrieves the full text of a court decision using either a sudact.ru URL or a case_id. It distinguishes from the sibling tool 'search_cases' by specifying the action (get vs search).
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 specifies that a token (MCP_SUDACT_TOKEN, Pro tier) is required and that either url or case_id must be provided. It does not explicitly state when not to use or compare to alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Полнотекстовый поиск судебных дел РФ — как родной поиск на sudact.ru.
Ищет по тексту документа с фильтрами по статье закона, типу суда, инстанции и датам; возвращает реальный total_found и выдачу с case_id/url для последующего get_citation. Требуется ключ MCP_SUDACT_TOKEN (тариф Pro): движок поиска — на нашем сервере.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Сколько дел вернуть (1-50). | |
| norms | No | Фильтр по статьям закона (первая идёт в поле 'Статья закона'). | |
| query | Yes | Текст документа / формулировка правового вопроса. | |
| date_to | No | Дата по (YYYY-MM-DD). | |
| instance | No | Инстанция: any | first | appeal | cassation | supervision. | any |
| date_from | No | Дата с (YYYY-MM-DD). | |
| court_type | No | vs — ВС РФ; arbitr — арбитраж; soyu — общей юрисдикции; ks — КС; any — все. | any |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses key behaviors: full-text search, filters by law article/court type/instance/dates, returns total_found and case_id/url, and requires token. Missing details on error handling, rate limits, or pagination.
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 concise Russian sentences; first states purpose, second adds key details. No redundant or extraneous text.
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?
With full schema coverage and an output schema present, description adds value by mentioning returned fields (total_found, case_id/url) and integration with sibling tool. Covers all essential aspects for a search tool.
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 summarizes parameter usage ('filters by article, court type, instance, dates') but does not add significant new semantics beyond what the schema already provides.
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 performs full-text search of Russian court cases, similar to sudact.ru. It distinguishes from sibling 'get_citation' by noting it returns case_id/url for subsequent citation retrieval.
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 mentions required authentication token (MCP_SUDACT_TOKEN) and tariff (Pro), and implies usage context by noting that returned case_id/url is for subsequent get_citation. However, it does not explicitly exclude alternatives or state when-not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Оба инструмента имеют четко разные цели: search_cases выполняет поиск дел по тексту и фильтрам, а get_citation извлекает полный текст конкретного решения. Нет пересечения или двусмысленности.
Имена инструментов следуют единому шаблону snake_case: search_cases и get_citation. Оба используют глагол_существительное, что делает их предсказуемыми и единообразными.
Сервер имеет всего 2 инструмента, что минимально для поиска и получения дел. Этого достаточно для базового сценария, но может не хватить для более сложных запросов (например, без фильтрации по судье).
Основные операции (поиск с фильтрами и получение полного текста) присутствуют. Однако отсутствует возможность получить метаданные дела (например, дату, судью) без скачивания всего текста, что является заметным пробелом.
Thai legal search MCP — statutes, gazette, opinions, court cases, with checkable citations.
Slovak court decisions as MCP tools. 12,000+ decisions, GDPR-compliant, pseudonymized, SLA-backed.
MCP server for Russian books search, details, and recommendation candidates.
Case law search, court decisions and súmulas, across indexed public sources (STF, STJ, TST, state co
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-sudact'
If you have feedback or need assistance with the MCP directory API, please join our Discord server