Czech VAT-payer reliability (ADIS / nespolehlivý plátce DPH) + registered bank accounts by DIČ.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 3 of 3 tools scored.
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.
check_bulk_dph_payerABulk 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_dph_payerACheck 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.
list_unreliable_payersAReturn 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
Sign in to create a connector for this server.