Skip to main content
Glama

Get current KRS extract

get_company
Read-only

Fetch the current official KRS extract for a Polish company using its 1–10 digit KRS number, returning identity, address, board, capital, and PKD details as markdown.

Instructions

Fetch the CURRENT (aktualny) official extract of a Polish company from the KRS registry by its 1-10 digit KRS number. Returns identity, address, board, capital and PKD as markdown.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "krs": "<krs>"
    },
    "name": "get_company"
  }
}

Input Schema

NameRequiredDescriptionDefault
krsYesKRS number, 1-10 digits (padding is applied automatically).
rejestrNoRegistry: P = entrepreneurs, S = associations.P

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true). The description adds value beyond them by disclosing the output format (markdown), the returned sections (identity, address, board, capital, PKD), that only the current rather than historical state is returned, and that zero-padding of the KRS number is handled automatically.

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?

Two dense sentences with zero filler; the verb, registry qualifier, keying parameter, and output shape all arrive in the first pass before any elaboration.

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

Completeness4/5

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

For a two-parameter read tool with no output schema, the description covers input, behavior (current-only), and return content and format. Minor gaps remain: language of the returned extract, and whether rejestr=S changes the returned section set.

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

Parameters3/5

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

Schema coverage is 100%, with both krs (pattern and padding note) and rejestr (P/S enum with default) fully documented in the schema. The description restates the 1-10 digit KRS constraint but adds nothing about the rejestr parameter, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource: fetch the CURRENT official KRS extract for a Polish company, keyed by KRS number, and lists the returned data domains (identity, address, board, capital, PKD). The capitalized 'CURRENT (aktualny)' implicitly differentiates it from get_company_full, but no sibling is named, so the distinction is left to inference.

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?

Usage is implied: you need a company's current registry extract and you have its KRS number. There is no explicit when-to-use / when-not-to-use guidance and no routing to get_company_full (historical/full extract) or search_companies (when you don't have a KRS number).

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