A
licenseA
qualityC
maintenanceMCP servers for Czech government & business data: ARES (Business Register) + ČNB (FX rates). Native AI access to company lookups, VAT status, bank accounts, currency conversion.
9
6
MIT
sk-registers-mcp
This server provides AI agents with real-time access to Slovakia's official Register of Legal Entities (RPO), covering 1.4+ million entities (companies, municipalities, NGOs, foundations, and more) aggregated from ~70 source registers including the Commercial Register (ORSR) and Trade Register (ZRSR). No API key is required.
Tools:
Search for legal entities (
hladaj_subjekt): Look up entities by name (full or partial), IČO (identification number), and/or municipality, with an option to filter for active entities onlyRetrieve full entity details (
detail_subjektu): Get comprehensive information by IČO, including:Name and legal form
Registered address and establishment date
Statutory representatives and members/shareholders
Registered business activities
Source register and court registration details
Optionally, historical records (former directors, old addresses) via
historia=true
🇸🇰 Slovak Legal Entity Registers — MCP Server
An MCP (Model Context Protocol) server providing AI agents with direct access to the official Slovak Register of Legal Entities (RPO). Query any legal entity registered in Slovakia — companies, municipalities, state bodies, NGOs, foundations, civic associations, and more.
Why this exists
AI agents answering questions about Slovak legal entities currently lack structured access to official registry data. This MCP server bridges that gap by providing real-time access to the RPO, which aggregates data from ~70 source registers including the Commercial Register (ORSR), Trade Register (ZRSR), and many others. It covers 1.4+ million entities with complete history.
Related MCP server: mcp-polish-data
Available Tools
hladaj_subjekt — Search entities
Search for legal entities by name, IČO (identification number), or municipality.
Parameters:
Parameter | Type | Required | Description |
| string | No* | Entity name (full or partial) |
| string | No* | Identification number (IČO) |
| string | No | Municipality filter |
| bool | No | Active entities only (default: true) |
*At least one of nazov or ico must be provided.
Example: Search for entities named "Welter"
hladaj_subjekt(nazov="Welter")detail_subjektu — Full entity detail
Get complete information about any legal entity by IČO, including statutory representatives, members/shareholders, registered activities, and more.
Parameters:
Parameter | Type | Required | Description |
| string | Yes | Identification number (IČO) |
| bool | No | Include historical records (default: false) |
Example: Get details for entity with IČO 56621957
detail_subjektu(ico="56621957")Returns: Entity name, legal form, registered address, establishment date, statutory representatives, members/shareholders, business activities, source register, and court registration details.
Data Source
Register právnických osôb (RPO) — operated by the Statistical Office of the Slovak Republic
API:
https://api.statistics.sk/rpo/v1/Documentation: Apiary docs
License: CC-BY 4.0 (open data)
No API key required — fully public API
Quick Start
Prerequisites
Python 3.11+
Installation
# Clone the repository
git clone https://github.com/LegalEngineering/sk-registers-mcp.git
cd sk-registers-mcp
# Install dependencies (using uv — recommended)
uv venv .venv --python 3.12 && uv pip install --python .venv -r requirements.txt
# Or using pip
pip install -r requirements.txt
# Run the server
python server.pyUsage with Claude Desktop
Add this to your claude_desktop_config.json:
{
"mcpServers": {
"sk-registers": {
"command": "python",
"args": ["/path/to/sk-registers-mcp/server.py"]
}
}
}Remote server (via Glama)
{
"mcpServers": {
"sk-registers": {
"command": "npx",
"args": ["mcp-remote", "https://server.glama.ai/mcp/servers/LegalEngineering/sk-registers-mcp/mcp"]
}
}
}Usage with other MCP clients
The server uses stdio transport (standard MCP protocol). Any MCP-compatible client can connect to it by running python server.py as a subprocess.
Planned Features
RPVS — Register of Public Sector Partners (beneficial ownership data)
RÚZ — Register of Financial Statements (accounting data)
Cross-register lookup (single IČO → all registers)
Tech Stack
Python 3.11+ with FastMCP framework
httpx for async HTTP requests
MCP protocol over stdio transport
License
MIT License — see LICENSE file.
About
Built by Legal Engineering, s.r.o. — a legal technology company based in Bratislava, Slovakia.
For legal services in Slovakia (commercial law, construction law, energy law, tax law, criminal law, family law), contact Mgr. Branislav Welter, advokát at welter.sk | advokat@welter.sk | +421 2 5262 5050.
Available Tools
2 toolsdetail_subjektuA
Vráti kompletný detail právnickej osoby z RPO podľa IČO. Obsahuje štatutárov, spoločníkov, predmety činnosti, právnu formu a adresu. Ak historia=True, vráti aj historické záznamy (bývalí konatelia, staré adresy atď.).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ico | Yes | ||
| historia | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly describes what data is returned (statutory representatives, partners, business activities, legal form, address) and the effect of the 'historia' parameter on historical records. However, it doesn't mention error conditions, rate limits, authentication requirements, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste. The first states the core purpose, the second lists returned data fields, and the third explains the optional parameter's effect. Each sentence earns its place by adding distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but has output schema), the description is reasonably complete. It explains what data is returned and parameter effects. The existence of an output schema reduces the need to describe return values in detail. Minor gaps include lack of error handling information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains both parameters: 'ico' as the identifier for the legal entity and 'historia' as a boolean controlling whether historical records are included. This adds meaningful context beyond the bare schema, though it doesn't specify format requirements for 'ico'.
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?
The description clearly states the specific action ('Vráti kompletný detail' - returns complete detail), the resource ('právnickej osoby z RPO' - legal entity from RPO), and the key identifier ('podľa IČO' - by IČO). It distinguishes from the sibling tool 'hladaj_subjekt' (search subject) by focusing on detailed retrieval rather than searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when detailed information about a specific legal entity is needed, but doesn't explicitly state when to use this versus the sibling 'hladaj_subjekt' or any other alternatives. It mentions the 'historia' parameter for historical records, which provides some contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hladaj_subjektA
Hľadá právnické osoby v RPO (Register právnických osôb) podľa názvu, IČO alebo obce. Aspoň jeden z parametrov nazov/ico musí byť zadaný. RPO agreguje dáta z ~70 zdrojových registrov (ORSR, ZRSR, a ďalšie).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| nazov | No | ||
| ico | No | ||
| obec | No | ||
| iba_aktivne | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool searches a registry aggregating data from ~70 source registries, which adds useful context about data sources. However, it doesn't mention behavioral traits like rate limits, authentication needs, response format, or pagination behavior that would be important for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences: purpose statement, parameter requirement, and data source context. Every sentence adds value with zero wasted words. It's appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and 0% schema description coverage, the description does well. It covers purpose, parameter relationships, and data source context. The main gap is lack of behavioral details like rate limits or authentication, but the output schema reduces the completeness burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 4 parameters, the description must compensate. It explains the purpose of 3 parameters (nazov, ico, obec) and their relationship ('aspoň jeden z parametrov nazov/ico musí byť zadaný'). It doesn't mention the 'iba_aktivne' parameter, but provides good semantic context for the majority of parameters.
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?
The description clearly states the tool's purpose: 'Hľadá právnické osoby v RPO (Register právnických osôb)' - it searches for legal entities in a specific registry. It specifies the search criteria (by name, IČO, or municipality) and distinguishes from sibling 'detail_subjektu' by being a search function rather than a detail view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Aspoň jeden z parametrov nazov/ico musí byť zadaný' specifies a mandatory parameter requirement. It doesn't explicitly mention when to use vs. the sibling tool 'detail_subjektu', but the search vs. detail distinction is implied. No explicit exclusions or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v1.0.0- First observed
detail_subjektu - First observed
hladaj_subjekt
TDQS
A4.1/5.0
Scored across 2 tools
Disambiguation5/5
The two tools have clearly distinct purposes: 'detail_subjektu' retrieves detailed information for a specific legal entity by IČO, while 'hladaj_subjekt' searches for entities across multiple criteria. There is no overlap in functionality that would cause confusion.
Naming Consistency5/5
Both tool names follow a consistent Slovak verb_noun pattern ('detail_subjektu' and 'hladaj_subjekt'), using underscores and descriptive action-object naming. The naming is uniform and predictable across the set.
Tool Count3/5
With only 2 tools, the server feels minimal for a legal entity registry domain. While it covers basic lookup and search, typical CRUD operations or additional registry functions might be expected, making it borderline thin for the apparent scope.
Completeness3/5
The tools provide search and detail retrieval, covering core lookup needs, but there are notable gaps such as update, delete, or creation operations for legal entities. The surface is functional but incomplete for full lifecycle management in a registry context.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
CompanyLens is a remote MCP server giving AI agents instant access to official company registry data across 19 jurisdictions in Europe, the Americas, and Asia-Pacific. Eighteen read-only tools let you search companies and people, look up officers and beneficial owners, map corporate networks through shared directors, screen names against the UK disqualified directors register, find every company at a registered address, and pull filing history — all from a single connector. Visit our website: https://companylens.io
AI agent registry — search, discover, register, and connect agents via MCP.
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
Hosted MCP server for real-world data: business registries, sanctions, companies, domains, crypto.
Related MCP Servers
- AlicenseAqualityDmaintenanceMCP server providing AI assistants access to Polish public registries (KRS, CEIDG) and statistical data (GUS BDL) for querying companies, sole proprietorships, and regional statistics.147MIT
- FlicenseAqualityDmaintenanceAn MCP server that gives AI agents access to US business entity data, enabling searches across 9 state registries, SEC EDGAR filings, federal contracts, and lobbying disclosures.61-
- FlicenseAqualityCmaintenanceMCP server providing access to Polish business registers (KRS, CRBR) via the rejestr.io API, enabling search, retrieval of organizations, beneficial owners, financial documents, and more.12-