Polish company financial statements for AI agents: revenue, profit, assets, rankings, benchmarks.
Score is being calculated.
Count KRS companies matching given filters. Returns a single number — no company list. Does not count JDG in this tool (full CEIDG is in Compabase; listing is RODO-gated). Sparse or zero counts in JDG-dominated PKDs include a hint.
| Name | Required | Description | Default |
|---|---|---|---|
| krs | No | KRS number of the company in the Polish National Court Register (10 digits). | |
| nip | No | Polish company tax number (NIP) of the business, 10 digits. | |
| pkd | No | Primary PKD code prefix, e.g. '46.90.Z' or '46'. | |
| city | No | City name — KRS uses uppercase. | |
| name | No | Company name, used when the KRS or NIP is not known. | |
| year | No | Filter to companies whose latest financial_period_to falls within this calendar year. Use only for sector/ranking browse — omit when looking up a company by name, KRS, or NIP. | |
| county | No | County / powiat (lowercase). | |
| region | No | Voivodeship (lowercase). | |
| all_pkd | No | Match any PKD code in the company's activity list (not just primary). | |
| has_email | No | true = only companies with email on record. Omit otherwise. | |
| is_active | No | true = active only, false = closed only. Omit for all. | |
| ebitda_max | No | Maximum EBITDA in PLN. | |
| ebitda_min | No | Minimum EBITDA in PLN. | |
| legal_form | No | Legal form fragment. | |
| profit_max | No | Maximum net profit in PLN. | |
| profit_min | No | Minimum net profit in PLN. | |
| capital_max | No | Maximum share capital in PLN. | |
| capital_min | No | Minimum share capital in PLN. | |
| has_website | No | true = only companies with website on record. Omit otherwise. | |
| revenue_max | No | Maximum total revenue in PLN. | |
| revenue_min | No | Minimum total revenue in PLN. | |
| total_assets_max | No | Maximum total assets in PLN. | |
| total_assets_min | No | Minimum total assets in PLN. | |
| 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 in PLN. | |
| profit_operating_min | No | Minimum operating profit in PLN. | |
| 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. |
Get the registry profile of one Polish company: name, legal form, address, industry (PKD), share capital, representation rules, recent registry changes, VAT status and headline financials for the latest filed period. Identify the company by name, KRS number or company tax number (NIP). For earlier years or full statements use get_financials.
| Name | Required | Description | Default |
|---|---|---|---|
| krs | No | KRS number of the company in the Polish National Court Register (10 digits). | |
| nip | No | Polish company tax number (NIP) of the business, 10 digits. | |
| name | No | Company name, used when the KRS or NIP is not known. |
Get a company's revenue rank positions within its industry (PKD), region (voivodeship), and all of Poland. Returns rows from company_financial_rankings — one row per scope (pkd_full, pkd_division, pkd_section, region, country). Use for questions like: where does company X rank in Poland / its industry / its region?
| Name | Required | Description | Default |
|---|---|---|---|
| krs | No | KRS number of the company in the Polish National Court Register (10 digits). | |
| nip | No | Polish company tax number (NIP) of the business, 10 digits. | |
| name | No | Company name, used when the KRS or NIP is not known. | |
| scope_type | No | Optional. Filter to a single scope. Omit to get all scopes. |
Secured liabilities from the latest financial-statement notes (period ending 2025+): mortgages (hipoteki), registered / financial pledges (zastawy), transfers of ownership, assignments — with creditor, amount, secured debt, asset and land-register (KW) numbers. Keyed by KRS; null when nothing is disclosed.
| Name | Required | Description | Default |
|---|---|---|---|
| krs | No | KRS number of the company in the Polish National Court Register (10 digits). | |
| nip | No | Polish company tax number (NIP) of the business, 10 digits. | |
| name | No | Company name, used when the KRS or NIP is not known. |
Get full financial statement metrics per fiscal period — all entity_financial_metrics columns. Includes cash_and_equivalents, inventories, receivables, liabilities, equity, cost breakdown, revenue lines. Identify company by name, KRS, or NIP.
| Name | Required | Description | Default |
|---|---|---|---|
| krs | No | KRS number of the company in the Polish National Court Register (10 digits). | |
| nip | No | Polish company tax number (NIP) of the business, 10 digits. | |
| name | No | Company name, used when the KRS or NIP is not known. | |
| year_to | No | Latest fiscal year to include (e.g. 2023). | |
| year_from | No | Earliest fiscal year to include (e.g. 2019). |
Get precomputed aggregate financial statistics for a sector, region, PKD branch, or country. Returns median, p25/p75/p90, winsorized mean, mean, total, n_companies, min/max. Use for questions like: what is the median revenue / average profit / assets in industry X or region Y? Prefer median or winsor_mean over mean. cost_wages is PLN-only.
| Name | Required | Description | Default |
|---|---|---|---|
| metric | No | Financial metric. Omit to return all metrics. | |
| currency | No | Currency (default: PLN). cost_wages is PLN-only. | |
| dimension_key | No | Key for the dimension, e.g. 'PL', 'G', '46', '46.90.Z', 'mazowieckie'. Prefix match applied. | |
| dimension_type | No | Granularity: 'country'=Poland; 'pkd_section'=A–U; 'pkd_division'=2-digit; 'pkd_full'=full code; 'region'=voivodeship; etc. |
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). The description adds useful non-structured context: results are 'precomputed', the recommendation to prefer median/winsor_mean over mean, and the cost_wages PLN-only constraint. No gaps that would mislead.
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?
Front-loads the purpose, followed by the return set and usage examples. Efficient overall, though the inline list of returned statistics is dense; it earns its place given there is no output schema.
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 no output schema, the description compensates by enumerating the returned aggregates (median, p25/p75/p90, mean, total, n_companies, min/max), which is exactly what an agent needs. All parameters are documented in the schema, so nothing critical is missing.
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 100%, so the schema already documents metric, currency, dimension_key, and dimension_type with enums and the PLN-only note. The description echoes the cost_wages constraint and adds the 'prefer median' guidance, but adds little syntax beyond the schema. Baseline 3 is appropriate.
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?
States a specific verb and resource: 'Get precomputed aggregate financial statistics' for sectors/regions/PKD branches/countries. The word 'aggregate' implicitly distinguishes it from the company-level get_financials sibling, but it never names that alternative, so an agent must infer the boundary.
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?
Provides concrete example questions ('what is the median revenue / average profit / assets in industry X or region Y?') that clearly signal when to reach for this tool. It stops short of naming when-not-to-use or pointing to an alternative like get_financials for company-level data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current billing period usage and remaining quota — mcp_queries, api_requests, export_companies, ask_ai_credits, watchlist_companies. Includes limits and reset date.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds value beyond that by spelling out the exact metrics returned plus the inclusion of limits and reset date, which is the key behavioral context for a quota tool and is especially useful given there is no output schema.
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?
One front-loaded sentence naming the resource, then an em-dash list of metrics and a short clause on limits and reset date. No filler, and the highest-value information (usage + remaining quota) comes first.
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 no output schema, the description carries the return-value burden and does so by listing the metric keys, limits, and reset date. What remains missing is scope (which account/workspace the usage applies to) and the relationship to get_plan, both minor for a no-arg read tool.
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 tool takes zero parameters, so the baseline is 4. The description cannot add parameter meaning, and none is needed; the enumeration of metrics describes the response rather than inputs, which is a reasonable substitute.
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?
States a specific verb ('Get') and resource ('current billing period usage and remaining quota') and enumerates the five metric buckets returned. It is clear what the tool does, but it never differentiates itself from the related sibling get_plan, so an agent must infer the boundary between 'usage/quota' and 'plan'.
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 phrase 'current billing period' implies a reporting context, but there is no statement of when to call this versus get_plan, get_financials, or the key-listing tools, and no mention of prerequisites or account scope. Usage is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| krs | No | KRS number of the company in the Polish National Court Register (10 digits). | |
| nip | No | Polish company tax number (NIP) of the business, 10 digits. | |
| 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, used when the KRS or NIP is not known. | |
| 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. |
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
search_companies2 fields changedInput schema / properties / sort_by / descriptionPrevious 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)."Input schema / properties / sort_by / enumPrevious 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"
+]count_companiesget_companyget_company_rankingsget_company_secured_liabilitiesget_financial_statsget_financialsget_usagesearch_companies3M+ Polish companies (KRS, CEIDG): financials, people, rankings and public registries.
Polish company registry: 4.4M firms, KRS/REGON data, VAT white list checks, financial statements
Verified Polish open data for AI agents: debt, budget, 460 MPs, votings, judiciary search, RAG.
Polish public procurement for AI agents: BZP and TED tenders, awards, buyers and contractors.
Add one secure layer between your agents and this server.
