Belarusian companies by UNP: state registry answers with source and sha256 for every fact.
Scored across 3 tools
The three tools are largely distinct: live registry check vs. cached card lookup vs. search. Some confusion is possible between check_counterparty and lookup_company since both return company status/details, but the live/collected distinction is clearly described.
All tool names follow a consistent verb_noun snake_case pattern: check_counterparty, lookup_company, search_companies. The pattern is predictable and easy for an agent to infer.
Three tools is a well-scoped set for a business registry server: search, cached detail lookup, and live verification. Each tool has a clear purpose and none feel redundant or unnecessary.
The tool set covers the core registry workflow: finding an entity, retrieving detailed cached information, and getting a live official status check. For a read-only registry domain, this is a complete and practical surface.
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 | ||
| name | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, and open-world behavior. The description adds genuinely useful context beyond those: rate-limiting, live/real-time response ('right now'), and the tri-state existence outcome (да | нет | не_установлено).
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 lean and front-loaded: the live-registry behavior and status categories appear first, followed by the optional `name` usage. The trailing Russian sentence repeats the registry-live idea, adding minor redundancy without hurting scannability.
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 and strong annotations, the description supplies the missing operational details: live behavior, speed, rate limits, status categories, and the role of `name`. It still lacks explicit UNP format and sibling routing, so it is not fully complete.
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 0%, so the description must carry parameter meaning. It usefully explains that `name` is the document-derived value used for a name-match verdict, but it never defines `unp` or its format beyond the registry context and the schema title, leaving a real gap for the required 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 clearly identifies the tool as a live registry lookup for Belarusian payers and enumerates the returned data (existence status, address, registration date, tax office, bankruptcy cases, etc.). It does not explicitly contrast with sibling tools lookup_company and search_companies, but the 'right now' live-registry framing and concrete fields make the purpose unambiguous.
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 a clear usage context: pass `name` from your documents to get a name-match verdict, and notes the operation is fast but rate-limited. It does not explicitly say when to use this tool instead of the siblings, so it misses the top score.
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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive. The description adds meaningful behavioral detail beyond these: no registry call is made, responses carry provenance and a sha256 hash, and withheld fields are explained with reasons. 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 the core purpose and information-dense output details. The trailing Russian sentence largely restates the English and adds slight redundancy, but overall the length is appropriate and free of 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?
For a simple one-parameter read-only lookup with an output schema, the description covers the stored nature, result contents, provenance, and speed. Nothing critical is missing for an agent to invoke 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?
The schema defines only the unp parameter with no description, so the 9-digit format stated in the tool description is essential and compensates for 0% schema coverage. It does not discuss validation edge cases, but for a single required parameter this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a collected public card for a Belarusian business entity by 9-digit UNP and enumerates the contained fields. It is specific about the resource and scope, though it stops short of explicitly naming sibling tools to differentiate them.
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 clear context: use this when you have a UNP and need a stored public card without making a live registry call. It does not explicitly say when to prefer check_counterparty or search_companies, but the stored/no-registry-call framing makes the intended use case evident.
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 | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the openWorldHint annotation. The annotation sets openWorldHint=false (closed world), but the description explicitly states 'Absence here is not absence in the state registry,' indicating the tool's data is incomplete relative to the registry. This is a serious inconsistency that undermines the annotation's reliability.
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 concise and front-loaded with the core purpose. The English text is efficient, but the Russian translation is redundant and adds no information, slightly increasing length without benefit.
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 simple two-parameter search tool with an output schema, the description covers key aspects: scope (collected entities), exclusion (sole proprietors), and the caveat about absence. It omits details on limit behavior, but the output schema fills return structure. The openWorldHint contradiction is the main gap.
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 description explains that the query parameter accepts a name fragment or UNP, adding meaning beyond the schema which has no descriptions. However, the limit parameter is not mentioned, and the description doesn't clarify input formats or constraints. With 0% schema coverage, the description partially compensates but leaves 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?
The description clearly states the tool's action (search) and resource (collected Belarusian legal entities) and specifies the search criteria (name fragment or UNP). It distinguishes itself from sibling tools by emphasizing search over direct lookup, and the title reinforces the purpose.
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 usage for searching entities by name or UNP but provides no explicit guidance on when to prefer this over check_counterparty or lookup_company. There are no exclusions or alternative routing, leaving the agent to infer the right context.
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.
check_counterpartylookup_companysearch_companiesLive data from 27 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.
UK company register lookups plus US, EU and UN sanctions screening. Every answer cites source.
UBO, sanctions & ownership graph. 23 tools, 130.7M entities, 31 registries.
Add one secure layer between your agents and this server.
