Servidores del Protocolo de Contexto de Modelo (MCP) para datos gubernamentales y empresariales checos. Proporciona a tu agente de IA acceso nativo a ARES, ČNB, ISIR, control de sanciones y un agregador unificado de diligencia debida.
Página de inicio: cz-agents.dev
Paquete | Fuente | Estado |
ARES — Registro Mercantil Checo | ✅ activo | |
ČNB — tipos de cambio diarios | ✅ activo | |
Control de sanciones UE + OFAC (KYC/AML) | ✅ activo | |
ISIR — Registro de insolvencia checo | ✅ activo | |
Agregador de diligencia debida (ARES + sanciones + ISIR + cadena estatutaria) | ✅ activo |
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" } },
"dd": { "command": "npx", "args": ["-y", "@czagents/dd"], "env": { "SANCTIONS_DB": "/path/to/sanctions.db" } }
}
}{
"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" },
"dd": { "url": "https://dd.cz-agents.dev/mcp" }
}
}@czagents/ares (9 herramientas)lookup_by_ico({ ico }) — registro completo de la empresa
search_companies({ query, city, street, psc, nace, pocet }) — búsqueda combinada
search_by_address({ street, city, psc }) — todas las empresas en una dirección
search_by_nace({ nace, city }) — por código de actividad CZ-NACE
get_statutaries({ ico }) — órgano estatutario actual (para diligencia debida)
validate_dic({ dic }) — formato DIČ + suma de comprobación MOD11
check_vat_payer({ ico }) — registro de IVA + cuentas transparentes
get_bank_accounts({ ico }) — cuentas publicadas por DPH
get_history({ ico }) — nombres anteriores, cambios de dirección
@czagents/cnb (3 herramientas)get_rates({ date? }) — hoja completa de tipos de cambio diarios
convert({ amount, from, to, date? }) — conversión cruzada con CZK
get_rate({ code, date? }) — tipo de cambio de una sola divisa
@czagents/sanctions (5 herramientas)search_person({ name, dob?, nationality?, threshold? }) — control KYC difuso frente a UE + OFAC
search_entity({ name, country?, threshold? }) — control de entidad / empresa
check_ico({ ico, name? }) — búsqueda directa de un IČO checo en listas de sanciones
get_listing({ id }) — registro completo por ${source}:${id}
list_recent_updates({ since, source? }) — monitoreo diario (añadido/eliminado/modificado)
@czagents/isir (3 herramientas)check_ico_insolvency({ ico }) — búsqueda directa de un IČO checo en el registro de insolvencia
search_person_insolvency({ ico?, rc?, dob?, firstname?, surname? }) — encontrar a una persona por IČO, número de nacimiento o nombre + fecha de nacimiento
poll_isir_events({ since }) — feed de eventos de solo adición para monitoreo diario
@czagents/dd (3 herramientas)get_dd_report({ ico, depth }) — informe unificado de ARES + sanciones + ISIR con puntuación de riesgo
get_risk_score({ ico }) — puntuación rápida de 0–100 + principales señales de alerta
get_statutory_chain({ ico, max_depth }) — recorrido del árbol de UBO / empresas pantalla
Construyendo servidores MCP para un país que no está en el conjunto de datos — justificación del diseño, dificultades (MOD11, errores de ARES Swagger) y cómo este patrón adapta MCP a idiomas no ingleses.
MIT © Martin Havel — ver 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 indicate readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context: it explains the threshold-based risk classification (1-9, 10-49, 50-199, 200+) and notes the compliance tier requirement, which is not covered by annotations. It does not contradict the read-only hint as 'detects' and 'counts' are read operations.
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, starting with the tool's main function. Each sentence provides necessary detail: the definition, the thresholds, and the access requirement. There is no unnecessary repetition 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?
For a simple tool with one parameter, read-only annotations, and no output schema, the description is nearly complete. It explains the detection logic and thresholds, and includes the compliance tier requirement. It could be more explicit about the return format (e.g., whether it returns a count, a risk category, or both), which would be helpful given the lack of 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?
Schema coverage for the single parameter (ico) is 100%, as the schema already describes it as 'Czech IČO 7-8 digits'. The description adds no additional information about the parameter itself, so it does not go beyond the schema. The baseline for high coverage is 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 what the tool does: 'Detects shell-firm hotel patterns — counts how many companies share the same registered address.' This is a specific verb+resource with additional detail on the pattern. It differentiates itself from sibling detection tools by focusing on address crowding.
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 context on the tool's purpose and includes a threshold-based risk interpretation, which implies when it would be relevant. However, it does not explicitly state when to use this tool versus sibling tools like detect_nominee_director or detect_phoenix, nor does it mention any exclusions. The 'Compliance tier or higher' requirement is a usage constraint but not an explicit when/when-not guideline.
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 context about the return format (indicator breakdown with riskScore 0-100), the data source (ARES data alone), and an access tier requirement, going beyond the annotations without contradicting them.
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, front-loaded with the purpose, and includes all relevant details without any fluff. Every 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?
For a single-parameter, read-only tool with no output schema, the description covers purpose, indicators, return summary, access tier, and alternative tool. It is complete and 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?
The input schema already fully describes the only parameter (ico) with format details. The description does not add parameter-specific information, so the baseline of 3 applies since schema coverage is 100%.
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 'white horse' / nominee director patterns, enumerates the 3 surface indicators, and distinguishes itself from the deeper detect_nominee_director_rich variant. This leaves no ambiguity about the tool's scope.
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 explains when to use this tool ('Pro Compliance tier or higher') and directs users to detect_nominee_director_rich for deeper analysis with 8 indicators and additional data sources. This provides clear alternatives and context.
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?
The description goes well beyond the annotations (readOnlyHint, openWorldHint). It adds that the tool is computable from 'ARES + ISIR data alone', returns a 'PhoenixReport with riskScore 0-100', and requires a 'Pro Compliance tier'. These are important behavioral details not present in 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?
Three sentences, each with a distinct role: purpose/indicators, output/access, and alternative. No fluff or repetition. The information is front-loaded and every clause 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?
For a detection tool with several indicators and an output riskScore, the description covers the essential context: input (ICO), computation (3 indicators, data sources), output (PhoenixReport with riskScore), tiers, and a pointer to the richer version. It does not explain the interpretation of the riskScore or the structure of PhoenixReport, but given no output schema, this is a minor gap.
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 only parameter 'ico' is fully documented in the schema ('Czech IČO — 7 or 8 digits') with 100% coverage. The description does not add any additional meaning about the parameter itself, so the baseline of 3 applies as the schema carries the weight.
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's purpose: 'Detect phoenix company pattern' and lists exactly what it computes (3 surface indicators). It also distinguishes itself from the sibling tool detect_phoenix_rich by specifying the limits of surface indicators vs deep indicators, making its role 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?
Explicit guidance is provided: 'Pro Compliance tier or higher' states an access requirement, and 'For 4 additional deep indicators ... see detect_phoenix_rich' directly names the alternative and when to use it instead. This gives the agent clear decision criteria for tool selection.
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, establishing a safe read-only snapshot. The description adds context about the report contents, such as per-member sanctions check and a transparent risk score with triggered red flags, but does not disclose API limitations, data sources, or response size. This adds moderate value beyond the 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, front-loaded with the main purpose, then the report contents. Every word earns its place; no filler or repetition.
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?
With no output schema, the description compensates by listing the main report sections, giving an agent a clear expectation of company facts, statutory body details, and risk score. It omits exact output formatting or risk score scale, but for moderate complexity, this is fairly complete.
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%, and the schema provides excellent parameter descriptions: ico format ('7 or 8 digits') and depth enum ('basic = ARES + sanctions only; full = + ISIR insolvency + virtual-address probe'). The tool description adds no parameter information, so the schema carries the burden; baseline of 3 applies.
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 opens with 'Generate a complete due-diligence report for a Czech IČO' – a specific verb, resource, and country scope. It enumerates report sections (company facts, statutory body, risk score), distinguishing it from sibling tools like get_eu_dd_report or get_risk_score.
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 clearly sets the context: use for Czech IČO to generate a complete due-diligence report. It does not explicitly mention when to use this over alternatives like get_risk_score or get_eu_dd_report, so it lacks exclusions, but the country and scope are well defined.
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?
The description goes beyond the readOnlyHint and openWorldHint annotations by detailing exactly what is returned (GLEIF entity data with status/address/registration number, sanctions screening against EU/OFAC lists), coverage notes, the SME limitation (important for expectations), and the tier requirement. This enriches behavioral understanding significantly.
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 compact and well-structured: purpose, input, output, coverage note, limitation, and access tier are each stated in one short sentence or clause. Every sentence adds essential information without redundancy.
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 report tool with no output schema, the description covers inputs, outputs, limitations, and prerequisites (tier). It addresses scope (EU/OFAC sanctions), data source (GLEIF), and coverage variability, making it complete enough for an agent to decide on invocation and set expectations.
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 both parameters already described in the schema (identifier as LEI or name, country as optional ISO code). The tool description repeats this and adds no new semantic detail beyond the schema. The example LEI in the schema is sufficient; the description's mention adds little value.
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' with a specific input format and return content (GLEIF data + sanctions screening). It distinguishes itself from sibling tools like get_dd_report by specifying EU/OFAC sanctions and GLEIF coverage, 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 implies when to use this tool: for EU due-diligence on international companies, especially those with LEI codes. It does not explicitly contrast with sibling tools or state exclusions, but the context (EU focus, sanctions, GLEIF) provides clear guidance. The note about Pro Compliance tier and SME limitations also sets usage expectations.
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?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds valuable behavioral context: the two-step lookup (ARES then GLEIF), the return fields (LEI, name, country, confidence), and the GLEIF coverage caveat. This goes beyond the annotations without contradicting them.
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 three sentences with no wasted words. It front-loads the purpose, then concisely explains process, output, and limitations. Every 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?
For a simple single-parameter lookup with no output schema, the description covers all essential aspects: the input type, the step-by-step process, the return fields, the coverage limitation, and the access tier requirement. It is complete for the tool's complexity.
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 provides full coverage of the single parameter 'ico' with description 'Czech IČO — 7 or 8 digits.' The description repeats 'Czech IČO' but adds no extra format or syntax details beyond the schema. Baseline 3 is appropriate given high schema coverage.
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 starts with 'Find the EU/international parent company for a Czech IČO,' which clearly states the verb and resource. It distinguishes itself from sibling tools by detailing the ARES→GLEIF lookup process and the specific output fields.
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 gives clear context: use for finding EU parent companies via ARES and GLEIF. It notes the Pro Compliance tier requirement and the GLEIF coverage limitation for SMEs, which implicitly tells users when not to use the tool. No explicit alternative is named, but the guidance is sufficient.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds what data is returned (score, risk level, flags) and a performance trait ('Faster'), which is consistent with annotations and provides useful context beyond the safety profile.
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: first sentence lists returned fields and frames the tool as lightweight; second gives the usage scenario. Every word earns its place, with no redundancy 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?
For a simple 1-param read-only tool with no output schema, the description covers purpose, output content, and usage context adequately. It could mention error behavior (e.g., invalid ICO) but is largely complete for an agent to select and invoke correctly.
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 the parameter 'ico' already described as 'Czech IČO — 7 or 8 digits.' The description adds no parameter-level detail, so the baseline 3 applies.
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 states a specific verb ('returns') and resource (numeric score 0-100, risk level, red flags), and explicitly distinguishes itself as 'Lightweight version of get_dd_report' while naming a sibling tool. This makes 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?
Explicitly identifies get_dd_report as the alternative and provides a clear usage condition: 'Faster when you only need a yes/no/maybe screen.' This gives strong when-to-use guidance, though it lacks an explicit 'when not to use' clause.
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 declare readOnlyHint and openWorldHint, but the description adds meaningful context: chronological sorting, specific event types, riskScore range (0-100), and tier requirement. It does not contradict annotations and provides more behavioral detail than the annotations alone.
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, front-loaded with the core purpose, and includes only essential details: event types, output shape, tier, and an alternative. No wasted 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 single parameter and no output schema, the description sufficiently conveys the return structure (events[] with riskScore) and the tool's scope. It is complete enough for an agent to select and invoke correctly, though it could mention potential omissions or sources.
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 sole parameter 'ico' is fully described in the schema as 'Czech IČO — 7 or 8 digits', covering 100% of schema descriptions. The description does not need to add further parameter semantics, so baseline 3 applies.
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 builds a chronologically sorted lifecycle timeline for a Czech company and lists the event types included. It differentiates from the richer sibling tool by specifying 'basic events' and pointing to get_risk_timeline_rich for an enriched version.
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 says 'Pro Compliance tier or higher' as a prerequisite and directs users to get_risk_timeline_rich when an enriched timeline is needed. This gives clear when-to-use and when-not-to-use guidance, fulfilling the dimension well.
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?
Annotations only indicate readOnlyHint and openWorldHint. The description adds valuable behavioral context: it is heuristic, noisy by design for common surnames, auto-skips persons with >50 matching companies, and produces a SURNAME_TOO_COMMON note. It does not describe output structure or failure modes, but these are secondary given the strong caveats disclosed.
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 moderately sized but every sentence earns its place: purpose, best-use case, exclusion, alternative, and noise warning are all packed in without redundancy. It is front-loaded with the primary function. Slightly long but justified by the caveats.
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?
Even without an output schema, the description clarifies the tool's scope, limitations, and alternatives, which is essential for correct invocation. It does not describe the return format, but the walk-through nature and the note behavior give enough context for an agent to expect a chain-like result. Missing explicit output details prevent a 5.
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 provides 100% coverage with descriptions for both 'ico' and 'max_depth'. The description adds context about surname-based heuristics and rare surnames, but does not significantly enhance parameter understanding beyond the 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?
The description clearly states the tool performs a 'surname-based heuristic walk through statutory bodies of related Czech companies'. It specifies the exact resource and action, and distinguishes itself from a true UBO source and sibling tools by noting it is best for shell-company unwinding with rare surnames.
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 guidance on when to use ('Best for shell-company unwinding in small s.r.o. with RARE surnames'), when not to use ('NOT a true UBO source'), and names the alternative ('use the ESM'). It also warns about common surnames and the auto-skip behavior, giving clear decision criteria.
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.
v0.3.0detect_address_crowdingdetect_nominee_directordetect_phoenixget_eu_dd_reportget_eu_parentget_risk_timelinev0.1.7get_dd_reportget_risk_scoreget_statutory_chainScored across 9 tools
Each tool targets a distinct niche: full report, light score, statutory chain, nominee detection, phoenix detection, timeline, address crowding, EU report, and EU parent lookup. Even the overlapping get_dd_report and get_risk_score are clearly delineated as a comprehensive vs. lightweight version, preventing confusion.
All tool names follow a consistent verb_noun pattern in snake_case: get_dd_report, get_risk_score, get_statutory_chain, detect_nominee_director, detect_phoenix, get_risk_timeline, detect_address_crowding, get_eu_dd_report, get_eu_parent. Verbs are get/detect, nouns are descriptive, and no mixed conventions appear.
Nine tools form a well-scoped set for the domain of Czech due-diligence and risk analysis. Each tool addresses a distinct analytical need without redundancy, and the count is neither sparse nor overwhelming for an MCP server.
The tool surface covers the full due-diligence lifecycle: comprehensive report, quick risk screening, statutory chain analysis, nominee and phoenix pattern detection, timeline, address crowding, EU cross-border checks, and parent lookup. No critical gap is apparent for the stated purpose of Czech company risk assessment.
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
