Compabase

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

Name	Required	Description
`krs`	No	KRS registry number (10 digits, zero-padded, e.g. '0000028860').
`nip`	No	NIP tax number (10 digits, no dashes).
`pkd`	No	Primary PKD code prefix, e.g. '46.90.Z' or '46'.
`city`	No	City name — KRS records use uppercase, e.g. 'WARSZAWA', 'POZNAŃ'.
`name`	No	Company name fragment (case-insensitive). Matches display name and full KRS name; legal-form suffixes like 'sp. z o.o.' are ignored.
`year`	No	Filter 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.
`limit`	No	Max results (default: 10, max: 50).
`county`	No	County / powiat (lowercase).
`fields`	No	Response 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.
`region`	No	Voivodeship (lowercase), e.g. 'mazowieckie', 'wielkopolskie'.
`all_pkd`	No	Match any PKD code in the company's activity list (not just primary).
`sort_by`	No	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).
`currency`	No	Currency for monetary filters. Default: pln.
`sort_dir`	No	Sort direction (default: desc).
`has_email`	No	true = only companies with email on record. Matching rows include contacts.email. Omit otherwise.
`is_active`	No	true = active only, false = closed only. Omit for all.
`ebitda_max`	No	Maximum EBITDA.
`ebitda_min`	No	Minimum EBITDA.
`legal_form`	No	Legal form fragment, e.g. 'spółka z o.o.' or 'akcyjna'.
`profit_max`	No	Maximum net profit.
`profit_min`	No	Minimum net profit.
`capital_max`	No	Maximum share capital.
`capital_min`	No	Minimum share capital.
`has_website`	No	true = only companies with website on record. Matching rows include contacts.website. Omit otherwise.
`postal_code`	No	Postal code prefix, e.g. '00-9' or '61-'.
`revenue_max`	No	Maximum total revenue.
`revenue_min`	No	Minimum total revenue.
`total_assets_max`	No	Maximum total assets.
`total_assets_min`	No	Minimum total assets.
`estimated_value_max`	No	Maximum Ohlson estimated equity value in PLN.
`estimated_value_min`	No	Minimum Ohlson estimated equity value in PLN.
`profit_operating_max`	No	Maximum operating profit (PLN). Omit if unused.
`profit_operating_min`	No	Minimum operating profit (PLN). Negative allowed. Omit if unused.
`registration_date_max`	No	Latest KRS registration date, YYYY-MM-DD (inclusive).
`registration_date_min`	No	Earliest 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.

Changed2 schema fields changedOct 12, 2026

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"
+]

Changed4 schema fields changedOct 7, 2026

addedInput schema / properties / registration_date_max

Added value: +{
+  "description": "Latest KRS registration date, YYYY-MM-DD (inclusive).",
+  "type": "string"
+}

addedInput schema / properties / registration_date_min

Added value: +{
+  "description": "Earliest KRS registration date, YYYY-MM-DD (inclusive). For newly registered companies use today's date for both registration_date_min and registration_date_max.",
+  "type": "string"
+}

changedInput schema / properties / sort_by / description

Previous value: -"Sort field (default: revenue_total)."New value: +"Sort field (default: revenue_total). registration_date + sort_dir=desc lists the newest registrations first."

changedInput schema / properties / sort_by / enum

Previous value: -[
-  "revenue_total",
-  "profit_net",
-  "total_assets",
-  "profit_operating",
-  "ebitda",
-  "capital_total",
-  "estimated_value"
-]New value: +[
+  "revenue_total",
+  "profit_net",
+  "total_assets",
+  "profit_operating",
+  "ebitda",
+  "capital_total",
+  "estimated_value",
+  "registration_date"
+]

First observedOct 2, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare the read-only, idempotent, non-destructive profile, so the safety burden is covered. The description goes further by disclosing RODO-gated hiding of JDG entities without a public email, the response-size tradeoff per fields value, and the sparse-result `hint` behavior — real behavioral context an agent cannot get from the annotations. Minor gap: nothing about pagination/offset behavior despite the default limit of 10.

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?

Front-loaded with purpose, then data-coverage caveats, then the response-shape options, then use cases and the export_companies exclusion. It is a dense paragraph with essentially no filler, though the fields recap partially duplicates the schema's own enum descriptions.

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 35-parameter read-only tool with no output schema, the description compensates well by describing exactly what each fields mode returns and flagging the `full` size risk. The only real omission is pagination/result-windowing behavior, which the limit cap hints at but the description never explains.

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 description coverage is 100%, so the schema already documents all 35 parameters including enums and defaults, which sets the baseline at 3. The description reinforces the fields enum values and default, but largely restates what the schema says (the cross-parameter tips for sort_by/revenue_growth_pct also appear in the schema), so it adds only marginal semantic value.

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 (search/filter) and resource (Polish KRS companies) and immediately draws the boundary against the CEIDG/JDG register that lives in the same database. It also names the sibling it should not be confused with (export_companies), so an agent can separate it from the rest of the company_* family without opening schemas.

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?

Explicitly enumerates the intended use cases (rankings, sector filters, city/county/region browsing, name search, NIP/KRS lookup) and adds a concrete when-not with an alternative: 'Do not call export_companies just to get a handful of emails or phones.' Both the positive routing and the exclusion are stated, not implied.

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

All Compabase tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Search Polish Companies

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources