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 the server is added with a single command (claude mcp add rejstrik -- uvx rejstrik-mcp), in Codex with one block in ~/.codex/config.toml. After that you can ask in plain language — “analyze the company’s financial performance over the last three years” or “check insolvency, VAT, company management, and subsidies” — and the agent picks the tools it needs on its own.

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.

Where the agent ends and the server begins

The MCP client is the application in which the conversation with the model runs — Claude Code, Codex, or another supported client. It understands the question, decides on the next step, and calls the tools. The server is a locally launched Python package. It contains no model of its own: it accepts precisely defined requests, communicates with the registries, works with documents, and returns structured data.

The keyless design follows from that. The server needs no access of its own to a model API, because reading the document is done by the model already running in the client. That removes the need for a second account, a second bill, and a second place to deal with model capabilities.

The typical flow is short. The agent finds the company via ARES. The server loads the Collection of Deeds and downloads the financial statement. The client reads the PDF — the text layer, or images of scanned pages. The agent transcribes the values into the FinancialStatement schema, including the period, the unit, and the numbers of the source pages. The server normalizes the units and computes the ratios, the IN05 index, trends, and warning signals.

The server therefore doesn’t need an OCR service or a vector database. That doesn’t mean AI has disappeared from the process — the model is still the one 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. A unit test is blind to the second kind.

That’s why tests over stored samples run without a network on every push, while a separate weekly canary probes the real portals and opens an issue if both fail. It isn’t one thing vaguely labeled CI/CD: the first is continuous integration, the second is operational monitoring. The difference is in what each one actually claims — and for a tool built over public registries, it’s honest to be clear about what’s verified offline and what’s been checked against the real world.

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.