Skip to main content
Glama

SiteCheck Company Records

Gov Krs Poland

gov_krs_poland
Read-only

Polish business register (KRS) current extract by KRS number: company name, legal form, NIP tax number, registered seat and address, and register dates. Current extract only; a KRS number that is not registered returns 404. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
krsYesKRS number, 10 digits, e.g. 0000500000

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
krsNo
nipNo
nameNo
sourceNo
addressNo
checkedAtNo
legalFormNo
registeredOnNo
lastEntryDateNo
registeredSeatNo
extractStateDateNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses important behavior: it is a current extract only, invalid KRS numbers return 404, pricing is $0.002 USDC per successful call, payment uses x402 on Base/Solana/Arc, and failed calls are not charged. This is unusually transparent for a paid lookup tool.

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

Conciseness5/5

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

The description is front-loaded with the core lookup purpose and returned data, then efficiently adds the current-extract limitation, 404 behavior, and pricing. Every sentence carries operational value, with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single required parameter, full schema coverage, read-only/open-world annotations, and an output schema, the description provides enough context to call the tool correctly. It covers purpose, scope, error behavior, and payment model without needing to explain return-value structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully describes the single krs parameter as 10 digits with an example, so the schema coverage is 100%. The description reinforces that lookup is by KRS number but adds no extra syntax or format details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: extracting a current KRS extract by KRS number. It also lists the returned fields and identifies the country/register, which distinguishes it from sibling country business-registry tools such as gov_ares_czech or gov_finland_prh.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies usage via 'Polish business register (KRS)' and 'current extract only', and it warns that unregistered KRS numbers return 404. However, it does not explicitly compare this tool with alternatives or name when a different sibling registry should be used.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources