This server gives AI assistants access to Finnish open government data through three MCP tools for company and procurement lookups.
hae_yritystiedot_prh: Look up a Finnish company's basic info (name, business ID, company form, registration date, status) by business ID or name via the PRH/YTJ open API.
hae_julkiset_hankinnat_hilma: Search Hilma's public procurement notices by keyword; returns title, contracting entity, deadline, and direct links to the notice and tender documents. Optional result limit and filter to only open/active notices.
hae_kaupparekisteri_muutokset_prh: Get company basics plus a full timeline of Finnish Trade Register entries, such as board/name changes, financial statements, share capital, bankruptcy, restructuring, or liquidation.
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., "@suomi-mcp Hae YTJ:stä yritys Y-tunnuksella 1629284-5."
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.
Osa datakytkin-projektia. Kokoelma MCP-työkaluja, jotka tuovat suomalaista avointa dataa suoraan tekoälyavustajien käyttöön – ilman selaimessa kikkailua, PDF-latauksia tai leikepöytää.
Paikallisesti ajettava MCP-palvelin (stdio), joka tuo Claude Desktopin (tai muun MCP-yhteensopivan clientin) käyttöön kolme työkalua suomalaisiin avoimen datan rajapintoihin:
Työkalu | Lähde | Mitä tekee |
| PRH / YTJ avoin data ( | Hakee yrityksen perustiedot Y-tunnuksella tai nimellä: nimi, Y-tunnus, yritysmuoto, rekisteröintipäivä, toiminnan tila. |
| Hilma – julkiset hankinnat ( | Hakee avoinna olevat hankintailmoitukset hakusanalla: otsikko, hankintayksikkö, määräaika, suorat linkit ilmoitukseen ja tarjouspyyntöön. |
| PRH – rekisteröidyt ilmoitukset ( | Yrityksen perustiedot + aikajana kaupparekisteriin rekisteröidyistä ilmoituksista: hallitus- ja nimenmuutokset, tilinpäätökset, osakepääoma, konkurssi/saneeraus/selvitystila. Täysi kattavuus. |
PRH: vanha
avoindata.prh.fi/bis/v1on poistettu käytöstä. Tämä palvelin käyttää nykyistä v3-rajapintaa (sama avoin YTJ-yrityshaku, ei API-avainta).Hilma: käytetään Hilman julkista hakurajapintaa, joka ei vaadi avainta. Koko ilmoituksen eForms-XML:n saa erikseen AVP-read-rajapinnasta (ilmainen tilausavain) – sitä ei tässä tarvita.
Vaatii Node.js 18+ polussa (kehitetty ja testattu Node 20:llä).
Lisää Claude Desktopin konfiguraatioon:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"datakytkin": {
"command": "npx",
"args": ["-y", "datakytkin-mcp"]
}
}
}Käynnistä Claude Desktop uudelleen. Ei tarvita erillistä asennusta – npx hakee
paketin npm:stä.
fetch is not definedClaude Desktop käynnistää palvelimen omalla PATH:llaan, ja npx valitsee
#!/usr/bin/env node -rivin kautta ensimmäisen node:n PATH:ssa – usein
vanhan järjestelmä-Noden (esim. v16), josta puuttuu fetch. Vaihda tällöin
suoraan absoluuttiseen Node 18+ -binääriin ja globaaliin asennukseen:
# asenna halutulla Nodella (esim. nvm:n Node 20)
"$(nvm which 20)" "$(dirname "$(nvm which 20)")/npm" install -g datakytkin-mcp
# tulosta polut configia varten:
echo "command: $(nvm which 20)"
echo "entry: $("$(nvm which 20)" "$(dirname "$(nvm which 20)")/npm" root -g)/datakytkin-mcp/dist/index.js"{
"mcpServers": {
"datakytkin": {
"command": "/ABSOLUUTTINEN/POLKU/node/v20.x.x/bin/node",
"args": ["/ABSOLUUTTINEN/POLKU/node/v20.x.x/lib/node_modules/datakytkin-mcp/dist/index.js"]
}
}
}node ajetaan tässä eksplisiittisesti, joten PATH:n vanha Node ei häiritse.
Päivitys: npm install -g datakytkin-mcp@latest samalla Nodella.
Related MCP server: finnish-company-mcp-server
"Hae PRH:sta yrityksen tiedot Y-tunnuksella 1629284-5."
"Etsi Hilmasta avoimet pilvipalveluihin liittyvät hankintailmoitukset, näytä 5."
"Hae YTJ:stä kaikki yritykset joiden nimessä on 'Reaktor' ja listaa Y-tunnukset."
"Näytä Hilmasta it-konsultoinnin tarjouspyynnöt ja niiden määräajat."
"Listaa Y-tunnuksen 1629284-5 viimeisimmät kaupparekisteriin rekisteröidyt muutokset."
"Onko yrityksellä 1234567-8 merkintöjä konkurssista tai saneerauksesta? Milloin hallitus on viimeksi muuttunut?"
git clone https://github.com/datakytkin/suomi-mcp.git
cd suomi-mcp
nvm use 20 # tai: nvm install 20
npm install
npm run typecheck # tarkista että kääntyy
npm run dev # käynnistä palvelin stdio-tilassa (= npx tsx src/index.ts)Palvelin puhuu MCP:tä stdin/stdout-yhteydellä; lokit menevät stderriin.
Käännetty ajo:
npm run build # tuottaa dist/
npm start # = node dist/index.jsUuden työkalun lisääminen: ks. CONTRIBUTING.md.
Claude Desktop -konfiguraatio repo-checkoutista (kehitykseen / omiin muutoksiin):
{
"mcpServers": {
"datakytkin": {
"command": "npx",
"args": ["tsx", "/ABSOLUUTTINEN/POLKU/suomi-mcp/src/index.ts"]
}
}
}datakytkin on itsenäinen avoimen lähdekoodin projekti. Se käyttää PRH:n ja
Hilman julkisia rajapintoja, mutta ei ole PRH:n, Hanselin, Hilman tai minkään
viranomaisen hyväksymä, tukema tai ylläpitämä. Data tulee sellaisenaan lähteestä.
suomi-mcp is part of the datakytkin project: a set of Model Context Protocol tools that bring Finnish open government data straight into AI assistants – no browser tabs, PDF downloads or copy-paste.
A locally run MCP server (stdio) exposing three tools to Claude Desktop (or any MCP-compatible client):
Tool | Source | What it does |
| Finnish Patent and Registration Office (PRH) / Business Information System, open data v3 | Look up a company by Business ID or name: name, Business ID, company form, registration date, status. |
| Hilma – Finnish public procurement notices ( | Search open procurement notices by keyword: title, contracting entity, deadline, direct links to the notice and tender documents. |
| PRH – registered notices open data | Company basics + a timeline of entries registered in the Finnish Trade Register: board and name changes, financial statements, share capital, bankruptcy / restructuring / liquidation. Full coverage. |
Tool names and all output are in Finnish (that is the data's language).
Requires Node.js 18+. Add to your Claude Desktop config
(~/Library/Application Support/Claude/claude_desktop_config.json on macOS,
%APPDATA%\Claude\claude_desktop_config.json on Windows):
{
"mcpServers": {
"datakytkin": {
"command": "npx",
"args": ["-y", "datakytkin-mcp"]
}
}
}Restart Claude Desktop.
Seeing fetch is not defined? Claude Desktop launches the server with its own
PATH, and npx may pick an old system node (e.g. v16) that lacks fetch.
Install globally with a Node 18+ binary and point command straight at it:
npm install -g datakytkin-mcp
npm root -g # entry = <printed path>/datakytkin-mcp/dist/index.js{
"mcpServers": {
"datakytkin": {
"command": "/absolute/path/to/node18+/bin/node",
"args": ["/absolute/path/to/lib/node_modules/datakytkin-mcp/dist/index.js"]
}
}
}datakytkin is an independent open-source project. It consumes public APIs from
PRH and Hilma but is not endorsed, supported or operated by PRH, Hansel, Hilma or
any public authority. Data is served as-is from the source. See
SECURITY.md for notes on the data sources and responsible use.
Hakee julkisia hankintailmoituksia Hilmasta (hankintailmoitukset.fi) hakusanalla. Palauttaa ilmoituksen otsikon, hankintayksikön, tarjousten määräajan ja suorat linkit ilmoitukseen ja tarjouspyyntöasiakirjoihin. Oletuksena vain avoinna olevat ilmoitukset.
| Name | Required | Description | Default |
|---|---|---|---|
| hakusana | Yes | Vapaa hakusana, esim. "it-konsultointi", "pilvipalvelut", "siivous", "rakennusurakka". | |
| max_tulokset | No | Palautettavien ilmoitusten enimmäismäärä (oletus 5). | |
| vain_aktiiviset | No | Jos true (oletus), näytetään vain ilmoitukset joiden tarjousten määräaika ei ole umpeutunut. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and covers the core behavioral traits: it searches, returns specific fields, and defaults to open notices only. It does not disclose rate limits, authentication needs, or error behavior, but these are less critical for a read-oriented search tool where the main behavior is transparent.
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 exactly two sentences: the first states the action and output in a compact list, and the second states the default filter. Every word earns its place; there is no repetition or filler.
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?
For a simple search tool with three well-documented parameters and no output schema, the description is adequately complete: it names the source, the returned fields, and the default behavior. Minor omissions like pagination or empty-result handling don't prevent an agent from invoking 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% with detailed parameter descriptions already present, including examples for hakusana, min/max for max_tulokset, and the default/effect for vain_aktiiviset. The description adds no new parameter semantics beyond restating the default open-notice filter, so the baseline score of 3 applies.
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 uses a specific verb ('Hakee' - searches) and resource ('julkisia hankintailmoituksia Hilmasta'), then enumerates the exact returned fields: title, procurement unit, tender deadline, and direct links. This clearly distinguishes it from the sibling tool hae_yritystiedot_prh, which covers company data from PRH.
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 clearly conveys when to use it: when the user needs Finnish public procurement notices from Hilma, with explicit expectations about the returned information. It doesn't explicitly name the sibling or state exclusions, but the domain difference from PRH company searches is self-evident, so the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hakee suomalaisen yrityksen perustiedot PRH:n avoimesta YTJ-rajapinnasta. Anna joko Y-tunnus (1234567-8) tai yrityksen nimi. Palauttaa nimen, Y-tunnuksen, yritysmuodon, rekisteröintipäivän ja toiminnan tilan.
| Name | Required | Description | Default |
|---|---|---|---|
| hakusana | Yes | Y-tunnus muodossa 1234567-8 TAI yrityksen nimi / sen osa (esim. "Reaktor"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the disclosure burden. It clearly indicates a read operation and lists returned fields, but it does not explain behavior for no matches, multiple matches, invalid input, or error responses.
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?
Two compact sentences with no filler: the first states the action and source, the second gives input guidance and output summary. It is well-structured and front-loaded.
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?
For a simple one-parameter lookup with no output schema, the description sufficiently explains input constraints and expected return fields. It is slightly incomplete regarding multi-result and not-found behavior, but remains adequate for correct invocation in normal cases.
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 description coverage is 100%, and the schema already documents hakusana with format, examples, and accepted alternatives. The description reinforces the parameter's meaning but adds little beyond the schema, so the baseline of 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?
Description states a specific verb and resource: 'Hakee suomalaisen yrityksen perustiedot PRH:n avoimesta YTJ-rajapinnasta', and lists concrete return fields. It is clearly distinct from the sibling procurement tool hae_julkiset_hankinnat_hilma.
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?
Clear usage context is provided: fetch Finnish company basic data using either Y-tunnus or company name. It does not explicitly discuss when not to use it or name alternatives, but the sibling tool is unrelated, so selection is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools target completely distinct resources: one fetches Finnish company information from PRH/Ytj, the other retrieves public procurement notices from Hilma. There is no overlap or ambiguity between them.
Both tools follow the consistent pattern 'hae_<target>_<source>' (hae_yritystiedot_prh, hae_julkiset_hankinnat_hilma). The Finnish verb 'hae' (fetch/search) and underscore-separated names create a clear uniform convention.
With only two tools, the server feels very thin. It is borderline on the scale: the two tools are individually useful, but the small count suggests the server is either highly niche or has unrealized potential. It does not feel excessively bloated, but it barely covers an 'entire dataset'.
The server name 'suomi-mcp' implies a broader Finnish data provider, yet only company information and procurement notices are covered. There are significant gaps: no address lookup, tax records, population data, legislation, or other common Finnish open data sources. At least a search/fetch pattern is consistent, but the surface is far from complete for a country-wide dataset.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Agent-native API for Finnish public company data via YTJ. Pay-per-call $0.01 USDC over x402.
Finnish Patent and Registration Office (PRH) — YTJ open data MCP.
Hilma MCP — Finnish government public procurement notices (keyed).
Official company and director data: search, profiles, filings, and name normalization.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/datakytkin/suomi-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
