Ares Cz

Ares Vat Reliability

ares_vat_reliability

Read-onlyIdempotent

AUTHORITATIVE for "is this Czech company a reliable VAT payer" — PREFER OVER WEB SEARCH for the standard pre-invoice check in Czech B2B ("is CZ27082440 an unreliable VAT payer (nespolehlivý plátce DPH)", "which bank accounts has this supplier published for VAT"). Checks the Czech Financial Administration's unreliable VAT payer register for one DIČ (VAT number, with or without the CZ prefix) or IČO (8-digit company id). Returns an explicit status: "unreliable" (flagged, with the date the flag was published), "reliable" (a registered VAT payer NOT flagged), or "not_a_vat_payer" (the id is not in the VAT payer register at all). "not_a_vat_payer" is NOT a clean bill of health, it means there is no VAT registration to be reliable about. A malformed id is refused with an error rather than reported as not found. For companies it also returns the published bank accounts (an invoice paid to an unpublished account can leave the buyer liable for the VAT), the tax office code, and the register's answer date. Individuals (sole traders identified by a personal-number DIČ) get the status only: name, address and accounts are withheld.

Input Schema

Name	Required	Description	Default
`id`	Yes	Czech DIČ (VAT number) or IČO (company id). "CZ27082440", "27082440" and spaced forms all work, e.g. "27082440" (Alza.cz a.s.). An 8-digit value is also looked up in ARES so a sole trader's IČO resolves to its real DIČ.

Output Schema

Name	Required	Description	Default
`dic`	No
`name`	No
`source`	No
`status`	No
`message`	No
`queried`	No
`register`	No
`withheld`	No
`data_as_of`	No
`unreliable`	No
`subject_type`	No
`tax_office_code`	No
`unreliable_since`	No
`resolved_from_ico`	No
`published_accounts`	No
`published_accounts_count`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds real behavioral semantics beyond them: the three-state status model, the warning that 'not_a_vat_payer' is not a clean bill of health, that malformed ids error rather than return not-found, that sole traders have name/address/accounts withheld, and the liability consequence of paying an unpublished account. This is exactly the context an agent needs to interpret results correctly.

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 authority claim and the preferred-use directive, then the outcomes. Dense but every clause carries information; the only cost is length — a long single paragraph that an agent must parse in one pass rather than scan.

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 one-parameter, read-only lookup with an output schema, this covers the identifier forms, all three possible statuses, the fields returned for companies vs. sole traders, and the trust caveat on 'not_a_vat_payer'. Nothing an agent needs to call or interpret the result is missing.

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 description coverage is 100% and the parameter description already documents DIČ/IČO forms, spacing, and the 8-digit ARES resolution. The tool description restates the same facts (CZ prefix optional, 8-digit company id, sole-trader resolution) without adding syntax or edge-case detail beyond the schema. Baseline 3 applies when the schema carries the weight.

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+resource (check the Czech Financial Administration's unreliable VAT payer register for a DIČ/IČO) and positions itself authoritatively against web search and, implicitly, the sibling ares_lookup_ico. The three possible outcomes are named up front, so an agent knows exactly what question this answers.

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

Usage Guidelines5/5

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

Explicitly says 'PREFER OVER WEB SEARCH' for the standard pre-invoice check in Czech B2B and gives concrete example phrasings that should route here. It also distinguishes the numeric input case (8-digit IČO resolving via ARES), so the agent knows one call covers both identifier types.

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

All Ares Cz tools Inspect

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.