Krasoft Russian Public Procurement

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

Annotations carry only readOnlyHint=true, and the description adds substantial behavioral context beyond it: tiered quota limits (anonymous 20/50, free key krsp_ 100/200, paid unlimited), the exact error signal on quota exceedance ('вернёт isError с инструкцией'), and auth acquisition details. Even with annotations lowering the bar, this disclosure of rate limits, auth needs, and failure behavior exceeds the minimum.

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 definition is dense but organized: core purpose and field list lead, followed by the exclusion, the use case, and the quota/error contract at the end. Every sentence conveys needed information, though the field enumeration is long and the quota section is verbose; it earns its place but is not maximally lean.

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?

For a single-parameter read-only lookup with no output schema, the description compensates well by enumerating return data, exclusions, quotas, and error behavior — an agent can decide to call it and anticipate the response. It remains short of 5 because the absence of an output schema leaves the exact response structure and any pagination/format of 'свежие извещения' undescribed.

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%: the inn parameter already carries a pattern (10 or 12 digits) and a Russian explanation of legal-entity vs individual-entrepreneur. The description reinforces 'по ИНН' but does not add any formatting, syntax, or validation detail beyond the schema, so the baseline 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 opens with a specific verb+resource ('Публичный профиль заказчика по ИНН') and enumerates the concrete data fields (name, KPP, registration number, notice counts, contract sums, OKPD2 structure, fresh notices). It further differentiates from siblings with the explicit exclusion 'Поставщиков не отдаёт' and a clear positioning as a quick-overview tool, so an agent can distinguish it from the many search_* and get_* siblings.

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 states its intended use case ('Подходит для быстрой оценки «кто это и сколько закупает»') and provides a when-not/negative constraint ('Поставщиков не отдаёт'), which signals when to look elsewhere. It falls short of a 5 because no alternative sibling is explicitly named with a routing condition, leaving the agent to infer which sibling covers supplier data.

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

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

The readOnlyHint annotation already marks this as a read operation, and the description adds substantive behavioral context beyond that: it does not return a position list, only aggregate KPIs, and it will return a refusal if the MCP-service is not connected. This is genuinely useful operational detail that the annotation alone does not provide.

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 compact and front-loaded: the core behavior and return fields come first, followed by the key limitation and sibling pointer, then the access condition. Every sentence carries necessary information without repetition or filler.

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?

Even without an output schema, the description names all four return KPIs. It covers the tool's scope, its limitation, the alternative tool for detailed positions, and the access/failure scenario. For a read-only aggregate tool with six optional, well-documented parameters, this is complete enough for an agent to call it 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?

Schema description coverage is 100%, so the input schema already documents every parameter, including period options and region code formats. The description adds no parameter-level detail beyond saying results are produced 'under a given filter', so the 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 names a specific resource and result: an aggregated KPI summary over 44-FZ contract execution line items. It lists the exact return metrics (totalSum, totalQty, contracts, suppliers) and explicitly distinguishes itself from search_contract_executions by stating it does not return position details. This is a concrete verb-plus-resource statement with clear sibling differentiation.

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 tells the agent exactly when to choose this tool versus the alternative: it returns only KPIs, and for actual positions it directs to search_contract_executions. It also states the access prerequisite (the MCP-service must be enabled by a KRAFOOT manager) and the failure outcome, leaving no ambiguity about when the tool is appropriate.

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

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

Annotations only declare readOnlyHint=true, so the description carries the burden of explaining behavior. It thoroughly discloses that free-tier values may be masked, that quotas vary by account type, and that exceeding limits returns isError with instructions. This goes well beyond the annotations.

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 front-loaded with the tool's core purpose and return contents, then provides necessary operational details about masking and quotas. Every sentence carries relevant information without redundancy.

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 no output schema, the description adequately explains what the tool returns, including the structure of the card and specification items. It also covers degradation behavior, quota limits, and error signaling, making the tool fully usable by an agent.

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?

There is only one parameter and the input schema already documents it fully with 100% coverage. The description mentions cctUniqID but does not add significant meaning beyond what the schema states about it being the internal contract ID.

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 identifies the tool as returning a contract card by internal ID (cctUniqID), listing both header fields and specification line items. This distinguishes it from sibling search tools like search_contracts and get_tender by specifying the exact resource and retrieval key.

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 when to use it: when you have an internal contract ID (cctUniqID). It gives useful quota and tier context, but it does not explicitly state when to choose this over sibling tools or provide exclusion conditions.

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

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

Annotations provide readOnlyHint=true, and the description goes well beyond that by disclosing per-tier daily quotas (20/50 anonymous, 100/200 free, unlimited paid), the account key location, and the isError response when limits are exceeded. This is valuable operational behavior that an agent needs before calling the tool.

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 first sentence front-loads the core purpose and content list, while the second and third compactly convey quota tiers and error behavior. The length is justified by the operational constraints, though slightly more concise quota phrasing could earn a 5.

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?

For a one-parameter tool with no output schema, the description compensates by naming the return contents (subject, customer, НМЦК, stages, dates, platform, securities, links) and the quota error behavior. It lacks only explicit when-not-to-use guidance, but this is a minor gap given the simple input contract.

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%: the schema already documents uniqId as 'Внутренний ID извещения (ntfUniqID из search_tenders)', and the tool description repeats the same provenance without adding format, range, or dependency details. The baseline of 3 for full schema coverage 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 a specific verb and resource: 'Детальная карточка извещения о закупке по внутреннему ID' and enumerates the card's contents (предмет, условия, заказчик, НМЦК, этапы и даты, площадка, обеспечения, ссылки). It also ties the identifier to search_tenders, distinguishing it from list/search siblings.

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 phrase 'поле ntfUniqID из результатов search_tenders' clearly indicates this tool is the detail-retrieval step after performing a search, giving the agent a concrete when-to-use signal. It does not explicitly exclude alternatives like get_tender_documents, but the internal-ID prerequisite provides adequate context for selection.

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

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

Read-only intent is already in annotations, but the description adds important behavioral limits: it returns only links, not file contents, and describes the failure mode when the MCP service is unavailable. This goes beyond what annotations convey.

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?

Every sentence carries distinct information: purpose/return fields, content limitation, sibling routing, and access precondition. No filler or repetition of schema.

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?

For a one-parameter read-only tool with no output schema, the description is complete: it lists returned fields, excludes file content, names the alternative for structured specs, and states access prerequisites. An agent can invoke confidently without opening schemas.

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 schema already fully documents uniqId with a description, so the baseline is 3. The description adds value by identifying the field origin (ntfUniqID from search_tenders), connecting the parameter to a sibling tool's output.

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 a specific verb ('Список документации') and resource (procurement notice documents by internal ID), and enumerates returned fields and example document types. It differentiates itself by explicitly redirecting parsed tech-spec items to search_tender_tech_specs.

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?

It specifies the required input source (ntfUniqID from search_tenders) and names the alternative tool for parsed tech-spec items. It also discloses the precondition: the MCP service of the 'Тендеры · Извещения' page must be connected, otherwise the tool refuses.

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

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

Though readOnlyHint is already set, the description adds important behavioral context beyond that: daily quota tiers, exact limits for anonymous/free/paid users, and the fact that exceeding the quota returns isError with instructions. It also clarifies what the output contains (counts, sums, trends, top customers/regions) and what it deliberately omits (product prices).

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 tool description is a single dense block with all information front-loaded: purpose, kinds, output contents, exclusions, quotas, and error behavior. It is wordier than strictly needed, but each sentence contributes unique information and no paragraphs/embellishments are wasted.

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?

There is no output schema, so the description does the work of explaining return content: counts of purchases and contracts, sums, year trend, top customers/regions. It also explains the quota/error outcome and exclusions. Given the two-parameter complexity and readOnly annotation, this is sufficient for a competent agent to invoke the tool, though an exact response shape would be even better.

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% and both parameters are already documented, so the baseline is 3. The description still adds value by mapping each kind to its concrete format and providing realistic examples ('21.20.10', 'ibuprofen'), plus specifying the oddity that MNN codes are krasoft.ru slugs in Latin rather than simple classifier codes.

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 opens with a precise verb+resource statement: an aggregated market slice of state procurement by classifier code. It enumerates exactly which code types are supported (okpd2, ktru, mnn) and names sibling tools (search_purchase_objects, search_contract_specs) for what this tool explicitly does NOT provide, making differentiation strong.

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 explicitly states the tool's usage as an aggregated market snapshot and provides an explicit when-not-to-use case: product prices are not included and must be obtained from search_purchase_objects/search_contract_specs on a paid tier. It also gives concrete quota behavior for anonymous, free, and paid use, so an agent knows when it will fail.

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

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

Annotations already declare readOnlyHint=true, and the description adds useful behavioral context: the first page contains Aggregates, each row is a shipped position with a detailed field list, and the tool returns a refusal if the required MCP service is not connected. This goes beyond the annotation without contradicting it.

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 long but purposeful: purpose is front-loaded, the output composition is enumerated because no output schema exists, and the aggregates/access notes are placed at the end. Every sentence contributes useful information; only the field list is verbose, but it earns its place.

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?

For a complex 18-parameter search tool with no output schema, the description covers the output shape, first-page aggregates, and the access-dependent failure mode. It does not explain filter combination behavior or route to sibling tools, but the schema handles individual parameter semantics, making this adequate.

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% across all 18 parameters, with descriptions and constraints already provided. The tool description focuses on output structure and access rather than input parameter semantics, so the baseline of 3 applies.

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 a specific verb and resource: 'Поиск по исполнению технических заданий контрактов на лекарственные препараты', and clearly defines the result granularity as one row per shipped item. This delivery-line focus distinguishes it from sibling tools like search_contract_executions 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended use is explicit: search drug contract delivery lines against contract technical specifications. It also discloses an access prerequisite and the failure mode if the MCP service is unavailable. It does not name sibling alternatives or exclusions, but the context is clear enough for a 4.

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

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

Beyond the readOnlyHint annotation, the description discloses a dependency on the MCP-service of the page 'Исполнение · Объекты закупок' and states that the tool returns a refusal without it. It also details the row structure, which helps predict the response shape given no output schema.

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 text is a long run-on sentence with a dense list of output fields; while accurate, it would benefit from bullet points or sentence breaks. It does front-load the purpose, but the structure hampers quick scanning.

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?

Considering the absence of an output schema and the 14 parameters, the description compensates by enumerating the expected row fields and noting the access dependency. It doesn't cover all edge behaviors (e.g., total limit semantics) but those are documented in the schema.

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 schema already describes all 14 parameters with 100% coverage; the description adds no additional parameter-level semantics, only output field details. 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 identifies the resource ('сведения об исполнении контрактов') and verb ('Поиск'), and specifies the output granularity (one row per product/work/service). It names executions_summary for KPI needs but does not explicitly differentiate from other search_contract_* siblings, so not a full 5.

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 only usage guidance is implicit: the phrase 'KPI по той же выборке — executions_summary' suggests using executions_summary for aggregate metrics instead of this tool. The access prerequisite is mentioned but no comparisons to other search_contract_* tools are provided.

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

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

Annotations already provide readOnlyHint=true. The description adds non-obvious behavioral context: the tool depends on a separately connected MCP service and will return a refusal without it, and it defines the output granularity as one row per procurement object at OKPD2/KTRU level. This goes beyond the annotations without contradicting them.

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 compact but informative: it front-loads the core action, then gives row semantics, the use case, and the access prerequisite. Each sentence adds value, though the field enumeration makes it slightly longer than strictly necessary.

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?

For a 17-parameter read-only search tool with no output schema, the description provides a clear output field list, a use case, and an access disclaimer, while the schema covers all parameters. It does not describe the response envelope or pagination, but the includeTotal and pageSize parameter descriptions already cover the relevant behavior.

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%, and every parameter already has a meaningful description. The description provides output and usage context but does not need to add parameter-level semantics, so the baseline 3 applies.

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 a specific verb and resource: 'Поиск по товарным позициям спецификаций заключённых контрактов'. It also defines the row granularity at OKPD2/KTRU level and enumerates the returned fields, which distinguishes it from the broader contract and specification search siblings.

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 explicitly gives the intended use case: 'кто, у кого и почём купил конкретный товар'. This is clear contextual guidance, though it does not name specific sibling tools or state when not to use it.

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

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

Annotations only mark readOnlyHint=true; the description adds real behavior: the response is one row per contract with listed fields, the first page contains Aggregates, and the tool depends on a specific MCP service and will refuse without it. No contradiction with annotations.

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 front-loaded with purpose and granularity, then covers output, the alternative tool, aggregates, and access in four focused sentences. Every sentence carries useful operational information with no filler.

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?

Despite having no output schema and 15 optional inputs, the description gives enough response-shape detail (contract fields, aggregates) and preconditions to let an agent invoke the tool correctly. The remaining parameter information is already fully present in the input schema.

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?

Input schema coverage is 100%, so the schema already documents all 15 optional parameters. The description mostly summarizes response content and access rather than adding meaning to the parameters; it does not materially extend parameter semantics.

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 opens with a specific action and resource — 'Поиск заключённых контрактов (44-ФЗ и 223-ФЗ)' — and clarifies the row granularity (one row = one contract). It names get_contract as the detail/card tool, so an agent can distinguish this list search from the related contract-card tool.

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?

It gives an explicit routing rule: use get_contract with cctUniqID for a contract card with line items. It also states the access prerequisite (MCP service connected by a KRA SOFT manager; otherwise the tool returns a refusal). It does not enumerate all sibling search_contract_* tools, but the primary list-vs-detail distinction is present.

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

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

Annotations only carry readOnlyHint=true, and the description adds substantial behavior beyond it: the split fields mnn, tradeName, manufacturer, and country are empty in the response because everything is flattened into name; contract number, customer, supplier, and region are absent for more than half of rows by 2026; the response includes Aggregates (total sum and quantity, number of contracts and suppliers); and the access failure mode is an explicit refusal. No contradiction with the readOnly annotation.

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 dense rather than short, but every sentence earns its place: search scope, data-model quirk, unsafe-filter warning, response aggregates, and access prerequisite. The verb+resource is front-loaded, and the length is justified for a 9-parameter tool with no output schema, though it could be tightened slightly.

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?

For a 9-parameter tool with no output schema, the description covers the essential operational facts: what is searched, the response shape (flattened name field, empty split fields, Aggregates), which filters are unsafe, and the access requirement. It omits empty-result behavior and sorting, but an agent has enough information to call 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?

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by warning that filters such as customerInns, supplierInns, regionCodes, and query (contract number/customer/supplier) will silently cut off matching rows because those attributes are often missing — behavioral semantics that the parameter descriptions alone cannot convey.

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 opens with a precise verb+resource — 'Поиск по строкам спецификаций заключённых контрактов 44-ФЗ' — and defines the unusual data model: one row equals one specification position with the full text in the name field. The scope is clear, but it does not explicitly name or contrast any sibling tool (e.g., search_contract_products), so differentiation among the many sibling search tools is implied rather than stated.

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 gives concrete usage context: filters on contract number, customer, supplier, and region 'отсекают остальные' because these attributes are missing from most rows, and it warns that the tool depends on a KRA SOFT manager-connected MCP service, otherwise 'инструмент вернёт отказ'. This is clear when/when-not guidance for filters and prerequisites, though it never names an alternative tool, leaving when-to-pick-this-over-siblings implicit.

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

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

Beyond the readOnlyHint annotation, the description discloses a critical auth requirement (MCP-service page 'Техническое задание · Контракты' connected by a КРАСОФТ manager, otherwise refusal) and a response behavior (first page contains Aggregates over the entire selection). This is meaningful behavioral context not present in the annotations.

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 purpose is front-loaded and the sentence is information-dense with no filler. The long list of row fields is justified because it defines what a 'position' means; the access note is a distinct final sentence. Slightly overloaded but efficient.

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 no output schema, the description does enough to sketch the return semantics: one row equals a contract TZ position with the source notice TZ item and the listed attributes, plus aggregate results on the first page. Combined with a fully described schema, this gives an agent most of what it needs, though it omits explicit alternative routing and pagination behavior beyond first-page aggregates.

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 schema already documents all 18 parameters. The tool description adds no parameter-specific guidance beyond restating the kind of fields returned in each row, so it stays at the baseline without compensating for any schema gaps.

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 opens with a clear Russian purpose: search across positions of technical specifications (ТЗ) of concluded contracts, and defines the output row composition. The resource is specific enough to separate it from tender-side and contract-spec siblings, though it does not name an alternative tool explicitly.

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 prefer this tool over sibling tools such as search_tender_tech_specs or search_contract_specs. It only states the search domain and an access prerequisite, leaving selection logic to the agent.

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

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

Annotations only declare readOnlyHint=true. The description adds meaningful behavioral context: it describes the access prerequisite (MCP service of the specific page, connected by a KRA SOFT manager), the failure mode ('без него инструмент вернёт отказ'), and the output granularity. This exceeds what annotations alone convey.

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 front-loaded with the primary purpose and uses compact sentences. The list of output fields is somewhat long, but it is relevant because there is no output schema. Overall, each sentence contributes useful information without excessive verbosity.

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 no output schema, the description compensates by enumerating the fields returned per result. It also covers access dependencies, failure behavior, and filter simplicity relative to a sibling tool. For a 6-parameter read-only search tool, this is sufficiently complete for an agent to call it 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?

Schema coverage is 100%, so the baseline is 3. The description adds value by summarizing the filter categories (text, region, dates), listing searchable fields such as МНН, trade name, plan number, IKZ, and customer, and explaining the row semantics. This complements rather than merely repeats 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 verb and resource: 'Поиск по объектам закупок в планах-графиках 44-ФЗ'. It further clarifies the result granularity ('одна строка = позиция плана') and explicitly contrasts itself with search_plan_tech_specs by noting simpler filters, so an agent can distinguish it from siblings without opening schemas.

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 names search_plan_tech_specs as the relevant alternative and indicates this tool has simpler filters: 'текст, регион и даты'. This gives clear context for when this tool is appropriate, though it does not explicitly enumerate when-not-to-use conditions or all possible sibling alternatives.

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

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

Annotations already declare readOnlyHint, so the safety profile is covered. The description goes beyond this by specifying the row semantics ('одна строка = один план-график заказчика'), listing the returned fields, and disclosing the failure mode when the MCP service is unavailable ('без него инструмент вернёт отказ').

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 definition is compact (two sentences) and front-loads the core purpose and row format before mentioning alternatives and access. Every clause adds information: result semantics, sibling routing, and a required access precondition — no filler or repetition.

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 no output schema, the description still conveys the return shape by enumerating the columns of each row and the granularity (one row per plan schedule). It covers access requirements, alternatives, and basic filtering context; only minor details such as pagination behavior and the total-count cap are left to the schema.

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% — every parameter already has a meaningful description in the input schema, so the tool description need not repeat them. The description adds no parameter-level semantics beyond the schema; it focuses on output fields, which is acceptable at the baseline of 3.

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 opens with a specific verb and resource — 'Поиск планов-графиков закупок 44-ФЗ' — and enumerates exactly what a result row contains: plan number/version, publication and approval dates, customer INN/EIS registration number, region, financial amounts, and position count. It also distinguishes itself from sibling position-level tools by explicitly pointing to 'search_plan_tech_specs и search_plan_objects' for 'Позиции планов в разрезе товаров'.

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 when to use this tool by naming the two sibling tools that cover plan positions in product detail, so an agent can route between header-level and position-level searches. It also discloses an access precondition: the MCP service for the 'Тендеры · План-график' page must be connected by the KRA SOFT manager, otherwise the tool returns a refusal. It stops short of an explicit when-not-to-use statement, hence 4 rather than 5.

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

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

Beyond the readOnlyHint annotation, the description discloses important behavioral traits: each result row is a specific tech-spec position, the first response page contains Aggregates, and the tool requires an MCP service connection or it will return a refusal. This adds meaningful operational context not present in the annotations.

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 dense and front-loaded with the main purpose, then adds output-field details, use case, response behavior, and access requirements. Each sentence earns its place, though the long list of row fields makes it slightly heavier than strictly necessary.

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?

For a tool with 16 parameters and no output schema, the description covers the return row structure, the presence of Aggregates, and the access constraint. It does not explain what Aggregates contain, but the schema covers all parameters and the use case is clear.

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 baseline is 3. The description reinforces which fields are searchable and describes row contents, but it does not add per-parameter semantics beyond what the input 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 names a specific verb and resource: 'Поиск по товарным позициям технических заданий в планах-графиках 44-ФЗ' and defines the row granularity as one position of a tech spec inside a plan position. It lists the output fields and the use case 'увидеть будущие закупки до публикации извещения', which clearly separates it from tender and contract search siblings.

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 provides a clear usage context: seeing future purchases before the notice is published, and notes an access prerequisite. However, it does not explicitly name sibling alternatives or state when not to use this tool, so it stops short of a full when/when-not guide.

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

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

The readOnlyHint annotation already covers the read nature. The description adds useful behavioral context beyond that: the tool requires a specific MCP service connection and will return a refusal without it, and it lists what each result row contains. No contradiction with annotations.

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?

Three sentences, each carrying distinct value: result structure, level/use case, and access prerequisite. The purpose is front-loaded and there is no repetition of schema content.

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?

Despite having 11 parameters and no output schema, the description covers the essential invocation context: what each returned row contains, how this differs from whole-purchase queries, and what happens if the required MCP service is unavailable. The schema covers the individual parameters sufficiently.

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?

All 11 parameters already have rich descriptions in the input schema, so the main description does not need to explain them in detail. The description provides general result semantics but adds little parameter-specific meaning beyond the schema, matching the baseline for high schema coverage.

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 names a specific verb and resource: searching purchase line items in notices (товарным позициям извещений). It clarifies the row-level granularity and the parent-notice fields included, and explicitly distinguishes this from whole-purchase search, making it easy to tell apart from sibling tools.

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?

It gives a clear intended use case: answering questions like 'кто и почём закупает конкретный товар'. It also clarifies that this is the item level, not the procurement level, but it does not explicitly name alternative tools or state when not to use this tool.

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

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

Annotations already provide readOnlyHint=true, and the description goes well beyond that by disclosing performance tradeoffs ('all' slower), the meaning of total capping at 10,000 (i.e., '10,000 and more') when includeTotal=false, exact quotas per account tier, and the error behavior when limits are exceeded. This is substantial behavioral context that helps an agent anticipate results and failures.

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 information-dense and front-loaded with the core purpose, then proceeds to return fields, performance/limit behavior, and quotas. While it is longer than the minimal two-sentence style, every sentence contributes meaningful operational context (availability, limits, error handling) that an agent needs. It is well-organized and avoids fluff, though it could be tightened slightly.

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 10 parameters, no output schema, and no required fields, the description covers essential operational aspects: returned item fields, pagination indirectly via schema, period behavior, total semantics, quotas, and error handling. It does not explicitly explain parameter combination or sorting, but the schema covers individual parameters, and the description provides enough context to call the tool correctly without ambiguity.

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% parameter description coverage, including details for period, includeTotal, regionCodes, customerInns, etc. The description adds a high-level summary of filter categories and repeats the includeTotal semantics, but it does not introduce new parameter-level meaning not already in the schema. Baseline 3 is appropriate because the schema carries the parameter semantics.

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 opens with a specific verb and resource: 'Поиск извещений о госзакупках РФ' (search for Russian state procurement notices), and enumerates the supported filters (text, region, customer INN, NMCC range, period) and the returned list fields (number, name, NMCC, customer, region, dates, winner/price if awarded). This makes the tool clearly distinct from siblings like get_tender (single tender details) and search_contracts (contracts).

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 supplies clear usage context: it searches notices by text and filters, with a default period of '2y' and a warning that 'all' is noticeably slower. It also specifies quota behavior (anonymous vs free vs paid), which helps an agent decide whether to use this tool under limits. However, it does not explicitly name alternatives or state when NOT to use this tool, so it falls short of a full 5.

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

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

Annotations only declare readOnlyHint=true, so the description carries the burden of behavioral detail. It adds an access/authentication note (the MCP service must be connected by a KRASOFT manager, otherwise the tool returns a refusal) and clarifies that the tool searches only by line name and returns a defined set of specification and notice fields. No contradiction with annotations.

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 dense sentence that front-loads the main purpose and packs in the return fields, the key limitation, the alternative tool, and the access caveat. There is no fluff, but the long semicolon-separated enumeration makes it slightly heavier to parse than necessary.

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 no output schema, the description provides a solid overview of the returned fields (specification position fields plus notice fields). It also covers the access constraint, the alternative path for notice-number filtering, and relies on the 100%-covered schema for parameter details, making it complete for a read-only 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 the baseline is 3 and the schema already documents each parameter. The description still adds value by explaining the query scope ('по наименованию строки') and explicitly warning that there is no notice-number filter, steering agents away from expecting an ntfNum parameter.

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 opens with a specific verb and resource: 'Поиск по строкам спецификаций (документации) извещений' and clarifies the unit of search (one line = one specification position). It explicitly differentiates from the sibling search_tender_tech_specs by noting the absence of a notice-number filter, so an agent can tell tools apart.

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?

It states exactly when this tool is appropriate: text search by line name only, and explicitly routes the agent to search_tender_tech_specs (ntfNum) for positions of a specific purchase. It also discloses the access prerequisite and the failure mode when the MCP service is not connected.

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

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

Annotations only declare readOnlyHint=true; the description adds meaningful behavioral detail: the row-wise granularity of results, which fields are included, the use of ntfNum for a full procurement's positions, and the hard dependency on the MCP service. This goes beyond the annotation without contradicting it.

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 compact and front-loaded with the core purpose, followed by the key grouping parameter and access prerequisite. It is slightly dense due to the enumerated fields, but every sentence contributes useful information.

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?

For an 11-parameter tool with no output schema, the description covers the essential context: result-row semantics, the main filtering/grouping intent, and the access failure mode. It does not discuss pagination or total-count behavior, but those are already documented in the schema parameters.

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 schema carries most parameter meaning. The description's ntfNum note mostly restates the schema's own explanation ('вернёт позиции ТЗ этой закупки'), and it does not add meaningful clarification for other parameters beyond what is already present.

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 resource and action: searching by positions of technical specifications of notices, and enumerates the fields returned per row. It is specific about the unit of search ('одна строка = одна позиция ТЗ внутри лота'), but it does not explicitly distinguish this tool from sibling tools such as search_tender_specifications.

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?

It gives clear operational context: how to retrieve all positions of one purchase using the ntfNum parameter, and warns that the tool requires the MCP service and returns a refusal without it. However, it does not explicitly state when to choose this tool over alternative search tools, so it falls short of full routing guidance.

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