Skip to main content
Glama
Sign In

pl-firmy: Polish company check

by com.almmity.api
OverviewDiscussionsAdmin

Polish VAT white list (Biała lista)

check_vat_whitelist
Read-only

Query the Ministry of Finance VAT white list (wl-api.mf.gov.pl). Returns the full taxpayer card: name, NIP, VAT status, REGON, KRS, address, every account (groups of 4), registration/denial/removal/restoration dates with legal basis, representatives, authorized clerks, partners, virtual accounts, and the MF requestId (legal proof of the answer). decision is czynny, zwolniony, niezarejestrowany or not found. Pass nip, or nips (up to 30, one search/nips call) for a batch with progress. Optionally bank_account to verify that account against the NIP: result TAK or NIE plus a separate requestId (the 15 000 PLN proof). When both nip and bank_account are set, the top-level requestId is the account-check id and detail.requestId is the taxpayer-search id. Or pass regon, or bank_account alone to find the owner. Reads a public registry and does not change it. Callable without an API key, within the daily per-IP limit. Errors and the daily MF limit come back in Polish.

Input Schema

NameRequiredDescriptionDefault
nipNo
dateNoYYYY-MM-DD, default today (Europe/Warsaw). MF allows up to 5 years back.
nipsNoUp to 30 NIPs, checked with one MF search/nips request. Each entry has decision and the full card.
regonNo
bank_accountNo26-digit NRB or PL IBAN. With nip, verifies the account (TAK/NIE). Alone, finds the owner.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / bank_account / description
      Previous value: -"26-digit NRB or PL IBAN"New value: +"26-digit NRB or PL IBAN. With nip, verifies the account (TAK/NIE). Alone, finds the owner."
    • addedInput schema / properties / nips
      Added value: +{
+  "description": "Up to 30 NIPs, checked with one MF search/nips request. Each entry has decision and the full card.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 30,
+  "type": "array"
+}
  2. Changed2 schema fields changed
    • changedInput schema / properties / bank_account / description
      Previous value: -"26-digit NRB / PL IBAN"New value: +"26-digit NRB or PL IBAN"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {},
+  "type": "object"
+}
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: no API key required, a daily per-IP limit, the MF daily limit, errors returned in Polish, and the legal significance of requestId as proof of the answer (with the 15 000 PLN account-check proof). This is exactly the kind of operational and legal-behavior detail annotations cannot carry.

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 the purpose and registry endpoint, and every sentence carries real information. The single dense paragraph does cram several modes and the dual-requestId rule together, which slightly hurts readability but wastes nothing.

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 five-parameter, multi-mode read tool it covers access requirements, rate limits, error language, and result semantics, and even summarizes the return card despite an output schema existing. An agent has everything needed to pick a mode and interpret the response.

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

Parameters5/5

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

With only 60% schema coverage, the description compensates well: it explains nips as a single batch search/nips request, bank_account as either a TAK/NIE verification or a standalone owner lookup, and the tricky interaction where the top-level requestId becomes the account-check id while detail.requestId holds the taxpayer-search id. Only the date parameter's semantics are left entirely to the schema, which documents it adequately.

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 and resource ('Query the Ministry of Finance VAT white list (wl-api.mf.gov.pl)') and enumerates exactly what comes back, so an agent knows this is a Polish MF registry lookup rather than a generic VAT or company lookup. The scope (taxpayer card, account verification, decision values) makes it distinguishable from registry-adjacent siblings like vies_check or find_company.

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?

Gives clear operational guidance on which parameter mode to use — nip for a single lookup, nips for a batch of up to 30, bank_account alone to find the owner, or nip+bank_account to verify an account. It does not, however, say when to prefer this over vies_check or get_krs_extract, so sibling routing is left implicit.

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

All pl-firmy: Polish company check 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