garant-mcp

Overview Schema Source Related Servers Score Discussions Admin

garant_revision_on_date

Identify the legal revision in force on a specific date to cite norms accurately for past events. Returns revision metadata, not text.

Instructions

КАКАЯ редакция действовала на дату. Текста нормы НЕ возвращает.

on_date — «ДД.ММ.ГГГГ». Ответ — запись о редакции: её название, статус, период действия, изменяющий акт и id_редакции. Ни текста статьи, ни блока provenance в нём нет.

действует_с и действует_по в ответе — границы ТОГО периода, которым покрыта запрошенная дата (периодов у редакции бывает несколько; чем это вызвано, карта эндпоинтов не объясняет); он же отдельным ключом _период_на_дату. Полный перечень периодов — в ключе периоды и в garant_revisions.

В день СТЫКА редакций под дату подходят обе: границу периода МЫ читаем включительно с обеих сторон, а как её трактует сам «Гарант», не проверено. Тогда в ответе стоит ключ _предупреждение: он называет всех кандидатов и говорит, что отданная выбрана порядком списка, а не доказана. Тот же ключ появляется, среди прочего, когда карта эндпоинтов не описывает список периодов, когда периодов у записи больше одного и когда сама дата в действует_с не разобралась как дата. Перечень здесь неполный намеренно: ветвей у ключа больше, чем описание способно перечислить не устаревая, — полон только сам ключ, и читать надо его.

Применять, когда норма цитируется применительно к прошлому событию: в жалобе на акт годичной давности норма приводится в редакции, действовавшей на дату того акта, а не в сегодняшней. Ссылка на редакцию, которой на тот момент не существовало, — самостоятельный повод отклонить довод.

ЧЕМ ВЗЯТЬ ТЕКСТ ТОЙ РЕДАКЦИИ. Прямого способа нет: garant_article и garant_document параметра редакции не принимают и собирают provenance по ДЕЙСТВУЮЩЕЙ редакции. Поэтому текст, взятый ими, относится к сегодняшнему дню, даже если этот инструмент вернул другую редакцию, — и ставить их рядом как цитату на прошлую дату нельзя.

Есть непроверенная возможность: id_редакции — это documentId самой редакции, и он МОЖЕТ приниматься как doc_id в garant_article. Проверить это без живой подписки невозможно, поэтому до проверки считать, что способа нет, и говорить пользователю прямо: редакция установлена, дословный текст в ней — нет.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`doc_id`	Yes
`on_date`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 8, 2026

TDQS

A4.9/5.0

Behavior5/5

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

No annotations exist, so the description carries full responsibility, and it delivers: it discloses absent fields (no text/provenance), inclusive edge-date behavior, the _предупреждение key and its intentionally incomplete branches, and an unverified possibility about id_редакции as documentId. It openly labels unchecked assumptions with 'не проверено' and 'МОЖЕТ приниматься'.

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 first line states the core function and the no-text caveat; subsequent sections are clearly delimited (response shape, edge dates, usage, text retrieval) and each paragraph carries non-redundant information. Despite length, no filler is present given the complexity.

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?

For a nuanced legal-history tool with no annotations and an output schema, the description covers input format, response semantics, edge-case warnings, when to use it, and how to (not) obtain revision text. It even tells the agent what to tell the user when direct text retrieval is impossible.

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?

With 0% schema coverage, the description compensates for on_date by specifying the format 'ДД.ММ.ГГГГ' and explaining how the date maps to period boundaries. doc_id is less explicitly described—it is only sensible by context and a later reference to documentId—so a small semantic gap remains.

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 opens with 'КАКАЯ редакция действовала на дату' and immediately clarifies it does not return the norm text. It names the response content (revision record with status, period, amending act, id) and distinguishes itself from garant_article, garant_document, and garant_revisions, so an agent can disambiguate.

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?

Explicit usage context is given: 'Применять, когда норма цитируется применительно к прошлому событию' with a concrete example. The 'ЧЕМ ВЗЯТЬ ТЕКСТ ТОЙ РЕДАКЦИИ' section explicitly states that garant_article and garant_document do not accept a revision parameter and cannot be used for past-date citation, telling when not to use alternatives.

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

Install Server