Click on "Deploy 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., "@ariregister-mcp search the e-Business Register for Bolt and show its registry code"
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 Estonian e-Business Register (Äriregister, run by RIK) (API docs). Use it to look up Estonian companies, their people and representation rights, annual reports, and e-invoice readiness from Claude or any other MCP client.
Built on the MCP TypeScript SDK v2 (@modelcontextprotocol/server). It serves the 2026-07-28 protocol revision and still works with clients on the 2025 revisions.
Uses the stdio transport. It needs Node.js 20 or newer.
Every tool is read-only.
The register has three access levels, and each tool needs one of them.
Tool | What it does | Needs |
| Find companies by name, part of a name, or registry code (up to 10 matches, with status, address and page URL) | – |
| Check whether up to 100 companies accept e-invoices, and through which operator | – |
| Full company data: general data, related persons, commercial pledges, rulings, registry cards | API key |
| Filtered company search by name, EMTAK activity, location, status, or a related person or company | API key |
| Who may represent a company, and whether they can act alone | API key |
| Filed annual reports with revenue, balance-sheet total, employees, audit status and file links | API key |
| A company's beneficial owners. The data is restricted and every lookup is logged | API key + legal basis |
| The register of trusts and the people involved | API key |
| Annual report line items (balance sheet, income statement, …) for this year and the previous one | XML login |
| Documents in a company's public file (annual report PDF/XBRL, articles) with download URLs | XML login |
| Code lists (legal forms, statuses, roles, countries, …) | XML login |
| Any other XML service query, e.g. daily change lists, entries and rulings, revenue by activity | XML login |
–: public. search_companies uses the register's autocomplete API. check_einvoice_recipients uses the XML service's e-invoice query, which RIK serves without a contract.
API key: the REST API at https://ar-rest.rik.ee (OpenAPI; a copy is in spec/). The server trades the key for a bearer token at /keyLogin/, caches the token, and logs in again when the token expires.
XML login: the SOAP service at https://ariregxmlv6.rik.ee. It takes the contract's username and password inside each request. It's only used for queries the REST API doesn't cover.
Related MCP server: finnish-company-mcp-server
The public tools work without any setup. For the others:
Sign the API contract at https://ariregister.rik.ee/eng/contract. RIK takes about 5 working days to review it. A contract that covers only the API services is free.
For the REST tools, create an API key in your e-Business Register account (instructions).
For the XML tools, use the username and password that come with the contract.
You can set the credentials as environment variables in your MCP client config. On macOS you can store them in the Keychain instead, so they're never written into a config file:
security add-generic-password -U -s ariregister-api-key -a api-key -w # REST API key (prompts for it)
security add-generic-password -U -s ariregister-xml -a <username> -w # XML service password (prompts for it)Environment variables take precedence over the Keychain.
Claude Code
claude mcp add -s user ariregister -- npx -y github:aanndryyyy/ariregister-mcp
# or, with credentials in the config instead of the Keychain:
claude mcp add -s user ariregister -e ARIREGISTER_API_KEY=xxx -e ARIREGISTER_USERNAME=xxx -e ARIREGISTER_PASSWORD=xxx -- npx -y github:aanndryyyy/ariregister-mcpClaude Desktop, Cursor, and other clients using mcpServers JSON
{
"mcpServers": {
"ariregister": {
"command": "npx",
"args": ["-y", "github:aanndryyyy/ariregister-mcp"],
"env": { "ARIREGISTER_API_KEY": "xxx", "ARIREGISTER_USERNAME": "xxx", "ARIREGISTER_PASSWORD": "xxx" }
}
}
}Leave out env if the credentials are in the Keychain, or entirely if you only need the public tools.
From a local clone
git clone https://github.com/aanndryyyy/ariregister-mcp.git
cd ariregister-mcp && npm install # builds dist/ automatically
claude mcp add -s user ariregister -- node "$PWD/dist/index.js"Variable | Default | Purpose |
| – | REST API key (Keychain fallback: service |
| – | XML service login (Keychain fallback: service |
|
| Override the REST base URL |
|
| Override the XML service URL, e.g. |
"What's the registry code of Arbictus OÜ, and is it still active?"
"Can these five companies receive e-invoices?"
"Who's on the management board of 14663023, and can they sign alone?"
"Show the balance sheet and income statement from their 2025 annual report."
"Which companies list Jaan Tamm as a board member?"
Beneficial owners. RIK only gives this data to requesters with a legal basis, and it logs each lookup with the requester's identity. get_beneficial_owners requires the requester's own name and identity-code country. The tool description tells the model to ask you for these details and never to guess them.
Language. Classifier texts (statuses, roles, legal forms) default to English. Pass language: "est" for Estonian. Company status codes: R = registered, L = in liquidation, N = bankrupt, K = deleted.
Limits. RIK allows 50 000 queries a day per contract and per key, one XML query at a time, and 20 document downloads a minute per IP. The server sends XML queries one at a time.
XML quirks. The XML service rejects a request that leaves out a field it requires, even when the docs give that field a default. xml_service_request passes your body through as is, so check the query's documentation page.
Structured output. Every tool declares an outputSchema and returns structuredContent, with the same JSON as text.
Bulk data. For whole-register analysis, use RIK's daily open data files (CC BY 4.0) instead of per-company queries.
npm install
npm run build
npx @modelcontextprotocol/inspector node dist/index.js # interactive testing
# End-to-end smoke test against the live register. It's read-only. Tools without credentials must return
# CREDENTIALS_MISSING; set the env vars (or HAS_KEYCHAIN_REST=1 / HAS_KEYCHAIN_XML=1) to run them for real.
npm test
PROTOCOL=legacy npm test # 2025-era protocolMIT
Check whether companies are in the e-invoice recipient register, i.e. whether you can send them a machine-readable e-invoice through an operator. Public, no account needed. Status OK = has a valid link in the e-invoice register (operator in service_provider), MR = registry code not found in the e-invoice register.
Inputs: registry_codes (required), page, include_names. Returns: pages, recipients
Search companies with filters (REST, needs an API key): name, registry code, EMTAK activity code, location, status, or a related person or company (e.g. every company where a person is a board member). Returns contacts, VAT number, address, activities and the matching related persons. Paginated (see total). Company status codes: R = registered, L = in liquidation, N = bankrupt, K = deleted.
Inputs: name, page, language, location, +15 more. Returns: list, total
Line items of a company's annual report: balance sheet, income statement, cash flow and so on, with this year's and the previous year's values (XML service, needs contract username and password). Without year it lists the available reports (year, report code, name). With year and no report_code it returns every report for that year (one query each); pass report_code (from the list) for just one.
Inputs: registry_code (required), year, language, report_code. Returns: year, message, reports, available, +1 more
A company's beneficial owners (REST, needs an API key and a contract that grants beneficial-owner access). This data is restricted: access needs a legal basis (e.g. a competent authority, an obliged entity under the AML act, or a legitimate interest), and RIK logs every lookup together with the requester's identity. The requester fields describe the PERSON MAKING THE QUERY and must be the real user's own details; ask the user for them and never guess or fill them in from other context.
Inputs: registry_code (required), requester_last_name (required), requester_first_name (required), requester_identity_code_countr… Returns: registry_code, beneficial_owners
Code lists used by the register (XML service, needs contract username and password), e.g. OIGVORMID (legal forms), EVSTAATUSED (company statuses), ISIKROLLID (person roles), RIIGID (countries), SIDEVAH (contact types), VALUUTAD (currencies). Use it to decode codes returned by the other tools.
Inputs: classifier (required), language. Returns: classifiers
Full register data for one company (REST, needs an API key). Choose blocks with include: general (names, addresses, legal form, share capital, financial year, contacts, EMTAK activities, VAT number), related_persons (board and council members, shareholders, representation rights), commercial_pledges, rulings (court registry rulings), registry_cards (entries on the registry card). Default: general. Company status codes: R = registered, L = in liquidation, N = bankrupt, K = deleted.
Inputs: registry_code (required), include, language, only_valid. Returns: url, company
Who may represent companies, and how (REST, needs an API key): persons with their role and whether they can act alone (exclusiveRightOfRepresentation), plus special conditions and joint-representation groups. Search by the REPRESENTATIVE: a person's identification code, or a company's registry code with person_type J when the representative is itself a company, or by name. For who can represent a given company, use get_company with include ['related_persons'] instead.
Inputs: page, birthday, language, page_size, +5 more. Returns: list, total
Annual reports filed by a company (REST, needs an API key): year, submission date, revenue, balance-sheet total, employee count, audit status, and links to the report files (PDF, BDOC/DDOC, XBRL). For the actual balance-sheet and income-statement lines use get_annual_report_figures.
Inputs: page, year, language, page_size, +4 more. Returns: list, total
Documents in a company's public file (XML service, needs contract username and password): annual reports as PDF, BDOC/DDOC and XBRL, and articles of association, with their e-Business Register URLs (opening one needs a login there; this tool never requests the paid access token that would buy the document). Document types: A = annual report PDF, D = BDOC/DDOC, X = XBRL, P = articles of association. Report types: A = annual, V = interim, L = liquidation, P = final.
Inputs: registry_code (required), page, year, valid, +2 more. Returns: pages, documents
Find Estonian companies and other legal persons by name, part of a name, or registry code. Public, no account needed. Returns up to 10 matches with registry code, status, legal address and the register page URL; historical names match too. Company status codes: R = registered, L = in liquidation, N = bankrupt, K = deleted.
Inputs: query (required). Returns: results
Search the register of trusts and similar arrangements (REST, needs an API key): trust name, status, country and the people involved (trustee UH.HALDUR, settlor UH.LOOJA, beneficiary UH.SOODUST, …). Beneficial-owner details of a trust are not requested by this tool.
Inputs: page, language, page_size, only_valid, +5 more. Returns: list, total
Call any e-Business Register XML (SOAP) query that has no dedicated tool, e.g. ettevotjaMuudatusedTasuline_v1 (companies changed on a date), kandedMaarused_v1 (entries and rulings for a day), aruandeMyygituluEMTAKjargi_v1 (revenue by activity), detailandmed_v2. Your contract username and password are added automatically. body holds the fields of keha as JSON: arrays repeat an element, objects nest. Field names and required fields are in the per-query docs at https://avaandmed.ariregister.rik.ee/en/open-data-api/introduction-api-services; send them in the order the docs list them. The service rejects a request that leaves out a field it requires, even one with a documented default. The response is the keha element as JSON with all values as text.
Inputs: body (required), operation (required). Returns: response, operation
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 12 tools
Most tools target distinct resources or access modes, but search_companies vs find_companies and list_annual_reports vs list_company_documents vs get_annual_report_figures overlap enough that the agent must read descriptions carefully. The generic xml_service_request is explicitly framed as a fallback, which reduces confusion with the dedicated XML tools. Overall mostly distinct with a few avoidable boundary ambiguities.
All names use snake_case and nearly all follow a verb_noun pattern: search_companies, get_company, find_companies, list_annual_reports, check_einvoice_recipients, etc. The only clear deviation is xml_service_request, which is a noun phrase rather than an action-oriented name. The search/find distinction is intentional but still readable.
Twelve tools is well within the appropriate range for a read-only registry API and each dedicated tool maps to a meaningful capability. The generic XML tool provides an escape hatch without bloating the dedicated surface. The count is well scoped for the server's purpose.
The surface covers the core read-only lifecycle: company search, company details, representation rights, annual reports, documents, beneficial owners, trusts, e-invoice checks and classifiers. However, less common XML operations are only available through the generic xml_service_request, which requires external documentation and exact field ordering, so the dedicated surface is not fully self-contained. Minor gaps remain but can be worked around.
estonia-business-register -- Estonia's e-Business Register, published as open data by RIK…
Estonian companies, EMTAK, grants and tenders from public registers.
Read-only Belgian company search, KBO data, financials, employees and company relationships.
Live data on every Danish company and the people behind it, for due diligence, KYC and research. 20 read-only tools: company search and lookup by name or CVR number, owners and the ownership chain to the ultimate owners, management and board, annual accounts and key figures, the SI-score risk rating, capital events, civil court cases and decisions from public authorities, VAT number checks, and lists of bankruptcy decrees and newly registered companies. Sources: the Danish Business Register (CVR), annual reports, the courts, Statstidende and public authorities. Sign in with a SelskabsInfo account; a free plan is available.
