Polish public procurement for AI agents: BZP and TED tenders, awards, buyers and contractors.
Scored across 9 tools
The get_company_* tools each target a distinct data source (EU funds vs EU grants vs EU tenders vs SUDOP aid vs BZP tenders), and the descriptions clearly differentiate them. However, eu_funds vs eu_grants and eu_tenders vs public_tenders are close enough that a careless agent could misselect, requiring careful reading of the descriptions.
All tool names follow a strict snake_case verb_noun or verb_noun_qualifier pattern (get_company, get_company_eu_funds, search_companies, search_tenders). The prefix structure (get_company_*) groups related lookups predictably.
Nine tools is well-scoped for a company-and-tenders research server. Each tool earns its place covering a distinct data source or search surface, with no redundancy.
Core company lookup and tender search are covered, but the descriptions reference get_financials (for earlier-year statements) and export_companies, neither of which exists in this tool set, creating dead ends. There is also no tool to fetch a single tender by ID or full notice detail, only search.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and non-open-world, so the safety profile is covered. The description adds the data scope (what the profile contains) but says nothing about lookup failure, ambiguous name matches, rate limits, or the fact that at least one identifier is effectively needed despite zero required parameters.
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?
Two sentences, both earning their place: the first front-loads the returned fields, the second handles identification and routes to the fallback tool. No filler or repetition.
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 usefully enumerates the profile contents, which is exactly what the agent needs to judge whether this tool returns what it wants. The gap is that zero required parameters are declared while the prose implies one identifier is mandatory, and no failure behavior is described.
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 baseline is 3. The description's note on identifying a company by name, KRS or NIP largely restates the schema, which already labels 'name' as the fallback when KRS/NIP is unknown; no extra format, priority, or conflict-handling detail is added.
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?
The description states a specific verb plus resource ('get the registry profile of one Polish company') and enumerates the fields returned (legal form, PKD, share capital, representation rules, VAT status, financials). It also scopes itself away from the EU-funds/grants/tenders siblings by framing the output as a registry profile rather than a program-specific dataset.
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?
Explicitly names an alternative and the condition for it: 'For earlier years or full statements use get_financials.' It also gives the three acceptable lookup keys, which tells the agent how the tool is invoked. It stops short of saying when NOT to use this versus the get_company_eu_* siblings, so a 5 is not warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get European Funds (Fundusze Europejskie) projects for a company — official MFiPR lists, EU co-financing, programme and dates. Keyed by NIP. Identify company by name, KRS, or NIP. Cohesion/shared-management funds; not TED procurement, not FTS Commission grants, and not SUDOP state aid.
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, idempotent=true, destructive=false, and openWorld=false, so the safety profile is covered. The description adds genuine context: the data source (official MFiPR lists) and the nature of returns (EU co-financing, programme, dates). It does not mention pagination or result limits, but for a read-only lookup the added context is solid.
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-loaded and dense: purpose, source, key, and exclusions all appear immediately. There is mild redundancy between 'Keyed by NIP' and 'Identify company by name, KRS, or NIP,' but every clause carries routing or scoping value.
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 does some work describing returned content (co-financing, programme, dates). Combined with annotations covering the safety profile and full schema coverage of inputs, an agent has enough to invoke correctly. A note on result volume or an identifier requirement would round it out.
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 coverage is 100%, so the baseline is 3. The description goes slightly further by stating the lookup is 'Keyed by NIP' and that name/KRS are alternatives, implying NIP is the preferred identifier — prioritization not expressed in the schema. This adds useful meaning beyond the per-parameter descriptions.
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 ('European Funds projects for a company'), names the official source (MFiPR lists), and explicitly carves out the domain against siblings: 'not TED procurement, not FTS Commission grants, and not SUDOP state aid.' An agent can distinguish this from get_company_eu_tenders, get_company_public_aid, and others 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly frames when to use it (Polish cohesion/shared-management EU funds) and, more importantly, when not to — the three exclusions map onto sibling tools covering tenders, Commission grants, and state aid. This is exactly the routing information an agent needs to pick among the eight siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get European Commission grants awarded directly to a Polish company (Horizon Europe, LIFE, Erasmus+ and other EU programmes from the EU Financial Transparency System). Identify the company by name, KRS number or company tax number (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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the underlying data provenance (EU Financial Transparency System) and the scope limitation ('awarded directly', Polish companies only). It still says nothing about data freshness or result completeness.
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?
Two tight sentences, front-loaded with what is fetched and scoped to the data source. The closing sentence blends identification guidance into the description rather than the schema but is not wasteful. No padding or repetition.
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?
For a read-only lookup with no output schema, the description covers the query side adequately but says nothing about what a grant record contains (amount, year, programme, awardee role) or result volume/pagination. An agent can call it correctly, but cannot anticipate the shape or limits of the response.
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 coverage is 100% and each parameter already documents its meaning and format (10 digits, 10-digit NIP, fallback for name). The description restates the three identifiers and adds the priority ordering (KRS/NIP preferred, name when unknown is only in the schema), which is minor added value over structured data. Baseline 3 applies.
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 European Commission grants awarded directly to a Polish company') and names the data source (EU Financial Transparency System) plus covered programmes (Horizon Europe, LIFE, Erasmus+). This distinguishes it reasonably from siblings like get_company_eu_tenders and get_company_public_aid, though it never explicitly contrasts itself with get_company_eu_funds.
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 description explains how to identify the company (name, KRS, NIP) but gives no guidance on when to use this tool versus get_company_eu_funds, get_company_eu_tenders, or get_company_public_aid. No prerequisites, exclusions, or alternative routing are provided despite many closely related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get TED EU-threshold public procurement — full awards as contractor and notices as buyer. Keyed by NIP. 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's main addition is what the data actually contains ('full awards as contractor and notices as buyer'), which is genuinely useful scope context. It discloses nothing about permissions, coverage window, or result volume, so it stays at baseline.
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?
Two short sentences with the purpose front-loaded and zero filler. It loses a point for mild redundancy between 'Keyed by NIP' and the following identification clause, which partly restate the same identifier guidance.
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?
All three params are optional, there is no output schema, and the description never indicates what a caller receives or whether results are limited/paginated. It is adequate for a lookup tool but leaves an agent guessing about result shape in a family of eight sibling company-data tools.
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 carries parameter meaning; the baseline is 3. The description's 'Keyed by NIP' plus 'Identify company by name, KRS, or NIP' adds only a hint about precedence, and slightly muddies it by implying NIP is the key while the schema treats name as the fallback for an unknown KRS/NIP.
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 TED EU-threshold public procurement') and adds scope detail, distinguishing it from the domestic sibling get_company_public_tenders via the explicit 'EU-threshold' qualifier. It never names a sibling outright, but the distinction is inferable without opening the schema.
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 description gives no when-to-use or when-not-to-use guidance and does not route the agent to or away from any sibling (public_tenders, eu_funds, eu_grants). 'Identify company by name, KRS, or NIP' is parameter selection advice, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get SUDOP public aid / grants for a company — full case list with amounts, grantor, measure, purpose. Keyed by NIP. 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds useful substance on its own: the response is a 'full case list' with named fields, which is valuable since there is no output schema. It omits pagination or result-size behavior, keeping it out of the top band.
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?
Two compact sentences with the core purpose and returned fields front-loaded, followed by the keying/identification note. Nothing is padded, though 'Keyed by NIP' followed immediately by 'Identify company by name, KRS, or NIP' is mildly redundant.
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?
For a three-parameter lookup with no required fields and no output schema, the description supplies the essential shape of the result set (case list with amounts, grantor, measure, purpose) and how to identify the company. Only pagination/limits and sibling routing are 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 all three parameters (krs, nip, name) are documented in the schema and the baseline is 3. The description adds only the identification strategy and the 'keyed by NIP' note, which largely restates what the schema already conveys.
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?
The description states a specific verb and resource ('Get SUDOP public aid / grants for a company') and enumerates the returned content (amounts, grantor, measure, purpose), so the agent knows exactly what data it gets. The 'SUDOP' and 'public aid' framing separates it from the EU-funding siblings, though it stops short of explicitly distinguishing itself from get_company_eu_grants.
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?
Usage is implied — fetch Polish public aid records for one company — and the description notes that the company can be located by name, KRS, or NIP. There is no explicit when-to-use versus when-not, and no pointer to a sibling such as get_company_eu_grants for EU-sourced aid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get BZP public procurement data — full awards as contractor and notices as buyer, with award values. Keyed by NIP. 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds content-level context (contractor awards, buyer notices, award values) but says nothing about pagination, result limits, or how the 'Keyed by NIP' resolution behaves when only a name is supplied.
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?
Two compact sentences, no filler, with the data scope front-loaded ahead of the identification note. 'Keyed by NIP' is slightly terse and could confuse an agent given that name and KRS are also accepted identifiers.
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?
For a read-only tool with no output schema, the description usefully sketches what comes back (awards, notices, values). The notable gap is that zero parameters are required, yet the description never states that at least one identifier must be supplied, leaving an agent guessing about the no-argument case.
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 all three parameters (krs, nip, name) are already documented, including that name is the fallback. The description simply restates the same three identifiers without adding format, precedence, or required-count guidance, so it lands at the baseline for a fully covered schema.
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 a well-scoped resource (BZP public procurement data), and details the two data shapes returned ('full awards as contractor and notices as buyer, with award values'). The 'BZP' qualifier implicitly separates it from EU-oriented siblings, but the description never names get_company_eu_tenders, so the differentiation is inferred rather than explicit.
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?
Usage is implied by the data scope (Polish public procurement), and 'Identify company by name, KRS, or NIP' hints at the identification workflow. However, there is no explicit when-to-use, no when-not-to-use, and no crossover guidance versus get_company_eu_tenders, which overlaps in the tenders domain.
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. |
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.
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.
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.
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.
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.
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.
Search Polish public procurement notices from BZP (national) and TED (EU): open calls with deadlines or awarded contracts. Filter by industry (it, construction, medicine, or a 2-digit CPV division such as 72), region, buyer city, kind and value. Returns title, buyer, CPV codes, publication date, deadline, estimated or awarded value and a link to the notice.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Buyer city, e.g. Warszawa. | |
| kind | No | Contract type. | |
| page | No | Result page (20 per page). | |
| region | No | Voivodeship of the buyer. | |
| source | No | national (BZP) or eu (TED). Default: both. | |
| status | No | open (default) or awarded notices. | |
| currency | No | Currency for value filters and output. Default PLN. | |
| industry | No | it, construction, medicine, or a 2-digit CPV division code (e.g. 72, 45, 33). | |
| value_max | No | Maximum estimated/awarded value. | |
| value_min | No | Minimum estimated/awarded value. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the dual-source/dual-status scope and the field set of the result, but says nothing about rate limits, ordering, or error behavior; modest added value over annotations.
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?
Two sentences, no filler: the first establishes sources and scope, the second covers filters and return fields. The most decision-relevant information (what it searches) is front-loaded.
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 10 parameters, no output schema, and 0 required params, the description compensates by enumerating the returned fields (title, buyer, CPV codes, dates, value, link). It leaves pagination/ordering behavior implicit, but the schema supplies the 20-per-page detail, so an agent has enough to call it correctly.
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 every parameter, including the industry alias/CPV-division convention and the defaults for status, source and currency. The description only restates the filter axes in prose, adding no syntax or format detail beyond the schema.
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 (Search) plus resource (Polish public procurement notices) and names the two sources it spans (BZP national, TED EU). It also distinguishes scope as 'open calls with deadlines or awarded contracts', which separates it from the per-company siblings like get_company_public_tenders.
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?
Gives clear context on what the tool covers and enumerates the filter dimensions (industry, region, buyer city, kind, value), which tells the agent when this tool fits. It stops short of explicitly routing between this and the company-scoped tender siblings or stating exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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"
+]get_companyget_company_eu_fundsget_company_eu_grantsget_company_eu_tendersget_company_public_aidget_company_public_tendersget_usagesearch_companiessearch_tendersEU public tenders for AI agents: open tenders, award history, competitors and bid intelligence.
Public tenders (EU TED, Armenia) for AI agents: search, details, watchlists, alerts.
Government tender search for AI agents. UK, EU and US procurement opportunities.
Official Polish registers for agents: tenders, EV charging, cars, permits, land, health, companies.
Add one secure layer between your agents and this server.