Jan Faller

Published 2026-06-25

rejstrik-mcp: Czech Company Registries for AI Agents

How I built a keyless MCP server that gives agents access to Czech registries, annual reports in PDF, and deterministic financial analysis.

When you vet a Czech company by hand, you keep switching back and forth between ARES, the Collection of Deeds, and other public registries. First you have to correctly identify the entity, then find the specific filing, download the PDF, read the financial statements, compare several years, and only at the end assemble a picture of what’s going on inside the company.

Yet the data itself is public. The problem is the path to it. Some of the information is available as a structured response from a registry, but the financial figures often remain only in the annual report in PDF format — sometimes with a text layer, other times as scanned pages. When comparing several years you also have to watch the units, because one statement may report whole korunas and another thousands of korunas.

That’s exactly why rejstrik-mcp came about: not as yet another website over the registries, but as an open integration layer for AI agents. Claude Code, Codex, or another MCP client can search for a company, download its filed documents, read them, and use the server for checks and calculations.

In Claude Code all it takes is:

claude mcp add rejstrik -- uvx rejstrik-mcp

In Codex the same package can be added to ~/.codex/config.toml:

[mcp_servers.rejstrik]
command = "uvx"
args = ["rejstrik-mcp"]

Then you can ask in plain language:

  • “Find the company by name and show its latest financial statements.”
  • “Analyze the company’s financial performance over the last three years.”
  • “Check insolvency, VAT, company management, subsidies, and contracts from the Contracts Registry.”

The agent picks the tools it needs on its own and assembles their results into an answer. The user doesn’t have to learn another interface or manually go around the individual registries.

Where the project came from

This direction already made sense to me during the development of obchodnirejstrik-ai. There it turned out that the path from a company name, through public registries and filed documents, to validated financial data isn’t just one feature of the product. It’s a standalone integration layer that can also be used in other applications.

So with rejstrik-mcp I didn’t copy the whole product. I separated out the more general part: access to the Czech registries, working with the Collection of Deeds, handing documents over to the agent, and deterministic calculations. obchodnirejstrik-ai builds a finished report for the end user over similar data, whereas rejstrik-mcp provides building blocks for any agent or other application.

Why MCP and not just a skill

A skill is primarily a reusable workflow. It can explain to the agent in what order to search for documents, which figures to copy from a statement, or how to interpret the result. But the actual problem with rejstrik-mcp wasn’t just instructions. The agent needed tools that actually call the registries, download the PDF, and always perform the same calculations over structured inputs.

MCP provides a shared contract for this part. A tool has a name, precisely described parameters, and a response structure. The same server can thus be used by multiple supported clients, and a fix to a parser or a calculation stays in one place. A skill on top of MCP could go on to describe the recommended procedure for the whole analysis, but without the integration layer it would mainly be a set of instructions and local scripts.

These approaches therefore don’t exclude each other. MCP gives the agent capabilities, and a skill can decide how best to combine them. For the most common scenarios rejstrik-mcp already offers the built-in prompts analyze-company and company-health-check, which walk the client through the whole procedure.

What is the client and what is the server

In this project the MCP client is the application in which the conversation with the model runs — for example Claude Code or Codex. The client understands the question, decides on the next step, and calls the available tools. In the installation shown, the MCP server is the locally launched Python package rejstrik-mcp. It contains no AI model of its own; it accepts precisely defined requests, communicates with the registries, works with documents, and returns structured data.

The server exposes thirteen tools in three groups:

  • finding a company and documents: find_company, list_filings, get_filing, read_filing_text, and read_filing_page_images;
  • analysis and presentation of the result: analyze_financials, estimate_valuation, and render_card;
  • other public checks: check_insolvency, get_statutory_bodies, check_vat, get_subsidies, and get_contracts.

For example, the client calls find_company, gets the company ID from the response, and then finds the available financial statements via list_filings. The server downloads the selected PDF and returns the path to the file. The client reads the document and sends the values it found back into analyze_financials. The server normalizes them and returns calculations, trends, and risk signals. In this flow MCP is the shared language between the application with the model and the Python that handles the data and the math.

Without a key there’s no fallback mode

The first versions of the project had two modes. Alongside the basic keyless use, the server could — once OPENAI_API_KEY or ANTHROPIC_API_KEY was set — call a model itself and extract information from documents. This branch gradually added dependencies, configuration, and a second place where model capabilities and cost had to be dealt with.

In version 0.8.0 I removed it. The current server is exclusively keyless: it neither needs nor accepts any key to a model API. The document is read by the model the MCP client already uses, and the server does only the work that is meant to be repeatable and verifiable.

A typical flow looks like this:

  1. The agent searches for the company by name or company ID via ARES.
  2. The server loads the Collection of Deeds and downloads the selected financial statement.
  3. The client reads the local PDF, the text layer, or images of scanned pages.
  4. The agent transcribes the values into the FinancialStatement schema, including the period, the unit, and the numbers of the source pages.
  5. The server normalizes the units and computes the ratios, the IN05 index, trends, and warning signals.
  6. It returns the result as structured data, Markdown, or an interactive card in the MCP Apps format.

The server therefore doesn’t need an OCR service, a vector database, or a hidden model layer. This doesn’t mean AI has disappeared from the process. The model is still useful for reading varied documents and explaining the result; it just doesn’t run under a second account inside the server.

What is computed deterministically

The agent reads the accounting values from the document, but the financial math itself doesn’t arise as free-form text from the model. The server checks the statement’s declared unit, converts the values to a common scale, and can flag a suspicious thousand-fold difference between years.

Over the normalized data it computes liquidity, indebtedness, profitability, margins, asset turnover, interest coverage, multi-year trends, and the IN05 index. It can also prepare an indicative valuation based on book value, capitalized earnings, and a sector EV/EBITDA multiple from Damodaran Europe data. The valuation is only indicative and is not an investment recommendation.

Alongside the financial statements the agent can check insolvency, VAT payer registration and reliability, statutory bodies, received state subsidies, and contracts from the Contracts Registry. The resulting report can be displayed as an interactive card in clients that support MCP Apps, or as a regular text overview.

What makes the project different

Chytrý rejstřík offers a ready-made commercial database, a website, an API, and its own MCP over a wide range of preprocessed company data. It’s suitable for users who want a managed service, monitoring, and a broader business database; remote access uses a login token, a paid plan, and daily limits.

The open-source project cz-agents-mcp, in turn, covers ARES, insolvency, VAT, sanctions, foreign registries, and other KYC/AML scenarios. I adapted some of the registry clients from this project, with attribution.

The distinction of rejstrik-mcp therefore isn’t that it’s the only one to give agents access to Czech registries. It’s in the specific path to the actually filed accounting documents: the server finds and downloads the PDF from the Collection of Deeds, exposes the text or images of its pages, and performs a keyless financial analysis over the values read by the model. The project doesn’t compete on the breadth of the database, but tries to go deeper, from the registry all the way to the original document.

Ordinary tests aren’t enough

With public registries there are two distinct kinds of failure. The first arises inside the project: a bug in a parser, a calculation, or a schema. The second comes from outside: the operator changes the interface, moves the portal, or starts blocking automated requests.

Regular CI therefore runs on every push and pull request without a network, over stored samples of responses. It checks formatting, parsers, the service layer, financial calculations, the command line, and the registration of the MCP tools. Thanks to this the test results don’t depend on the momentary availability of the state systems.

Alongside that, a separate canary test runs every Monday at 6:00 UTC. It verifies both the new and the older portal of the Collection of Deeds and fails only when neither responds. In that case GitHub Actions automatically opens or updates an issue. This test doesn’t confirm the correctness of all data in all registries; it’s a narrow operational signal that at least one path to the filed documents still works.

Before a release a broader live test can be run manually. It verifies searching for a company via ARES, listing filings, downloading a PDF, live insolvency and VAT checks, and creating a report over test statements. A separate release procedure then, after a tag is created, builds the package and publishes it to PyPI and a GitHub Release.

So it isn’t one thing vaguely labeled CI/CD. The offline tests are continuous integration, the weekly canary is operational monitoring, and the automation over the version tag handles releases.

What I learned

The hardest part of the project wasn’t adding as many AI features as possible. What mattered more was drawing the boundary correctly between the model and ordinary software. The model reads varied documents well and can explain their contents. But company identification, working with units, financial formulas, access to the registries, and behavior on error need firm rules and tests.

Equally important was accepting that integrating public data isn’t work that’s finished once and for all. The registries change even when the project’s source code hasn’t changed. That’s why, alongside unit tests, you need to watch the real live sources as well and openly distinguish between what we test offline and what we’ve verified against the real world.

That, for me, is the main point of rejstrik-mcp. It’s not another layer of “AI magic” over public data, but an auditable interface between the agent, the original documents, and deterministic computation. The source code is public under the MIT license on GitHub.