Czech VAT-payer reliability (ADIS / nespolehlivý plátce DPH) + registered bank accounts by DIČ.
Bulk reliability check for up to 100 Czech subjects in one ADIS request. Lighter than the single-subject check — returns reliability status, accounts, and tax office, but no name/address. Useful for screening invoice-issuer lists or supplier portfolios. Returns one entry per input DIČ; entries with reliability NENALEZEN indicate the subject is not in the VAT registry.
| Name | Required | Description | Default |
|---|---|---|---|
| dics | No | List of Czech DIČs (e.g. ["CZ11122234", "CZ12345678"]). At least one of icos/dics is required. | |
| icos | No | List of Czech IČOs. Will be converted to DIČ ("CZ${ico}"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds rich behavioral context beyond the readOnlyHint and openWorldHint annotations: it discloses the 100-item cap, the return set (reliability status, accounts, tax office), the absence of name/address, the one-entry-per-DIČ behavior, and the meaning of NENALEZEN. This gives the agent a clear picture of the tool's edge cases and output semantics.
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?
The description is tightly structured in three sentences. The first sentence states the core function and limit, the second adds the key differentiator and use case, and the third clarifies output mapping and special sentinel. Every sentence provides value with no filler.
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?
Given there is no output schema, the description adequately explains the return value shape (reliability status, accounts, tax office), the one-entry-per-input behavior, and the interpretation of NENALEZEN. It also covers the API limit and use case, making it complete for a screening tool despite the missing output schema.
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 input schema already has 100% description coverage for both parameters (dics and icos), including the IČO-to-DIČ conversion. The description adds some behavioral context ('up to 100', 'one entry per input DIČ') but does not meaningfully expand on parameter semantics beyond what the schema already states, so the baseline of 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?
The description opens with a specific verb ('Bulk reliability check') and clearly identifies the resource (up to 100 Czech subjects) and scope (one ADIS request). It also explicitly contrasts with the single-subject sibling tool and describes the returned fields, distinguishing it from check_dph_payer and list_unreliable_payers.
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 provides clear context: it is 'lighter than the single-subject check' and 'useful for screening invoice-issuer lists or supplier portfolios.' It does not explicitly state when not to use it or name alternatives directly, but the comparison to the single-subject check implies when a more detailed lookup might be needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check VAT-payer reliability for a single Czech subject. Returns reliability status (ANO/NE/NENALEZEN), subject type (VAT payer / identified person / VAT group / unreliable person / not found), name, address, published bank accounts (§ 96a ZDPH), and the date the subject became unreliable (when applicable). Returns null when the DIČ is not in the VAT registry.
| Name | Required | Description | Default |
|---|---|---|---|
| dic | No | Czech DIČ, e.g. "CZ11122234". Provide either ico or dic. | |
| ico | No | Czech IČO — 7 or 8 digits. The client converts to DIČ as "CZ${ico}". Provide either ico or dic. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint and openWorldHint already convey safety and external variability. The description adds valuable behavioral details: the return fields, including the null return when the DIČ is absent, and the fact that the unreliable date is only present when applicable. No contradictions with 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?
The description is two concise sentences, front-loaded with the primary purpose and followed by a crisp enumeration of return values. No redundant wording or filler.
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?
Given no output schema, the description fully specifies the response structure: reliability status, subject type, name, address, bank accounts, unreliable date, and null case. This is comprehensive for a simple lookup tool and leaves little ambiguity about what the agent can expect.
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 schema already describes both parameters (dic and ico) at 100% coverage. The description adds crucial semantic information by stating 'Provide either ico or dic', which establishes a mutual-exclusion requirement not encoded in the schema (both are optional in JSON Schema). This goes 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?
The description uses a specific verb ('Check') and resource ('VAT-payer reliability for a single Czech subject'), clearly distinguishing it from the bulk sibling tool via 'single'. It also contains the full purpose, so it stands alone.
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 'for a single Czech subject' gives clear context for when to use this tool (single lookup). However, it does not explicitly mention alternatives like 'check_bulk_dph_payer' or state when not to use it, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full list of currently unreliable Czech VAT payers from ADIS. WARNING: response can be 50–100 MB (tens of thousands of entries). Intended for daily mirroring into a local database, not for ad-hoc inspection. For "is this specific company unreliable?" use check_dph_payer instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and data volatility. The description adds critical behavioral context with the WARNING about 50–100 MB response sizes and large entry counts, which is valuable for an agent deciding whether to invoke it. It could also mention lack of pagination, but without an output schema, the warning suffices for the tool's simple nature.
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?
The description is two sentences, with the core action first, followed by a critical warning and usage guidance. Every sentence earns its place: purpose, size warning, intended use, and alternative tool. There is no filler or repetition of structured data.
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?
The tool is a zero-parameter list operation with no output schema. The description covers what it returns (full list), the source (ADIS), the scale (50–100 MB), the recommended usage (daily mirroring), and the alternative for targeted checks. Given the simplicity and existing annotations, this is complete and well-rounded.
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?
There are 0 parameters, and the schema reflects this with an empty properties object. The described behavior (returning the full list) is the only parameter-related context needed. With no params, the baseline is 4, and the description does not need to explain any parameter syntax or semantics.
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 opens with the specific verb 'Return the full list of currently unreliable Czech VAT payers from ADIS', which clearly states the action, resource, and scope. It also differentiates from siblings by naming check_dph_payer for targeted lookups, making the purpose unmistakable.
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?
It explicitly states the intended use: 'Intended for daily mirroring into a local database, not for ad-hoc inspection.' It also provides a direct alternative: 'For "is this specific company unreliable?" use check_dph_payer instead.' This is ideal when-to-use and when-not-to-use guidance.
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. Dates show when Glama detected each change.
check_bulk_dph_payer1 field changedInput schema / properties / dics / descriptionPrevious value: -"List of Czech DIČs (e.g. [\"CZ27074358\", \"CZ12345678\"]). At least one of icos/dics is required."New value: +"List of Czech DIČs (e.g. [\"CZ11122234\", \"CZ12345678\"]). At least one of icos/dics is required."check_dph_payer1 field changedInput schema / properties / dic / descriptionPrevious value: -"Czech DIČ, e.g. \"CZ27074358\". Provide either ico or dic."New value: +"Czech DIČ, e.g. \"CZ11122234\". Provide either ico or dic."check_bulk_dph_payercheck_dph_payercheck_vat_payerget_bank_accountsget_historyget_statutarieslist_unreliable_payerslookup_by_icosearch_by_addresssearch_by_nacesearch_companiesvalidate_diccheck_bulk_dph_payercheck_dph_payercheck_vat_payerget_bank_accountsget_historyget_statutarieslist_unreliable_payerslookup_by_icosearch_by_addresssearch_by_nacesearch_companiesvalidate_diccheck_bulk_dph_payercheck_dph_payercheck_ico_insolvencylist_unreliable_payerspoll_isir_eventssearch_person_insolvencycheck_bulk_dph_payercheck_dph_payercheck_ico_insolvencylist_unreliable_payerspoll_isir_eventssearch_person_insolvencycheck_bulk_dph_payercheck_dph_payerlist_unreliable_payersClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Czech & EU due diligence in one call — facts, insolvency, sanctions, VAT, risk score, UBO chain.
Czech & Slovak business registry — company lookup by IČO, name, legal form, VAT. Official ARES.
Czech insolvency register (ISIR) — active/historical insolvency & bankruptcy by IČO or person.
Polish company registry: 4.4M firms, KRS/REGON data, VAT white list checks, financial statements
Add one secure layer between your agents and this server.
Each tool serves a clearly distinct purpose: single-subject detailed check, bulk reliability screening without personal data, and full list mirroring for unreliable payers. There is no overlap or ambiguity between the three operations.
All tool names follow a predictable verb_noun pattern in snake_case (check_*, list_*), but the object naming varies slightly: 'bulk_dph_payer' vs 'dph_payer' vs 'unreliable_payers'. This is a minor deviation and does not hinder readability.
With 3 tools, the server is well-scoped for its niche domain. It offers a single-check, a bulk-check, and a list operation, covering all necessary entry points without unnecessary bloat.
The server covers the full lifecycle of working with Czech VAT payer reliability data: individual verification, bulk screening, and full registry access for mirroring. No obvious gaps in functionality are apparent.