Belarusian companies by UNP: state registry answers with source and sha256 for every fact.
Scored across 5 tools
check_counterparty (live by name), lookup_company (collected card by UNP), and search_companies (collected search by name/UNP) all return entity data and could be momentarily confused. The descriptions sharply differentiate them via 'live registry' vs 'instant, no registry call' and by single-card vs list semantics, so boundaries are mostly clear.
Three tools follow a verb_noun pattern (check_counterparty, lookup_company, search_companies), but entity_timeline is noun_phrase and sources_and_coverage is a noun construct. The set is still readable, but it is not a single predictable convention.
Five tools is well-scoped for a read-only registry server: search, card lookup, live verification, timeline, and provenance. Each earns a distinct place with no redundancy.
The surface covers the main read lifecycle: discover (search), retrieve (lookup_company), verify live (check_counterparty), track changes (entity_timeline), and assess data trust (sources_and_coverage). Minor gaps like batch/UNP-list lookups or a person/sole-proprietor path exist, but core workflows are covered.
Live answer of the Belarusian State Register of Payers (MNS) and related registries right now: exists / active (да | нет | не_установлено), address, registration date, tax office, bankruptcy cases, exclusion from public procurement, KGK inspection plans, procurement history. Pass name from your documents to get a name-match verdict. Takes seconds; rate-limited. Живой ответ реестра по УНП.
| Name | Required | Description | Default |
|---|---|---|---|
| unp | Yes | УНП субъекта — РОВНО 9 цифр (из документов, ЕГР или ГРП). Иное отклоняется с invalid_unp. | |
| name | No | Наименование контрагента из ваших документов — для сверки имени с ответом реестра (необязательно; если не передано, имя не сверяется). |
| Name | Required | Description |
|---|---|---|
| error | No | Отказ: code и detail |
| унп | No | |
| реестр | No | Какой государственный реестр ответил |
| получено | No | Время получения ответа держателя |
| держатель | No | Держатель данных — атрибуция (Закон 455-З ст.20) |
| существует | No | да | нет | не_установлено |
| проверено_в | No | Момент запроса |
| наименование | No | |
| адрес_запроса | No | Локатор ответа держателя |
| отпечаток_ответа_держателя | No | sha256 сырого ответа |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds value beyond that: rate-limiting, the seconds-scale latency, that the data is live, and the enumerated verdict domain (да | нет | не_установлено). It doesn't describe pagination or the error surface beyond the schema's invalid_unp note.
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 lookup and its scope are front-loaded, and the sentences are dense but purposeful; the optional `name` hint and the rate-limit caveat are separate, short statements. The long enumerated list of returned fields is slightly sprawling and partially redundant with the output schema, but it is compactly packed.
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?
An output schema exists, so return values needn't be spelled out, yet the description enumerates them anyway, which is harmless redundancy rather than a gap. For a two-parameter, read-only lookup with full schema coverage and annotations, an agent has enough to call it correctly; the missing piece is only explicit sibling routing.
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 nonetheless adds meaning by explaining the purpose of the optional `name` parameter (producing a name-match verdict against the registry answer) and confirming the `unp`-driven lookup flow. That is a modest but real increment over the schema's own wording.
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?
It states a specific verb+resource: a live lookup of the Belarusian State Register of Payers by УНП, returning existence/status, address, registration date, tax office, and more. That is unambiguous and far from a tautology. It stops short of naming which sibling tool is the alternative (lookup_company, search_companies), so it doesn't fully differentiate among 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?
It implies usage context (verify a counterparty from your documents via `unp`, optionally pass `name` for a name-match verdict) and adds operational guidance ('takes seconds; rate-limited'). However it never states when NOT to use this tool or which sibling to prefer for cached/bulk/alternative lookups, so guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change timeline of a Belarusian entity by UNP from collected data: an ordered log of canon changes per predicate (created / reaffirmed / superseded / conflict_detected), each event carrying old and new value, source registry and time (effective_at, observed_at). Lets an agent read anomalies over time (sudden address/head/activity change). Instant, no registry call. Хронология изменений субъекта по УНП из собранного.
| Name | Required | Description | Default |
|---|---|---|---|
| unp | Yes | УНП субъекта — РОВНО 9 цифр (из документов, ЕГР или ГРП). Иное отклоняется с invalid_unp. | |
| limit | No | Максимум событий в ответе, 1–500 (по умолчанию 100); новейшие первыми. |
| Name | Required | Description |
|---|---|---|
| unp | No | |
| note | No | |
| error | No | |
| found | No | |
| events | No | События изменения канона, новейшие первыми |
| meaning | No | Пояснение, когда не найдено (НЕ значит «не существует») |
| entity_id | No | Внутренний UUID субъекта |
| event_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real context beyond that: the data comes from already-collected data, no registry call is made, and the response is an ordered event log with old/new values plus source registry and effective_at/observed_at timestamps. It does not discuss limit behavior or empty/unknown-entity outcomes, which the schema partly covers.
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?
Front-loaded and dense with useful detail, and the payload structure is stated efficiently. The trailing Russian sentence duplicates the opening claim about the change log for the UNP, which is redundant text rather than new 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?
With annotations covering safety and an output schema present, the description does not need to explain return values, yet it still conveys the event model, data source, and zero-side-effect timing. An agent has everything needed to decide to call it and interpret the result.
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%, with unp format (exactly 9 digits, invalid_unp on violation) and limit bounds/default/ordering fully documented in the schema. The description adds no parameter-level syntax or constraint beyond that, 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+resource+scope: an ordered change log per predicate for a Belarusian entity identified by UNP, drawn from collected data. It enumerates the event types (created/reaffirmed/superseded/conflict_detected) and the payload each carries, which is far more than a restatement of the name and clearly separates it from lookup/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?
It gives a concrete use case ('read anomalies over time — sudden address/head/activity change') and a selection-relevant fact ('Instant, no registry call'), implying it is the right choice when historical change tracking is needed rather than a live lookup. It does not explicitly name a sibling (e.g. lookup_company for current state) as the alternative, so it stops short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Collected public card of a Belarusian business entity by UNP (9 digits): legal name, status, each statement with registry source, retrieval time and sha256 of the raw response; withheld fields with reasons. Instant, no registry call. Карточка субъекта по УНП из собранного.
| Name | Required | Description | Default |
|---|---|---|---|
| unp | Yes | УНП субъекта — РОВНО 9 цифр (из документов, ЕГР или ГРП). Иное отклоняется с invalid_unp. |
| Name | Required | Description |
|---|---|---|
| unp | No | УНП, 9 цифр |
| card | No | Публичная проекция: утверждения с источником, временем и sha256 |
| page | No | Ссылка на карточку (только если это юрлицо) |
| error | No | Отказ: code (напр. invalid_unp) и detail |
| found | No | Найдена ли карточка в собранном |
| meaning | No | Пояснение смысла, когда не найдено (НЕ значит «не существует») |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: it is instant because it makes no registry call, and it discloses that results come from a stored collection with per-statement registry source, retrieval time, sha256 of the raw response, and withheld fields with reasons.
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 English portion is front-loaded with purpose, then the returned content, then the key latency fact ('Instant, no registry call'). The trailing Russian sentence ('Карточка субъекта по УНП из собранного') duplicates the English purpose and does not earn 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?
With an output schema present, return values need not be enumerated, yet the description usefully sketches them plus provenance and withholding behavior. The only real gap is the absence of routing guidance against the four sibling tools, which is a usage concern rather than a completeness one.
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 the single 'unp' parameter is fully documented in the schema, including the 9-digit constraint and invalid_unp rejection. The description repeats the 9-digit requirement rather than adding syntax or format meaning, 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+resource: retrieving a collected public company card for a Belarusian entity keyed by UNP. The scope is well bounded ('by UNP (9 digits)', 'Collected public card'), which separates it from search_companies, but no sibling tool is named or contrasted, so an agent must infer the boundary from the input alone.
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?
Usage is only implied: the tool requires a known UNP, so it is the lookup path once an identifier is in hand. There is no explicit statement of when to prefer it over check_counterparty, entity_timeline, or search_companies, and no exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search collected Belarusian legal entities by name fragment or UNP. Only legal entities are found by name (sole proprietors never are). Absence here is not absence in the state registry. Поиск юрлица по названию или УНП среди собранного.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Максимум возвращаемых субъектов, 1–25 (по умолчанию 10). | |
| query | Yes | Фрагмент наименования юридического лица ИЛИ его УНП. Индивидуальные предприниматели по названию не находятся (только по УНП через lookup_company/check_counterparty). |
| Name | Required | Description |
|---|---|---|
| error | No | Отказ: code (напр. empty_query) |
| results | No | Публичные проекции найденных юрлиц |
| coverage | No | Охват собранного относительно запроса |
| data_boundary | No | Граница данных (public_projection) |
| search_backend | No | Каким механизмом выполнен поиск |
| degraded_search | No | Был ли поиск в деградированном режиме |
| does_not_establish | No | Что отсутствие результата НЕ устанавливает |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so safety is covered. The description adds genuinely non-structured context: the corpus is 'collected' (a subset, not the registry) and negative results are not authoritative — important framing for how much to trust an empty response. Return format and pagination are left to the 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?
Front-loaded with the core action and only three short sentences, each carrying information (scope, exclusion, negative-result caveat). The trailing Russian sentence duplicates the opening English sentence rather than adding new content, which is mild redundancy for an agent parsing the description.
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 annotations covering the safety profile and an output schema covering return values, the description fills the remaining gaps an agent needs: what the corpus is, what can be found by name, and how to interpret a negative result. Explicit guidance on the lookup_company/check_counterparty fallback for sole proprietors would make it fully self-contained.
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 both parameters (query, limit) are already documented in Russian with format hints, defaults, and the 1–25 range. The description restates that query accepts a name fragment or UNP and adds no syntax or matching rules (e.g., case sensitivity, prefix vs substring) beyond what the schema provides. 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?
States a concrete verb (search) plus the resource (collected Belarusian legal entities), and names both lookup keys: name fragment or UNP. The sentence 'Only legal entities are found by name (sole proprietors never are)' scopes the tool against the sole-proprietor path handled by siblings like lookup_company, so an agent can distinguish it without opening the schema.
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?
Gives clear context for when the tool applies (name-fragment or UNP lookups over the collected corpus) and the crucial caveat that a miss here does not mean the entity is absent from the state registry — 'Absence here is not absence in the state registry.' It stops short of explicitly routing sole-proprietor-by-name cases to an alternative tool in the description body; that routing only appears in the schema's query description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Machine-readable trust card of the registry itself: every source with provenance (organ, tier, URL) and its DECLARED access/rights (machine_api_authorization, terms_status) AS DECLARED in config — not asserted by this tool; plus coverage (claims and evidence per source, which sources give canon) and grounding invariants (total claims, how many lack evidence, off-source, freshness). Technical availability is NOT a legal right to use or redistribute the data. Карточка доверия: источники, права как задекларированы, покрытие и заземление.
| Name | Required | Description | Default |
|---|---|---|---|
| source_id | No | Необязательно: вернуть карточку только одного источника по его ID (напр. BY:MNS:GRP). Пусто — все источники. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| sources | No | Источники: провенанс, права КАК ЗАДЕКЛАРИРОВАНЫ, покрытие |
| card_doc | No | |
| grounding | No | Инварианты заземления: claims_total, claims_without_evidence, off_source, verified_official_without_evidence, evidence_without_locator, entities_with_claims, observed_from/to |
| legal_note | No | Тех.доступность ≠ право; правовые поля отражают декларацию, не утверждение |
| predicates | No | Число утверждений по предикату (топ) |
| generated_at | No | Время сборки карточки (UTC ISO) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive), so the bar is lower, yet the description still adds real behavioral value: rights are 'AS DECLARED in config — not asserted by this tool,' and 'Technical availability is NOT a legal right to use or redistribute the data.' That tells the agent how to interpret the output's epistemic status, which annotations cannot convey. It does not describe pagination or output format limits, so 4 rather than 5.
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 core claim is front-loaded, but the body is a dense run-on that stacks parenthetical qualifiers, and the trailing Russian sentence duplicates the English content verbatim rather than adding information. Every sentence does address the tool's content, yet the structure is heavier than it needs to be for a one-parameter read tool.
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?
An output schema exists, so return values need not be explained, and annotations cover safety; the description still usefully frames what the card contains and warns against misreading declared rights as granted rights. The notable gap is the absence of any when-to-use guidance relative to the sibling tools, which keeps it from a 5.
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 the sole optional parameter source_id is already documented in the schema (return one source's card by ID, empty = all sources). The description does not restate or extend that parameter's semantics, so the baseline of 3 for fully covered schemas 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 resource — a machine-readable trust card of the registry itself — and enumerates the content categories it returns (sources with provenance, declared rights, coverage, grounding invariants). That is far more specific than a name restatement and is clearly a different domain from the sibling tools (check_counterparty, lookup_company, search_companies). It stops short of an explicit comparison to those siblings, so it lands at 4 rather than 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?
Usage is only implied: an agent can infer it should call this to inspect provenance, declared rights, and coverage before trusting or redistributing registry data. There is no explicit statement of when to call this versus the sibling lookup tools, and no prerequisites or exclusions are given. The caveat about legal vs technical availability is a limitation disclosure, not usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
entity_timelinesources_and_coveragecheck_counterparty9 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / name / descriptionAdded value: +"Наименование контрагента из ваших документов — для сверки имени с ответом реестра (необязательно; если не передано, имя не сверяется)."Input schema / properties / name / titleRemoved value: -"Name"Input schema / properties / unp / descriptionAdded value: +"УНП субъекта — РОВНО 9 цифр (из документов, ЕГР или ГРП). Иное отклоняется с invalid_unp."Input schema / properties / unp / titleRemoved value: -"Unp"Input schema / titleRemoved value: -"check_counterpartyArguments"Output schema / descriptionAdded value: +"Живой ответ реестра; ключи на русском; набор полей зависит от существования субъекта и ветки (банкротство, исключение из закупок, планы проверок, закупки). Всегда несёт провенанс: держатель, реестр, адрес запроса, время, sha256 ответа."Output schema / propertiesAdded value: +{
+ "error": {
+ "additionalProperties": true,
+ "description": "Отказ: code и detail",
+ "type": "object"
+ },
+ "адрес_запроса": {
+ "description": "Локатор ответа держателя",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "держатель": {
+ "description": "Держатель данных — атрибуция (Закон 455-З ст.20)",
+ "type": "string"
+ },
+ "наименование": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "отпечаток_ответа_держателя": {
+ "description": "sha256 сырого ответа",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "получено": {
+ "description": "Время получения ответа держателя"
+ },
+ "проверено_в": {
+ "description": "Момент запроса"
+ },
+ "реестр": {
+ "description": "Какой государственный реестр ответил",
+ "type": "string"
+ },
+ "существует": {
+ "description": "да | нет | не_установлено",
+ "type": "string"
+ },
+ "унп": {
+ "type": "string"
+ }
+}Output schema / titleRemoved value: -"check_counterpartyDictOutput"lookup_company7 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / unp / descriptionAdded value: +"УНП субъекта — РОВНО 9 цифр (из документов, ЕГР или ГРП). Иное отклоняется с invalid_unp."Input schema / properties / unp / titleRemoved value: -"Unp"Input schema / titleRemoved value: -"lookup_companyArguments"Output schema / descriptionAdded value: +"Карточка из собранного, либо «не найдено», либо отказ (error)."Output schema / propertiesAdded value: +{
+ "card": {
+ "additionalProperties": true,
+ "description": "Публичная проекция: утверждения с источником, временем и sha256",
+ "type": "object"
+ },
+ "error": {
+ "additionalProperties": true,
+ "description": "Отказ: code (напр. invalid_unp) и detail",
+ "type": "object"
+ },
+ "found": {
+ "description": "Найдена ли карточка в собранном",
+ "type": "boolean"
+ },
+ "meaning": {
+ "description": "Пояснение смысла, когда не найдено (НЕ значит «не существует»)",
+ "type": "string"
+ },
+ "page": {
+ "description": "Ссылка на карточку (только если это юрлицо)",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "unp": {
+ "description": "УНП, 9 цифр",
+ "type": "string"
+ }
+}Output schema / titleRemoved value: -"lookup_companyDictOutput"search_companies9 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / limit / descriptionAdded value: +"Максимум возвращаемых субъектов, 1–25 (по умолчанию 10)."Input schema / properties / limit / titleRemoved value: -"Limit"Input schema / properties / query / descriptionAdded value: +"Фрагмент наименования юридического лица ИЛИ его УНП. Индивидуальные предприниматели по названию не находятся (только по УНП через lookup_company/check_counterparty)."Input schema / properties / query / titleRemoved value: -"Query"Input schema / titleRemoved value: -"search_companiesArguments"Output schema / descriptionAdded value: +"Найденные юрлица из собранного плюс границы охвата, либо отказ (error)."Output schema / propertiesAdded value: +{
+ "coverage": {
+ "description": "Охват собранного относительно запроса"
+ },
+ "data_boundary": {
+ "description": "Граница данных (public_projection)",
+ "type": "string"
+ },
+ "degraded_search": {
+ "description": "Был ли поиск в деградированном режиме",
+ "type": "boolean"
+ },
+ "does_not_establish": {
+ "description": "Что отсутствие результата НЕ устанавливает"
+ },
+ "error": {
+ "additionalProperties": true,
+ "description": "Отказ: code (напр. empty_query)",
+ "type": "object"
+ },
+ "results": {
+ "description": "Публичные проекции найденных юрлиц",
+ "items": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "search_backend": {
+ "description": "Каким механизмом выполнен поиск",
+ "type": "string"
+ }
+}Output schema / titleRemoved value: -"search_companiesDictOutput"check_counterpartylookup_companysearch_companiesLive data from 80+ official national company registries. Unmodified. For KYB and due diligence.
Open public procurements of Belarus: search by words or customer UNP, source link for each.
Polish business register (REGON / BIR1.1) — resolve any Polish company by NIP, REGON or KRS number…
Company search and enrichment from official business registers in 200+ countries.
Add one secure layer between your agents and this server.