This server provides read-only access to the Czech e-Sbirka legal database (~92,000 acts) via a SPARQL/RDF endpoint, allowing you to search for and retrieve Czech laws.
Search acts (cz_search): Find acts by publication year and/or citation substring (case-insensitive), with pagination support (up to 500 results per query).
Get act metadata (cz_get_act): Retrieve detailed metadata for a specific act by year and number, including ELI URI, human-readable citation (e.g. 110/2019 Sb.), source URL, latest consolidated version date, and version URI.
Get consolidated text (cz_get_text): Fetch the full consolidated text of an act, assembled from ordered HTML fragments, along with fragment count, byte size, and version date.
Key characteristics:
Every response includes eli_uri, human_readable_citation, and source_url for independent verification, plus dataset_note and eli_note for data provenance transparency.
Data is sourced from the opendata.eselpoint.gov.cz SPARQL endpoint, licensed CC BY 4.0, and updated daily.
No API key required; all operations are read-only.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cz-eli-mcp Get the full text of act 110/2019 Sb."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for the Czech e-Sbirka legal database (e-sbirka.gov.cz), the official
Collection of Laws (Sbirka zakonu), via its open-data SPARQL endpoint. It searches acts and
fetches their full consolidated text, with verifiable citations.
Part of the MateMatic eu-legal-mcp production line - after PL, DE, AT, ES, FI, IE, NL, SE, FR,
LU and DK. Same citation contract, e-Sbirka source. This is the first connector in the line that
talks SPARQL/RDF rather than a REST/XML API.
Scope. This MVP searches acts (by year and/or a citation substring), returns metadata, and assembles the full consolidated text of the latest version. ~92,000 acts, updated daily, licensed CC BY 4.0. Language: Czech. Every response carries a
dataset_note.ELI is national, not data.europa.eu. The act IRI follows the ELI URI template (
eli/cz/sb/{year}/{number}) but is minted by the e-Sbirka open-data graph (opendata.eselpoint.gov.cz), not resolvable ondata.europa.eu. The readable page is one-sbirka.gov.cz. Every response carries aneli_notesaying so.Text is assembled, not a single file. e-Sbirka exposes the consolidated text as ordered HTML fragments over SPARQL;
cz_get_textreconstructs the plain text from them. There is no single official XML/PDF manifestation.
Tool | What it does |
| Find acts by year and/or a citation substring (discovery). |
| Metadata for an act by year + number, plus the latest consolidated version date. |
| Full consolidated text of an act, assembled from the latest version's fragments. |
| Declare what this connector covers, when each family was captured, and - explicitly - what it does NOT cover. Every gap carries a fallback. |
Every response carries the contract: eli_uri (the national ELI IRI, e.g.
https://opendata.eselpoint.gov.cz/esel-esb/eli/cz/sb/2019/110), human_readable_citation
(e.g. 110/2019 Sb.), and source_url (the e-sbirka.gov.cz page).
Related MCP server: Slovak Law MCP Server
Run it with no install step (once published to PyPI):
uvx cz-eli-mcpOr from source:
cd cz-eli-mcp
pip install -e .{
"mcpServers": {
"cz-eli-mcp": { "command": "cz-eli-mcp" }
}
}Smart App Control blocks unsigned executables, which covers uvx.exe, pip.exe
and the cz-eli-mcp.exe launcher that pip writes at install time. The python.exe and
py.exe from the python.org installer are signed by the Python Software
Foundation, so running the module through the interpreter works:
python -m pip install cz-eli-mcp
python -m cz_eli_mcppip.exe is blocked for the same reason, so install with python -m pip, not
pip install. If python is not on PATH, use the Windows launcher: py -3 -m cz_eli_mcp.
{ "mcpServers": { "cz-eli-mcp": { "command": "python", "args": ["-m", "cz_eli_mcp"] } } }Do not turn Smart App Control off to work around this - it cannot be re-enabled without reinstalling Windows.
Environment:
CZ_ELI_ENDPOINT - default https://opendata.eselpoint.gov.cz/sparql
CZ_ELI_CACHE_DIR - default ~/.matematic/cache/cz-eli
CZ_ELI_AUDIT_DIR - default ~/.matematic/audit
No API key. The e-Sbirka open-data SPARQL endpoint is keyless.
Public data only - read-only SPARQL against e-Sbirka; no client data leaves the machine.
Audit log - every tool call appends one JSON line to ~/.matematic/audit/cz-eli-mcp.jsonl.
Vendor-neutral - talks only to opendata.eselpoint.gov.cz; no LLM provider, no telemetry.
Verifiable citations - every response is independently checkable via source_url.
See CONSTITUTION.md and DISCOVERY.md.
pip install -e ".[dev]"
pytest tests/test_instructions_drift.py tests/test_parse.py -v # offline
pytest tests/test_smoke.py -v # hits the live SPARQL endpointApache-2.0. © Matematic Solutions / Wieslaw Mazur. e-Sbirka data is CC BY 4.0 (Czech Ministry of
the Interior); relayed with attribution and a source_url.
Fetch Czech act metadata by year and number.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | e.g. ``2019``. | |
| number | Yes | e.g. ``110``. |
| Name | Required | Description |
|---|---|---|
| year | No | |
| number | No | |
| eli_uri | No | |
| citation | No | |
| eli_note | No | |
| source_url | No | |
| dataset_note | No | |
| version_date | No | |
| latest_version_uri | No | |
| human_readable_citation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds no behavioral traits beyond what is in annotations or schema. It is adequate but does not enhance transparency.
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?
A single, clear sentence that immediately conveys the tool's purpose. 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 simple input schema, output schema existence, and annotations covering behavioral safety, the description is complete enough for an agent to understand and invoke the tool 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%, so baseline is 3. The description restates 'by year and number' but adds no additional meaning or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Fetch), resource (Czech act metadata), and identifiers (year and number). It distinguishes from siblings like cz_get_text and cz_search by specifying 'metadata'.
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 usage when you have year and number, but does not explicitly state when to prefer this over siblings or provide exclusions. The sibling names hint at alternatives, but the description itself lacks guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full consolidated text of a Czech act by year and number.
The text is assembled from the latest consolidated version's ordered HTML fragments.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | e.g. ``2019``. | |
| number | Yes | e.g. ``110``. |
| Name | Required | Description |
|---|---|---|
| year | No | |
| format | No | |
| number | No | |
| content | No | |
| eli_uri | No | |
| citation | No | |
| eli_note | No | |
| byte_size | No | |
| source_url | No | |
| dataset_note | No | |
| version_date | No | |
| fragment_count | No | |
| human_readable_citation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds that the text is assembled from ordered HTML fragments of the latest consolidated version, which provides useful context beyond annotations but does not fully explain behavior like output format or permissions.
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 with two sentences: the first clearly states the purpose, and the second adds a key detail about the assembly. Every sentence earns its place with no fluff.
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 (2 params, output schema present, rich annotations), the description adequately covers what it does and how it works. The presence of an output schema reduces the need to detail return values. It could mention how the text is returned (e.g., plain text or HTML) but that is likely covered by the 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 is 100% (both year and number are described in the input schema). The description does not add any additional meaning or constraints beyond the schema, so it meets the baseline of 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 fetches the full consolidated text of a Czech act by year and number, using a specific verb and resource. However, it does not explicitly differentiate from sibling tools like cz_get_act or cz_search, which could cause confusion.
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?
No guidance is provided on when to use this tool versus the siblings. The description does not include any when-to-use or when-not-to-use advice, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Czech acts by year and/or a citation substring.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | restrict to a publication year, e.g. ``2019``. | |
| limit | No | max hits (1..500, default 50). | |
| offset | No | pagination offset (default 0). | |
| contains | No | substring matched (case-insensitive) against the citation, e.g. ``"110"``. |
| Name | Required | Description |
|---|---|---|
| items | No | |
| total | Yes | |
| dataset_note | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as false, covering the safety and behavior profile. The description does not add any behavioral details beyond the search intent, such as case-insensitive matching or pagination behavior. It is adequate but does not leverage the opportunity to provide 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?
The description is a single concise sentence that front-loads the core purpose: searching Czech acts by year and/or citation substring. No superfluous words; every part 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?
Given the presence of a full output schema, detailed input schema descriptions, and rich annotations, the description is complete enough. It covers what the tool does and the key search criteria, which is sufficient for an agent to decide when to use it.
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 every parameter has a description in the schema. The description reiterates the two primary filtering parameters (year and contains) but does not mention limit or offset. This adds some context by summarizing the main criteria, but does not provide additional semantics 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 action (search), the resource (Czech acts), and the criteria (year and/or citation substring). It distinguishes from sibling tools 'cz_get_act' and 'cz_get_text', which retrieve specific acts or texts, by focusing on search functionality.
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 directly tells the user to use this tool for searching Czech acts by year or citation substring. It implies the primary use case but does not explicitly state when to avoid this tool or when to use siblings instead. The verb 'search' clearly differentiates from 'get' siblings, so guidance is clear but not exhaustive.
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.1.1cz_get_actcz_get_textcz_searchEach tool has a clear, distinct purpose: metadata retrieval, full text retrieval, and search. No overlap or ambiguity.
All tools follow a consistent `cz_verb_noun` pattern in snake_case, making them predictable and easy to understand.
Three tools is well-scoped for a legal acts server, covering the core operations without unnecessary bloat.
The set covers search, metadata, and full text retrieval. A list-all-act function is missing but search can approximate it; otherwise complete for read-only access.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search Swiss federal legislation: laws, articles, amendments via the Fedlex SPARQL endpoint.
Resolve, search and verify legal citations against the official sources, with provenance.
Temporal search and comparison for official Luxembourg and reviewed EU law, with provenance.
Search EU legislation, CJEU case law, and treaties; traverse CELLAR graph; browse EuroVoc concepts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/matematicsolutions/cz-eli-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
