Skip to main content
Glama

Search Polish Companies

search_companies
Read-onlyIdempotent

Search and filter Polish KRS companies (spółki). Compabase also holds the full CEIDG/JDG register; this tool does not browse JDG — those without a public contact email are hidden because of RODO. Default fields=summary returns a compact row (name, NIP, KRS, location, PKD, latest financials, email/phone/website) — small enough for MCP clients. fields=contacts_only is name/NIP/KRS/city/email/phone/website only. fields=full returns every company_search column plus contacts and may exceed client size limits. Use for rankings, sector filters, city/county/region browsing, name search, or NIP/KRS lookup. When a PKD is mostly JDG, a sparse result includes a hint (full CEIDG is in the database; listing is RODO-gated). Do not call export_companies just to get a handful of emails or phones.

Input Schema

NameRequiredDescriptionDefault
krsNoKRS number of the company in the Polish National Court Register (10 digits).
nipNoPolish company tax number (NIP) of the business, 10 digits.
pkdNoPrimary PKD code prefix, e.g. '46.90.Z' or '46'.
cityNoCity name — KRS records use uppercase, e.g. 'WARSZAWA', 'POZNAŃ'.
nameNoCompany name, used when the KRS or NIP is not known.
yearNoFilter to companies whose latest financial_period_to falls within this calendar year (e.g. 2024). Use only for sector/ranking browse — omit when looking up a company by name, KRS, or NIP.
limitNoMax results (default: 10, max: 50).
countyNoCounty / powiat (lowercase).
fieldsNoResponse size. Default summary (name, NIP, KRS, location, PKD, latest financials, email/phone/website). contacts_only: name, NIP, KRS, city, email, phone, website. full: every company_search column plus contacts — often too large for MCP clients.
regionNoVoivodeship (lowercase), e.g. 'mazowieckie', 'wielkopolskie'.
all_pkdNoMatch any PKD code in the company's activity list (not just primary).
sort_byNoSort field (default: revenue_total). registration_date + sort_dir=desc lists the newest registrations first. revenue_growth_pct + sort_dir=desc lists the fastest-growing companies (y/y revenue growth from KRS financial statements; combine with revenue_min to skip small companies).
currencyNoCurrency for monetary filters. Default: pln.
sort_dirNoSort direction (default: desc).
has_emailNotrue = only companies with email on record. Matching rows include contacts.email. Omit otherwise.
is_activeNotrue = active only, false = closed only. Omit for all.
ebitda_maxNoMaximum EBITDA.
ebitda_minNoMinimum EBITDA.
legal_formNoLegal form fragment, e.g. 'spółka z o.o.' or 'akcyjna'.
profit_maxNoMaximum net profit.
profit_minNoMinimum net profit.
capital_maxNoMaximum share capital.
capital_minNoMinimum share capital.
has_websiteNotrue = only companies with website on record. Matching rows include contacts.website. Omit otherwise.
postal_codeNoPostal code prefix, e.g. '00-9' or '61-'.
revenue_maxNoMaximum total revenue.
revenue_minNoMinimum total revenue.
total_assets_maxNoMaximum total assets.
total_assets_minNoMinimum total assets.
estimated_value_maxNoMaximum Ohlson estimated equity value in PLN.
estimated_value_minNoMinimum Ohlson estimated equity value in PLN.
profit_operating_maxNoMaximum operating profit (PLN). Omit if unused.
profit_operating_minNoMinimum operating profit (PLN). Negative allowed. Omit if unused.
registration_date_maxNoLatest KRS registration date, YYYY-MM-DD (inclusive).
registration_date_minNoEarliest KRS registration date, YYYY-MM-DD (inclusive). For newly registered companies use today's date for both registration_date_min and registration_date_max.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / sort_by / description
      Previous value: -"Sort field (default: revenue_total). registration_date + sort_dir=desc lists the newest registrations first."New value: +"Sort field (default: revenue_total). registration_date + sort_dir=desc lists the newest registrations first. revenue_growth_pct + sort_dir=desc lists the fastest-growing companies (y/y revenue growth from KRS financial statements; combine with revenue_min to skip small companies)."
    • changedInput schema / properties / sort_by / enum
      Previous value: -[
      -  "revenue_total",
      -  "profit_net",
      -  "total_assets",
      -  "profit_operating",
      -  "ebitda",
      -  "capital_total",
      -  "estimated_value",
      -  "registration_date"
      -]New value: +[
      +  "revenue_total",
      +  "profit_net",
      +  "total_assets",
      +  "profit_operating",
      +  "ebitda",
      +  "capital_total",
      +  "estimated_value",
      +  "registration_date",
      +  "revenue_growth_pct"
      +]
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them: the RODO gating that hides companies without a public email, the sparse-result `hint` behavior, and the client-size risk of fields=full. That is meaningful operational context the annotations cannot convey.

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

Conciseness4/5

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

Dense but front-loaded: purpose, then scope exclusions, then field modes, then use cases, then the anti-pattern. Every sentence carries information, though the field-mode details partially duplicate the enum descriptions in the schema.

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?

For a 35-param tool with no output schema, the description supplies the return-shape semantics for each fields mode, the RODO/JDG limit on result coverage, and the hint signal on sparse results — everything an agent needs to interpret and size its calls.

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

Parameters4/5

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

Schema coverage is 100% across 35 params, so the baseline is 3, but the description adds genuine meaning: the three fields modes and their exact contents, and combination recipes like registration_date + sort_dir=desc for newest registrations and revenue_growth_pct + revenue_min for fast-growing companies.

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?

States a specific verb+resource ('Search and filter Polish KRS companies') and immediately scopes what it does not cover (JDG/CEIDG browsing). An agent can distinguish it from get_company and export_companies without opening a schema.

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

Usage Guidelines5/5

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

Enumerates concrete use cases (rankings, sector filters, city/county/region browsing, name search, NIP/KRS lookup) and names the anti-pattern explicitly: 'Do not call export_companies just to get a handful of emails or phones.' It also flags the JDG exclusion, so the agent knows when to look elsewhere.

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.