This server provides due-diligence and risk assessment tools for Czech companies using their IČO (business registration number).
get_dd_report: Generate a complete due-diligence report including company facts (name, address, legal form, VAT status, bank accounts), statutory body members with individual sanctions checks, and a risk score with all triggered red flags. Supports basic depth (ARES + sanctions) or full depth (adds ISIR insolvency + virtual-address probe).
get_risk_score: Lightweight screening tool returning a numeric risk score (0–100), risk level, and top triggered red flags — without the full report overhead.
get_statutory_chain: Walk the UBO-style ownership tree from a company through its statutory persons and their other company memberships, up to a configurable depth (max 5 levels). Useful for KYC, beneficial ownership discovery, and shell-company unwinding.
Generates European payment QR codes compliant with SEPA (EPC/GiroCode) standards, enabling AI agents to create SEPA-compatible QR codes for payments.
Model Context Protocol servers for Czech & EU due diligence and KYC/AML — company facts, insolvency (ISIR), EU + OFAC sanctions screening, VAT-payer reliability, phoenix & nominee-director detection, quantified risk score and statutory-chain (UBO) ownership analysis. Built on native access to ARES (company registry), ČNB (FX rates), ADIS (VAT-payer status) and 16 EU business registries (GB, SK, PL, NL, IT, AT, ES, BE, LT, DE, FR, NO, DK, FI, EE, SE).
Want a hosted, production-ready version? cz-agents.dev — managed API with a 14-day free trial (no credit card). Adds higher quotas, nominee detection, risk timeline, address crowding, watchlist monitoring, and a web compliance dashboard. Your self-hosted config keeps working after upgrade — same endpoints, same token format.
Don't want to wire an MCP client? The same data is available as a web application:
Business partner due diligence (prověření obchodního partnera)
Case study: company due diligence with an AI agent — 20 minutes → 30 seconds
Landing page: cz-agents.dev · Listed in: official MCP Registry under DNS-verified namespace dev.cz-agents/*
Package | Source | Status |
ARES — Czech Business Register | ✅ live | |
ČNB — daily FX rates | ✅ live | |
EU + OFAC sanctions screening (KYC/AML) | ✅ live | |
ISIR — Czech insolvency register | ✅ live | |
ADIS — unreliable VAT payer (nespolehlivý plátce DPH) + transparent accounts | ✅ live | |
Due-diligence aggregator (ARES + sanctions + ISIR + ADIS + statutory chain) | ✅ live | |
Czech distress real estate intelligence (ISIR sales + portál dražeb) | ✅ live (v0.1) | |
EU business registries — 16 countries (GB, SK, PL, NL, IT, AT, ES, BE, LT, DE, FR, NO, DK, FI, EE, SE) via Companies House / ORSR / KRS / SIRENE / BRREG / CVR / PRH / RIK / Bolagsverket / VIES / GLEIF | ✅ live | |
Payment QR codes (SPAYD / EPC-GiroCode) — bonus utility | ✅ live |
Server | What it adds | Where |
| 8-indicator nominee director detection (cross-DB), phoenix recidiva, enriched risk timeline with AI narrative, recursive linked-entities risk analysis (depth 1-3), shell-firm address crowding with provider detection, daily watchlist monitoring with email digest | Hosted-only at |
Related MCP server: eu-company-mcp-server
{
"mcpServers": {
"ares": { "command": "npx", "args": ["-y", "@czagents/ares"] },
"cnb": { "command": "npx", "args": ["-y", "@czagents/cnb"] },
"sanctions": { "command": "npx", "args": ["-y", "@czagents/sanctions"], "env": { "SANCTIONS_DB": "/path/to/sanctions.db" } },
"isir": { "command": "npx", "args": ["-y", "@czagents/isir"], "env": { "ISIR_SOAP_ENABLED": "1" } },
"adis": { "command": "npx", "args": ["-y", "@czagents/adis"], "env": { "ADIS_SOAP_ENABLED": "1" } },
"dd": { "command": "npx", "args": ["-y", "@czagents/dd"], "env": { "SANCTIONS_DB": "/path/to/sanctions.db", "ADIS_SOAP_ENABLED": "1" } },
"eu-registry": { "command": "npx", "args": ["-y", "@czagents/eu-registry"] },
"payqr": { "command": "npx", "args": ["-y", "@czagents/payqr"] },
"realestate": { "command": "npx", "args": ["-y", "@czagents/realestate"] }
}
}{
"mcpServers": {
"ares": { "url": "https://ares.cz-agents.dev/mcp" },
"cnb": { "url": "https://cnb.cz-agents.dev/mcp" },
"sanctions": { "url": "https://sanctions.cz-agents.dev/mcp" },
"isir": { "url": "https://isir.cz-agents.dev/mcp" },
"adis": { "url": "https://adis.cz-agents.dev/mcp" },
"dd": { "url": "https://dd.cz-agents.dev/mcp" },
"eu-registry": { "url": "https://eu-registry.cz-agents.dev/mcp" },
"payqr": { "url": "https://payqr.cz-agents.dev/mcp" },
"realestate": { "url": "https://realestate.cz-agents.dev/mcp" }
}
}@czagents/ares (10 tools)lookup_by_ico({ ico }) — full company record
search_companies({ query, city, street, psc, nace, pocet }) — combined search
search_by_address({ street, city, psc }) — all companies at an address
search_by_nace({ nace, city }) — by CZ-NACE activity code
get_statutaries({ ico }) — current statutory body (for due diligence)
validate_dic({ dic }) — DIČ format + MOD11 checksum
check_vat_payer({ ico }) — VAT registration + transparent accounts
get_bank_accounts({ ico }) — DPH-published accounts
get_history({ ico }) — previous names, address changes
watch_entity({ ico }) — start free monitoring onboarding for one company
@czagents/cnb (3 tools)get_rates({ date? }) — full daily FX sheet
convert({ amount, from, to, date? }) — CZK-crossed conversion
get_rate({ code, date? }) — single currency rate
@czagents/sanctions (6 tools)search_person({ name, dob?, nationality?, threshold? }) — fuzzy KYC screen against EU + OFAC
search_entity({ name, country?, threshold? }) — entity / company screen
check_ico({ ico, name? }) — direct lookup of a Czech IČO on sanctions lists
get_listing({ id }) — full record by ${source}:${id}
list_recent_updates({ since, source? }) — daily monitoring (added/removed/modified)
rescreen_portfolio({ subjects[], since, source? }) (paid; available when x402 is enabled) — re-screen your own subject list against sanctions-list changes
@czagents/isir (3 tools)check_ico_insolvency({ ico }) — direct lookup of a Czech IČO in the insolvency register
search_person_insolvency({ ico?, rc?, dob?, firstname?, surname? }) — find a person by IČO, birth number, or name + DOB
poll_isir_events({ since }) — append-only event feed for daily monitoring
@czagents/adis (3 tools)check_dph_payer({ ico OR dic }) — full reliability check via ADIS V2: status (ANO/NE/NENALEZEN), subject type, name, address, transparent bank accounts (§ 96a ZDPH), unreliable-since date
check_bulk_dph_payer({ icos[] OR dics[] }) — batch up to 100 subjects (lighter response, status + accounts only)
list_unreliable_payers() — full list of currently unreliable payers (50–100 MB, intended for daily mirroring)
@czagents/dd (12 tools)person_companies({ name, birth_year? }) — Czech VR companies connected to a person (free, anonymous)
get_owners({ ico }) — direct + upstream Czech VR ownership tree (free, anonymous)
get_dd_report({ ico, depth }) — unified ARES + sanctions + ISIR report with risk score
watch_entity({ ico }) — start free monitoring onboarding for one company
get_risk_score({ ico }) — fast 0–100 score + top red flags
get_statutory_chain({ ico, max_depth }) — surname-based statutory-body walk for shell-company unwinding
detect_nominee_director({ ico }) — 3-indicator "white horse" director detection (Compliance tier+)
detect_phoenix({ ico }) — phoenix-company pattern detection (Compliance tier+)
get_risk_timeline({ ico }) — chronological company lifecycle/risk timeline (Compliance tier+)
detect_address_crowding({ ico }) — shell-firm "address hotel" detection (Compliance tier+)
get_eu_dd_report({ lei OR name, country? }) — EU DD report: GLEIF entity data + EU/OFAC sanctions check (Compliance tier+)
get_eu_parent({ ico }) — find EU/international parent via ARES → GLEIF LEI matching (Compliance tier+)
@czagents/eu-registry (3 tools)search_company({ name, country?, limit? }) — search non-Czech registries by company name across 16 countries
get_company({ id, country }) — company record by national ID (CRN / IČO / KRS / SIREN / LEI / VAT / …)
lookup_company_by_vat({ vat }) — free VIES VAT validity + name/address lookup
@czagents/payqr (6 tools)qr_payment({ iban, bic?, amount?, ... }) — payment QR (auto SPAYD for CZ/SK, EPC/GiroCode for other SEPA)
qr_text({ text }) — plain-text QR
qr_wifi({ ssid, password?, security? }) — Wi-Fi network QR
qr_vcard({ name, phone?, email?, ... }) — vCard 3.0 contact QR
qr_read({ image_data }) — decode + classify a QR code from a base64 image
qr_payment_batch({ payments[] }) (paid; available when x402 is configured) — payment QRs for a whole invoice run in one call
@czagents/realestate (1 tool, free tier only)get_district_aggregate({ okres, window_days? }) — anonymised district-level distress real-estate stats (ISIR insolvencies + portál dražeb/CEVD forced sales); counts under 5 are banded to protect individual identification
A toolkit for compliance, KYC/AML, accounting and cross-border checks over Czech & EU registries:
VAT & invoicing — verify VAT-payer status (ADIS) and convert at official ČNB FX rates before booking.
Counterparty screening — ARES identity, EU + OFAC sanctions, ISIR insolvency.
Due diligence (flagship) — the @czagents/dd aggregator combines the above into a risk score, statutory-chain / UBO walk, and EU-parent lookup.
Cross-border — company lookups across 16 EU registries (@czagents/eu-registry).
Use a single-source server when you need just one dataset; use the due-diligence aggregator for combined, scored output.
Example prompts the aggregator handles well:
KYC pre-invoice — "Before we send a 350 000 Kč invoice to IČO 11122234, flag any insolvency, sanctions, unreliable-VAT-payer status, or nominee-director red flags."
Vendor onboarding — "Run KYC on this prospective supplier and tell me if anything looks off. Use the full statutory chain."
M&A pre-due-diligence — "Generate a DD report on the acquisition target and walk the statutory body two levels deep — flag any insolvent firms in the network."
A/A/A on Glama (quality / security / license), claimed and maintained.
Listed in the official MCP registry
under DNS-verified namespace dev.cz-agents/*.
Building MCP servers for a country that isn't in the dataset — design rationale, gotchas (MOD11, ARES Swagger bugs), and how this pattern adapts MCP to non-English locales.
MIT © Martin Havel — see LICENSE
Detects "shell-firm hotel" patterns — counts how many companies share the same registered address. Threshold-based risk: 1-9 normal (multi-tenant office), 10-49 mild (legitimate coworking), 50-199 medium (virtual office provider), 200+ high (shell-firm hotel). Compliance tier or higher.
| Name | Required | Description | Default |
|---|---|---|---|
| ico | Yes | Czech IČO 7-8 digits |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. Description adds threshold-based risk levels (1-9 normal, 200+ high), giving concrete behavioral context beyond 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?
Description is informative but slightly verbose with threshold enumeration. Front-loaded with purpose, but could be more concise while keeping information.
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?
Tool is simple (one param, no output schema). Description sufficiently explains purpose and threshold interpretation. Complete given annotations.
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?
Single parameter 'ico' with schema description 'Czech IČO 7-8 digits'. Description adds no further meaning; schema coverage is 100%, so baseline 3.
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?
Clearly states it detects 'shell-firm hotel' patterns by counting companies sharing the same registered address. Distinguishes from siblings like detect_nominee_director and detect_phoenix.
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?
Implies usage for compliance checks with 'Compliance tier or higher', but no explicit when-to-use or when-not-to-use, nor contrasts with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect "white horse" / nominee director patterns — 3 surface indicators (age outlier, multi-board membership, recent appointment) computable from ARES data alone. Returns indicator breakdown with riskScore 0-100. Pro Compliance tier or higher. For 8-indicator deep analysis including ISIR cross-reference, sanctions, address crowding and phoenix pattern, see detect_nominee_director_rich in @czagents/ddplus.
| Name | Required | Description | Default |
|---|---|---|---|
| ico | Yes | Czech IČO — 7 or 8 digits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds specific behavioral context: data source (ARES data alone), indicators computed, and output structure. No contradictions.
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 concise, front-loaded with the main purpose, and each sentence adds value. No unnecessary words.
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 the simple input (one parameter), no output schema, and annotations providing readonly/open world, the description fully covers what the tool does, its tier requirement, and points to an alternative for deeper analysis.
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 provides 100% coverage for the single parameter with a clear description. The tool description does not add further parameter semantics, so baseline score 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 clearly states the tool detects nominee director patterns using 3 surface indicators, and distinguishes it from the richer alternative. The output format (indicator breakdown with riskScore) is specified.
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 mentions the Pro Compliance tier requirement and explicitly directs users to a deeper analysis tool when needed, providing clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect phoenix company pattern — 3 surface indicators (surname match with prior insolvent director, founding proximity < 12 months to insolvency, NACE sector presence) computable from ARES + ISIR data alone. Returns PhoenixReport with riskScore 0-100. Pro Compliance tier or higher. For 4 additional deep indicators (founder identity, asset transfer, multi-cycle, address continuity) see detect_phoenix_rich in @czagents/ddplus.
| Name | Required | Description | Default |
|---|---|---|---|
| ico | Yes | Czech IČO — 7 or 8 digits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. Description adds return type (PhoenixReport with riskScore 0-100) and tier requirement (Pro Compliance tier or higher), adding context beyond 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 wasted words, front-loaded with purpose and key details.
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 one parameter, no output schema, and moderate complexity, the description covers indicators, data sources, return type, tier, and alternative tool, making it self-contained.
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?
Only one parameter (ico) with schema description 'Czech IČO — 7 or 8 digits.' Description does not add additional meaning beyond the schema; schema coverage is 100%, so baseline 3.
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 clearly states it detects the phoenix company pattern with specific indicators, and explicitly distinguishes from the sibling detect_phoenix_rich tool.
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?
Provides when to use (3 surface indicators from ARES/ISIR) and when not to use (for deep indicators, use detect_phoenix_rich), with explicit alternative named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a complete due-diligence report for a Czech IČO. Returns company facts (name, address, legal form, VAT status, bank accounts), statutory body with per-member sanctions check, and a transparent risk score with all triggered red flags.
| Name | Required | Description | Default |
|---|---|---|---|
| ico | Yes | Czech IČO — 7 or 8 digits. | |
| depth | No | basic = ARES + sanctions only; full = + ISIR insolvency + virtual-address probe. | basic |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows it's a safe read operation. The description adds that it generates a report with risk scores and sanctions, but no additional behavioral traits like auth requirements or rate limits. Adequate but not enriched.
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?
Three sentences, no wasted words. Front-loads the main purpose, then lists content details. Each sentence earns its place.
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?
No output schema, but description adequately describes return contents (company facts, statutory body, risk score, red flags). Could mention that it accepts a single IČO per call, but overall complete for a single-input report 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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining what each depth level ('basic' vs 'full') includes (e.g., 'basic = ARES + sanctions only'), which goes beyond the schema's enum 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?
Description clearly states 'Generate a complete due-diligence report for a Czech IČO' and lists specific outputs (company facts, statutory body, risk score). It differentiates from sibling tools that are more specialized detection tools (e.g., detect_nominee_director, get_risk_score) by being a holistic report.
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 implies this is for a comprehensive report on a Czech company, but does not explicitly state when to use it vs. specialized siblings. It provides clear context but lacks exclusions or alternatives, so it's slightly above average.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
EU Due-Diligence report for an international company. Input: 20-char LEI code, or company name + optional country. Returns GLEIF entity data (status, address, registration number) plus sanctions screening against EU/OFAC lists. Coverage notes per country included. Note: GLEIF covers mid/large firms with LEI — SMEs may not be found. Pro Compliance tier or higher.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | 20-char LEI code (e.g. "W38RGI023J3WT1HWRP32") or company name. | |
| country | No | ISO 3166-1 alpha-2 country code — helps narrow name search, not needed for LEI lookup. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint: true) already indicate the tool is read-only. The description adds valuable context: it returns GLEIF entity data and sanctions screening, includes coverage notes per country, and notes the limitation with SMEs. This supplements annotations without contradiction.
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 concise—three sentences and a note—with the core purpose front-loaded. Each sentence contributes meaningful information (purpose, input/output, coverage, limitation). Only minor redundancy with schema descriptions prevents a 5.
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 tool with no output schema and moderate complexity (two input modes, multiple output types, coverage notes, tier restriction), the description covers what the tool does, its limitations, and input options. It could detail sanctions lists or response format, but it is sufficiently complete given the annotations.
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% with good parameter descriptions. The description's input guidance ('20-char LEI code, or company name + optional country') adds no new semantics beyond the schema, so a 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 clearly states the tool produces an 'EU Due-Diligence report' for international companies, specifying the input (LEI code or company name) and outputs (GLEIF entity data plus sanctions screening). It distinguishes itself from sibling tools like 'get_dd_report' and 'get_eu_parent' by focusing on EU-specific due-diligence with GLEIF and sanctions.
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 when to use the tool (for EU due-diligence with LEI or company name) and notes that SMEs without LEI may not be found, implying an alternative may be needed. It also mentions a tier requirement ('Pro Compliance tier or higher'). However, it does not explicitly compare to sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the EU/international parent company for a Czech IČO. Looks up the company name in ARES, then searches GLEIF (Global LEI Foundation) for a matching LEI-registered entity. Returns LEI, name, country, and confidence level (HIGH/MEDIUM/LOW). Note: GLEIF covers mid/large international firms; SMEs without an LEI will not be found. Pro Compliance tier or higher.
| Name | Required | Description | Default |
|---|---|---|---|
| ico | Yes | Czech IČO — 7 or 8 digits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses two-step lookup process, confidence level, and limitations (SMEs). Annotations (readOnlyHint, openWorldHint) are consistent and description adds valuable context.
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, front-loaded with purpose, no fluff, well-structured.
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?
No output schema, but description explains return values (LEI, name, country, confidence) and caveats. Complete for a simple lookup 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?
Schema already describes the ico parameter as 'Czech IČO — 7 or 8 digits.' Description does not add further semantic meaning beyond that.
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?
Clearly states the tool finds the EU/international parent company for a Czech IČO via ARES and GLEIF, distinguishing it from sibling tools like get_statutory_chain.
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?
Provides context that GLEIF covers mid/large firms and SMEs without LEI won't be found, implying when to use. Misses explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lightweight version of get_dd_report — returns just the numeric score (0-100), risk level, and top triggered red flags. Faster when you only need a yes/no/maybe screen.
| Name | Required | Description | Default |
|---|---|---|---|
| ico | Yes | Czech IČO — 7 or 8 digits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations (readOnlyHint, openWorldHint) by stating it's lightweight and faster. Consistent with read-only nature; no behavioral surprises.
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?
Single sentence, no wasted words, all information is front-loaded and easy to parse.
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 the tool's simplicity (one parameter, read-only, few output fields), the description is complete. No output schema, but listed outputs suffice. Sibling comparison provided.
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?
Single parameter 'ico' with description 'Czech IČO — 7 or 8 digits.' Schema coverage is 100%, so description adds minimal value beyond schema. Baseline 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?
Clearly describes as lightweight version of get_dd_report, specifies exact output (score, risk level, red flags), and highlights speed advantage. Distinguishes from sibling tool.
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 mentions faster when only a yes/no/maybe screen is needed, implying when to use this over get_dd_report. Provides clear context but no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a chronologically sorted lifecycle timeline for a Czech company — basic events include company formation, statutory appointments, active insolvency, sanctions matches, VAT reliability flips. Returns events[] with riskScore 0-100. Pro Compliance tier or higher. For enriched timeline with ISIR lifecycle, address history, cross-entity events, and AI narrative summary, see get_risk_timeline_rich in @czagents/ddplus.
| Name | Required | Description | Default |
|---|---|---|---|
| ico | Yes | Czech IČO — 7 or 8 digits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint) are supplemented by description noting return format (events[] with riskScore 0-100) and specific event types. No contradictions, but could detail fields beyond riskScore.
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 concise, front-loaded sentences that cover purpose, output, tier requirement, and sibling tool reference.
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?
Adequate for a simple tool with one parameter and no output schema. Mentions return format but lacks details on other fields in events[]. Still sufficient.
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 already fully describes the ico parameter (coverage 100%). Description adds no new parameter semantics beyond reinforcing Czech context.
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?
Clearly states it builds a chronologically sorted lifecycle timeline for a Czech company, listing basic events like formation, appointments, etc. Distinguishes from a richer sibling tool.
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?
Provides explicit prerequisite ('Pro Compliance tier or higher') and directly names an alternative tool for enriched timeline: get_risk_timeline_rich.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Surname-based heuristic walk through statutory bodies of related Czech companies. Best for shell-company unwinding in small s.r.o. with RARE surnames. NOT a true UBO source — for actual beneficial ownership use the ESM (evidence skutečných majitelů, separate registry, future @czagents/esm). For boards of large public companies with common Czech surnames (Novák, Zima, Kolář…) results are noisy by design; the tool auto-skips persons whose surname matches >50 companies with a SURNAME_TOO_COMMON note.
| Name | Required | Description | Default |
|---|---|---|---|
| ico | Yes | Czech IČO — 7 or 8 digits. | |
| max_depth | No | Max recursion depth (default 3, hard cap 5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the readOnlyHint and openWorldHint annotations. It explains the heuristic nature, noise for common surnames, and auto-skipping with notes, which annotations do not cover.
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 concise and front-loaded with the main purpose, followed by caveats. It uses about five sentences with no wasted words, though it could be slightly more compact without losing meaning.
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 the tool's complexity (heuristic, noisy, surname-based), the description covers purpose, usage, limitations, and alternatives comprehensively. It adequately prepares the agent for expected behavior, even without an 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 has 100% coverage for its two parameters, so the baseline is 3. The description does not add extra parameter-level details beyond the schema, though it implicitly ties the ICO to surname rarity, which is minor additional context.
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 clearly states the tool performs a surname-based heuristic walk through statutory bodies of related Czech companies, specifically for shell-company unwinding with rare surnames. It distinguishes itself from a true UBO source, making its purpose unambiguous.
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 explicitly states when to use (shell-company unwinding with rare surnames) and when not to use (common surnames like Novák, Zima, Kolář). It provides an alternative (ESM registry) for actual beneficial ownership, giving clear 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.
v0.3.0detect_address_crowdingdetect_nominee_directordetect_phoenixget_eu_dd_reportget_eu_parentget_risk_timelinev0.1.7get_dd_reportget_risk_scoreget_statutory_chainTools have distinct purposes covering different aspects of Czech company due diligence. Some overlap between `get_dd_report` and `get_risk_score` is clarified by descriptions stating one is full report and the other lightweight. No significant confusion.
All tool names follow a consistent `verb_noun` pattern in snake_case (e.g., `detect_address_crowding`, `get_dd_report`). Verbs are either 'detect' or 'get', making it predictable and easy to understand.
With 9 tools, the set is well-scoped for Czech company due diligence. It covers risk detection, reports, EU aspects, and timelines without being excessive or insufficient.
The tool surface covers core due diligence operations: pattern detection, reports, risk scoring, EU parent lookup, timeline, and statutory chain. Missing a direct company search tool, but the domain is well-covered for risk screening. Advanced features are noted as external tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Hosted MCP server for real-world data: business registries, sanctions, companies, domains, crypto.
Czech National Bank (Česká národní banka, ČNB) public API MCP. Keyless.
AI-native ERP MCP: ES/EU fiscal compliance (VeriFactu/TicketBAI/Facturae), invoicing, tax, banking
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/martinhavel/cz-agents-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
