Skip to main content
Glama

Compabase

by io.github.ContentWriterco
OverviewDiscussionsAdmin

Count Polish Companies

count_companies
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
krsNoKRS registry number.
nipNoNIP tax number.
pkdNoPrimary PKD code prefix, e.g. '46.90.Z' or '46'.
cityNoCity name — KRS uses uppercase.
nameNoCompany name fragment (case-insensitive). Matches display name and full KRS name; legal-form suffixes like 'sp. z o.o.' are ignored.
yearNoFilter 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.
countyNoCounty / powiat (lowercase).
regionNoVoivodeship (lowercase).
all_pkdNoMatch any PKD code in the company's activity list (not just primary).
has_emailNotrue = only companies with email on record. Omit otherwise.
is_activeNotrue = active only, false = closed only. Omit for all.
ebitda_maxNoMaximum EBITDA in PLN.
ebitda_minNoMinimum EBITDA in PLN.
legal_formNoLegal form fragment.
profit_maxNoMaximum net profit in PLN.
profit_minNoMinimum net profit in PLN.
capital_maxNoMaximum share capital in PLN.
capital_minNoMinimum share capital in PLN.
has_websiteNotrue = only companies with website on record. Omit otherwise.
revenue_maxNoMaximum total revenue in PLN.
revenue_minNoMinimum total revenue in PLN.
total_assets_maxNoMaximum total assets in PLN.
total_assets_minNoMinimum total assets in PLN.
estimated_value_maxNoMaximum Ohlson estimated equity value in PLN.
estimated_value_minNoMinimum Ohlson estimated equity value in PLN.
profit_operating_maxNoMaximum operating profit in PLN.
profit_operating_minNoMinimum operating profit in PLN.
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
    • 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"
+}
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely non-obvious context: JDG companies are excluded, CEIDG data lives elsewhere and is RODO-gated, and sparse/zero counts in JDG-heavy PKDs come back with a `hint`. That hint signal is valuable for interpreting an odd result.

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?

Three tight sentences, front-loaded with purpose and return shape before the caveats. The jargon ('Compabase', 'RODO-gated') costs a little clarity but does not pad the text.

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?

With no output schema, the description usefully discloses the return shape (a single number, occasionally with a `hint`). It also explains the main exclusion that would confuse an agent. A one-line indication of what the filter set covers would close the remaining gap for a 29-parameter tool.

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%, so all 29 parameters are already documented, including the nuanced `year` and `registration_date_min` usage notes. The description adds nothing per-parameter, so the baseline 3 applies; it compensates only at the aggregate level by calling out that filters are matched against KRS 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 (count) and resource (KRS companies) and immediately delimits scope by declaring it returns a single number, not a list. This cleanly separates it from search_companies and export_companies, which an agent can now distinguish without opening either schema.

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

Usage Guidelines4/5

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

The 'returns a single number — no company list' clause implicitly routes the agent to a listing tool when actual records are needed, and the JDG exclusion tells the agent when the count will not be authoritative. It stops short of explicitly naming the alternative tool or the exact condition for choosing count over search.

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

All Compabase toolsInspect
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.

Resources