Krasoft Russian Public Procurement

Поиск позиций техзаданий контрактов

search_contract_tech_specs

Read-only

Поиск по позициям технических заданий (ТЗ) заключённых контрактов — одна строка = позиция ТЗ контракта вместе с исходным пунктом ТЗ извещения: МНН или вид медизделия (miTypeCode — 6-значный код вида по НКМИ, miTypeName, классификация miSection/miSubsection), торговое наименование, лекарственная форма и дозировка, производитель, страна, количество, цена, сумма, снижение, заказчик и поставщик, номера контракта и извещения. Ответ на первой странице содержит Aggregates по всей выборке. Строк выдачи — не больше 200 (10 страниц по 20); для сводной задайте groupBy — итоги по виду МИ, классификации, году или месяцу подписания, владельцу РУ или производителю считаются на сервере по ВСЕЙ выборке и приходят в groups (если строки не нужны — pageSize: 1). Доступ: MCP-сервис страницы «Техническое задание · Контракты», его подключает менеджер КРАСОФТ; без него инструмент вернёт отказ.

Input Schema

TableJSON Schema

Name	Required	Description
`fz`	No	Закон: 44 и/или 223
`mnn`	No	МНН, напр. "Ибупрофен"
`page`	No	Страница выдачи (0-based)
`query`	No	Текст поиска: МНН, торговое наименование, производитель, номер контракта или извещения
`period`	No	Период по году подписания контракта: "2y" — последние 2 года, "5y" — 5 лет, "older" — старше 5 лет, "all" — весь корпус (медленнее). По умолчанию "2y"; при заданных датах — "all"
`country`	No	Страна производства (точное название)
`groupBy`	No	Сводная по всей выборке; в каждой группе key — значение разреза. Разрезы МИ (только позиции МИ): "miType" — по коду вида НКМИ (с его классификацией), "miClassification" — по подразделу классификации, "miSection" — по разделу. "signedYear" / "signedMonth" — ряд по годам или месяцам подписания (key «2026» / «2026-03», группы по времени; если периодов больше groupSize — последние). "regHolder" — владелец РУ (вероятный), "manufacturer" — производитель (вероятный): те же поля, что в BI, считаются по аналитической витрине и не работают со свободным текстом query; незаполненные — группа «[не указан]». По каждой группе: rows, sum, qty, contracts (оценка, погрешность до 2–3 %); groupsTotal, totalRows/totalSum и otherRows/otherSum — чтобы итог по группам сходился с итогом выборки. Если сводная не посчиталась, причина — в groupsError
`pageSize`	No	Размер страницы
`signedTo`	No	Дата подписания контракта по (ГГГГ-ММ-ДД)
`groupSize`	No	Сколько групп вернуть, по убыванию суммы
`onlyGnvlp`	No	Только препараты из перечня ЖНВЛП
`tradeName`	No	Торговое наименование
`miTypeName`	No	Вид медизделия по словам названия в НКМИ, напр. "перчатки нитриловые"
`signedFrom`	No	Дата подписания контракта с (ГГГГ-ММ-ДД)
`contractNum`	No	Реестровый номер контракта
`miTypeCodes`	No	Коды видов медизделий по НКМИ — 6 цифр, напр. ["185830"]
`regionCodes`	No	Коды регионов РФ: 2 цифры ("77" — Москва) либо полный 13-значный код
`customerInns`	No	ИНН заказчиков
`includeTotal`	No	Точный счёт найденного без потолка. Без него total не больше 10 000 — это значит «10 000 и больше»
`manufacturer`	No	Производитель
`supplierInns`	No	ИНН поставщиков
`notificationNum`	No	Номер извещения
`miClassification`	No	Классификация МИ по видам: код раздела ("2"), подраздела ("2.25") или слово из названия ("перчатки")

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 15, 2026

changedInput schema / properties / groupBy / description

Previous value: -"Сводная по всей выборке, только позиции МИ: \"miType\" — по коду вида НКМИ (с его классификацией), \"miClassification\" — по подразделу классификации, \"miSection\" — по разделу. По каждой группе: rows, sum, qty, contracts (оценка, погрешность до 2–3 %); groupsTotal, totalRows/totalSum и otherRows/otherSum — чтобы итог по группам сходился с итогом выборки"New value: +"Сводная по всей выборке; в каждой группе key — значение разреза. Разрезы МИ (только позиции МИ): \"miType\" — по коду вида НКМИ (с его классификацией), \"miClassification\" — по подразделу классификации, \"miSection\" — по разделу. \"signedYear\" / \"signedMonth\" — ряд по годам или месяцам подписания (key «2026» / «2026-03», группы по времени; если периодов больше groupSize — последние). \"regHolder\" — владелец РУ (вероятный), \"manufacturer\" — производитель (вероятный): те же поля, что в BI, считаются по аналитической витрине и не работают со свободным текстом query; незаполненные — группа «[не указан]». По каждой группе: rows, sum, qty, contracts (оценка, погрешность до 2–3 %); groupsTotal, totalRows/totalSum и otherRows/otherSum — чтобы итог по группам сходился с итогом выборки. Если сводная не посчиталась, причина — в groupsError"

changedInput schema / properties / groupBy / enum

Previous value: -[
-  "miType",
-  "miClassification",
-  "miSection"
-]New value: +[
+  "miType",
+  "miClassification",
+  "miSection",
+  "signedYear",
+  "signedMonth",
+  "regHolder",
+  "manufacturer"
+]

Changed1 schema field changedOct 15, 2026

changedInput schema / properties / groupBy / description

Previous value: -"Сводная по всей выборке, только позиции МИ: \"miType\" — по коду вида НКМИ (с его классификацией), \"miClassification\" — по подразделу классификации, \"miSection\" — по разделу. По каждой группе: rows, sum, qty, contracts (число контрактов — оценка, погрешность до 2–3 %); groupsTotal, totalRows/totalSum и otherRows/otherSum — чтобы итог по группам сходился с итогом выборки"New value: +"Сводная по всей выборке, только позиции МИ: \"miType\" — по коду вида НКМИ (с его классификацией), \"miClassification\" — по подразделу классификации, \"miSection\" — по разделу. По каждой группе: rows, sum, qty, contracts (оценка, погрешность до 2–3 %); groupsTotal, totalRows/totalSum и otherRows/otherSum — чтобы итог по группам сходился с итогом выборки"

Changed1 schema field changedOct 14, 2026

changedInput schema / properties / groupBy / description

Previous value: -"Сводная по всей выборке, только позиции МИ: \"miType\" — по коду вида НКМИ (с его классификацией), \"miClassification\" — по подразделу классификации, \"miSection\" — по разделу. По каждой группе: rows, sum, qty, contracts; groupsTotal, totalRows/totalSum и otherRows/otherSum — чтобы итог по группам сходился с итогом выборки"New value: +"Сводная по всей выборке, только позиции МИ: \"miType\" — по коду вида НКМИ (с его классификацией), \"miClassification\" — по подразделу классификации, \"miSection\" — по разделу. По каждой группе: rows, sum, qty, contracts (число контрактов — оценка, погрешность до 2–3 %); groupsTotal, totalRows/totalSum и otherRows/otherSum — чтобы итог по группам сходился с итогом выборки"

Changed5 schema fields changedOct 14, 2026

addedInput schema / properties / groupBy

Added value: +{
+  "description": "Сводная по всей выборке, только позиции МИ: \"miType\" — по коду вида НКМИ (с его классификацией), \"miClassification\" — по подразделу классификации, \"miSection\" — по разделу. По каждой группе: rows, sum, qty, contracts; groupsTotal, totalRows/totalSum и otherRows/otherSum — чтобы итог по группам сходился с итогом выборки",
+  "enum": [
+    "miType",
+    "miClassification",
+    "miSection"
+  ],
+  "type": "string"
+}

addedInput schema / properties / groupSize

Added value: +{
+  "default": 50,
+  "description": "Сколько групп вернуть, по убыванию суммы",
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / miClassification

Added value: +{
+  "description": "Классификация МИ по видам: код раздела (\"2\"), подраздела (\"2.25\") или слово из названия (\"перчатки\")",
+  "type": "string"
+}

addedInput schema / properties / miTypeCodes

Added value: +{
+  "description": "Коды видов медизделий по НКМИ — 6 цифр, напр. [\"185830\"]",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / miTypeName

Added value: +{
+  "description": "Вид медизделия по словам названия в НКМИ, напр. \"перчатки нитриловые\"",
+  "type": "string"
+}

AddedSep 15, 2026

TDQS

A4/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses substantial behavioral facts: the 200-row/10-page output ceiling, Aggregates returned on the first page, groupBy totals computed server-side over the entire selection with groups/groupsError, and the access prerequisite that produces a refusal if unconfigured.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the purpose, but the long enumeration of row fields (miTypeCode, miTypeName, classification, trade name, form, dosage, manufacturer, country, quantity, price, sum, reduction, customer, supplier, numbers) largely duplicates the schema and bloats an already dense paragraph.

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 23-parameter tool with no output schema, the description adequately conveys the response shape (row fields, Aggregates, groups, groupsError), pagination limits and the access requirement. It stops short of explaining row-level total semantics, but is 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% and the schema itself documents every parameter in depth (notably groupBy). The description adds little beyond the schema except the cross-parameter hint that pageSize: 1 works with groupBy for summaries, so the 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 states a specific verb+resource: searching across the technical-specification positions of concluded contracts, and explains that one row is a contract ТЗ position joined with the notice's ТЗ point. It distinguishes itself from the notice side by naming the source (извещения), though it never explicitly contrasts with close siblings like search_contract_specs or search_contract_products.

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?

It gives clear usage context: use groupBy for server-side summaries over the whole selection, and pageSize: 1 when rows aren't needed; it also warns the tool needs the MCP page service or returns a refusal. It lacks explicit when-not guidance or named alternatives among the sibling search tools.

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

All Krasoft Russian Public Procurement tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?