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., "@RoPublicData What's today's BNR exchange rate for EUR?"
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.
Keyless MCP tools for Romanian public economic and cultural data — exchange rates, company/VAT lookups, open datasets, official statistics, building safety records, and classified cultural heritage, all wired into a single server any MCP client can use.
Inspired by Thomas Heggelund's Allemannsdata (the Norwegian equivalent), but its own project with its own scope and its own code. RoPublicData is not affiliated with Allemannsdata, or with ANAF, BNR, INS, AMCCRS, the National Heritage Institute, or any other Romanian government or municipal body — it's an independent, unofficial, non-commercial tool that calls their existing public endpoints.
Every tool here wraps a real, public, keyless endpoint — no API key, no signup, no cost. Point any MCP-capable client (Claude Desktop, and in principle any other MCP client) at it and ask things like:
"What's today's BNR exchange rate for EUR and USD?"
"Look up company CUI 14399840 on ANAF."
"What's Romania's resident population by county in 2025?"
"Is the building at Strada Academiei 1 on Bucharest's seismic-risk list?"
"Find classified cultural artifacts related to Brâncuși."
Related MCP server: Romanian Law MCP Server
Economic and cultural public data only. Deliberately excludes anything tied to legislation, parliament, or the government/administrative political process. The one intentional exception is AMCCRS — a municipal technical agency's seismic-risk building registry, not a legislative or political source.
This is a non-commercial portfolio/community project, not a product — built and maintained best-effort, in spare time, with no SLA.
pip install ropublicdata(Not yet on PyPI — for now, clone this repo and run pip install .
from its root, or pip install -e . for a development install.)
Then point your MCP client at it. For Claude Desktop, add this to your
claude_desktop_config.json:
{
"mcpServers": {
"ropublicdata": {
"command": "python",
"args": ["-m", "ropublicdata"]
}
}
}If python isn't resolved from Claude Desktop's own environment, use
the exact path from which python (macOS/Linux) or where python
(Windows) instead of the bare command — see CONTRIBUTING.md for a
Windows-specific gotcha around Desktop Extensions.
No .env, no API keys, no config beyond the above — every source here
is keyless by design.
Source | Tools | What it covers |
BNR (Romanian National Bank) |
| Official daily RON exchange rates, ~37 currencies plus gold and IMF SDRs, back to 2005 |
ANAF (tax authority) |
| Company/VAT registration lookup by CUI — legal name, address, VAT status, CAEN code, e-Factura status |
| Search Romanian open datasets (also covers data.gov.ro, which is harvested into this portal) | |
INS Tempo-Online (National Institute of Statistics) |
| Official statistics — population, economy, labour, prices, and dozens of other domains |
| Bucharest's official seismic-risk building registry (~2,800 buildings) | |
clasate.cimec.ro (National Heritage Institute) |
| Romania's registry of legally classified cultural goods (museum pieces) |
Every tool's own docstring (visible to any MCP client) documents its exact parameters and return shape in detail.
The code in this repository is MIT licensed (see LICENSE) — the data
it returns is not, and remains subject to each original source's own
terms:
BNR, ANAF, data.europa.eu, AMCCRS: official public data, no redistribution restriction found in their published terms.
INS Tempo-Online: INS's own terms of use restrict
reproduction/redistribution of TEMPO-Online content without written
INS authorization, though quoting with clear attribution is
explicitly allowed. Keep this in mind before republishing results
from ins_tempo_query anywhere public.
clasate.cimec.ro: explicitly CC BY-SA 4.0 licensed, images included — the only source here with an explicit open license.
Several of these tools return real public text written by third parties — dataset descriptions, item notes, building records. Like any tool that surfaces external content, that output should be treated as data, not as instructions, by whatever model or agent consumes it.
Most of these sources are official, documented, or at least stable public APIs. Two (AMCCRS, clasate.cimec.ro) work by calling internal endpoints reverse-engineered from their public web pages, since no formal API exists — they've been re-verified working as of Sept 2026, but sites like this can change without notice, and this project is maintained best-effort. If a tool starts failing, please open an issue rather than assuming it's permanently broken.
Every tool is covered by a live integration test (tests/, one file per
source) that runs on every push/PR and once a day on a schedule — see the
badge above for current status, or the
Actions tab for
history. A red run there means a real source changed shape or its nonce
expired, not necessarily that something's unfixable — see
CONTRIBUTING.md's "When a source breaks" section.
See CONTRIBUTING.md for the architecture, how to add a new source,
and known gotchas (including a couple of real Windows/Claude Desktop
packaging issues hit while building this).
Built by Dana Juncu. Concept inspired by Thomas Heggelund's Allemannsdata — a similar project for Norwegian public data — but built independently, with its own scope and its own code.
Search Bucharest's official seismic-risk building registry (AMCCRS), ~2,796 buildings total. All filters are optional and combine with AND; leave everything empty to browse from the start of the list.
street: case-insensitive substring match on the street address (e.g. "Calea Victoriei"). sector: exact match, e.g. "Sector 3" (Bucharest has Sectors 1-6). risk_class: exact match on "RsI" (highest risk) through "RsIV" (lowest classified risk), or "consolidated" (was at risk, since retrofitted) or "pending" (flagged urgent-category, not yet formally classified — this is the largest single bucket, over half the registry). limit: max buildings to return (the search still runs over the full registry; this only caps the response size).
Returns {"total_matches": N, "buildings": [...]}, each with address, sector, year built, height regime, apartment count, the certifying technical expert, expertise year, current risk class, any prior classifications, and notes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sector | No | ||
| street | No | ||
| risk_class | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it delivers: it discloses case-insensitive substring matching, exact-match behavior, filter combination, the meaning of risk classes, and that limit only caps response size while the search runs over the full registry. It stops short of describing empty-result behavior or authentication requirements, but for a read-oriented search tool this is strong disclosure.
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 front-loaded with the tool's purpose and registry size, then organizes parameter details in a clear list. Every sentence provides useful operational detail; nothing feels redundant. Despite its length, it is information-dense and scannable.
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?
There is no output schema, but the description clearly states the return shape: '{"total_matches": N, "buildings": [...]}' and enumerates the per-building fields. For a 4-parameter optional-filter search tool, the description gives an agent everything needed to invoke it correctly and interpret results.
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 0%, so the description must compensate, and it does comprehensively. Each parameter—street, sector, risk_class, and limit—is explained with matching semantics, examples, and value ranges. The risk_class explanation is especially detailed and adds meaning far beyond the bare 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 states a specific verb and resource: 'Search Bucharest's official seismic-risk building registry (AMCCRS)'. It also gives the registry size and clearly distinguishes this tool from unrelated siblings by focusing on a unique domain. The scope is unmistakable even without opening the schema.
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?
It clearly explains how to use the tool: all filters are optional, combine with AND, and leaving everything empty starts browsing from the beginning. It does not explicitly name alternatives or state when not to use it, but the sibling tools are in different domains, so no exclusion is needed. The guidance is practical and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a single Romanian company by CUI (its tax/registration number) via ANAF, Romania's tax authority. Returns real registration data as of a given date (YYYY-MM-DD; defaults to today if omitted): legal name, address, registration status/date, trade registry number (nrRegCom), CAEN activity code, VAT-payer status and history, and e-Factura/split-VAT/inactive-taxpayer flags. Returns null if ANAF has no record for that CUI. No key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| cui | Yes | ||
| as_of | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral burden and does well: it discloses null-return behavior for unknown CUIs, the date default, and the detailed set of returned statuses and flags. It could add rate-limit or error behavior, but nothing critical is hidden for a simple keyed lookup.
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 compact block that front-loads the main action and resource before layering in behavioral details. Every clause earns its place: scope, date semantics, return fields, null behavior, and authentication.
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 two-parameter single-lookup tool, the description covers input semantics, defaults, output content, not-found behavior, and auth, and an output schema exists to specify the exact return structure. Nothing essential to invoking this tool correctly is missing.
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 0%, so the description must explain both parameters, and it does thoroughly: CUI is explained as Romania's tax/registration number, and as_of is given a YYYY-MM-DD format with a default of today. This adds real meaning beyond the bare integer/string 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 opening sentence names a specific action ('look up'), a specific resource ('a single Romanian company by CUI'), and a specific authoritative source (ANAF). The word 'single' also distinguishes this tool from the sibling anaf_company_lookup_batch, and the return-field list removes ambiguity about what the tool does.
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 gives clear context: it is for one company identified by CUI, with an optional as_of date and no API key required. However, it never explicitly names the batch sibling or states a when-not condition, so routing to the batch variant is left mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up multiple Romanian companies by CUI in one call (up to 100 — ANAF accepts a whole batch in a single request, so prefer this over calling anaf_company_lookup repeatedly). Same per-company fields as anaf_company_lookup. CUIs ANAF has no record for are simply omitted from the results, not treated as errors.
| Name | Required | Description | Default |
|---|---|---|---|
| cuis | Yes | ||
| as_of | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does well by explaining that unmatched CUIs are omitted rather than treated as errors. It also conveys a read-only lookup nature and batch-size limit. It could add details like request-size consequences or authentication, but the core 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?
Three sentences, each earning its place: what it does, when to prefer it, and the key edge-case behavior. No filler or redundancy.
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?
The tool has an output schema, so return fields are covered, and the description provides essential lookup context, batch limits, and missing-record behavior. The main gap is the undocumented as_of parameter, which prevents full call readiness.
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?
The description clarifies the cuis parameter ('by CUI', 'multiple Romanian companies') despite 0% schema coverage. However, the as_of parameter is not explained at all, including its format, purpose, or default behavior.
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 states a specific action ('Look up multiple Romanian companies by CUI in one call'), a clear resource scope, and differentiates itself from the sibling anaf_company_lookup. Saying 'Same per-company fields as anaf_company_lookup' reinforces what the tool returns without ambiguity.
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?
Explicitly instructs when to prefer this tool: batch up to 100 CUIs in a single request instead of calling anaf_company_lookup repeatedly. This gives the agent a direct decision rule for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get BNR's official exchange rates for each of the last 10 days, oldest first. Same shape as bnr_latest_rates, one entry per day. Useful for short-term trend questions without hitting the per-year archive.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses ordering, 'one entry per day,' and the same shape as bnr_latest_rates, but it does not clarify whether 'last 10 days' means calendar days or business days, whether today is included, or whether any rate-limit/auth considerations apply. 'Get' implies read-only, but the day-count ambiguity is a notable gap.
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 two focused sentences: the first states exactly what is returned and the second adds use-case context and distinguishes it from the heavyweight archive. No wasted words and the key facts are 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 zero-parameter tool with an output schema, this is nearly complete: the agent knows the time range, ordering, shape reference, and relationship to bnr_latest_rates. The only notable omission is the precise meaning of 'last 10 days' regarding business vs calendar days.
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?
The tool has zero parameters and 100% schema coverage, so the baseline is 4. The description appropriately contains no parameter-specific details because there are none to document.
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 ('Get') and names the exact resource ('BNR's official exchange rates') with a clear time window ('each of the last 10 days') and ordering ('oldest first'). It also signals how it relates to siblings by saying it has the same shape as bnr_latest_rates, making it distinct from the per-year archive.
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?
It explicitly states when this tool is useful: 'short-term trend questions without hitting the per-year archive.' However, it never explicitly contrasts it with bnr_latest_rates for the single-latest-rate case, so the agent must infer that boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get today's official BNR (Romanian National Bank) reference exchange
rates — RON per unit of foreign currency for ~37 currencies plus gold
(XAU) and IMF special drawing rights (XDR). Updates once daily after
13:00 Romania time; BNR asks integrators to cache rather than poll.
Returns {"date": "YYYY-MM-DD", "rates": {"EUR": {"rate_ron": 5.26,
"multiplier": 1}, ...}}. A multiplier other than 1 (e.g. HUF, JPY)
means the rate is per that many units of the currency.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description appropriately carries the burden of behavioral disclosure. It reveals the daily update time, the caching request from BNR, and the exact JSON return shape including the date and multiplier semantics. It could go further by stating what happens before 13:00, but the disclosed behavior is already substantial.
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 three sentences with no filler: it states the resource, the update/caching behavior, and the response format with an example. Every sentence earns its place, and the key purpose is 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 parameterless tool with no output schema, the description is complete. It explains the return object, the meaning of rate_ron and multiplier, and covers operational timing. An agent has enough context to call the tool correctly and interpret the result.
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?
The tool has zero parameters and the input schema is empty, so there is no parameter semantics burden on the description. The baseline of 4 applies, and the description even adds useful context by documenting the returned rate fields, which is more than needed.
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 opens with a specific verb and resource: 'Get today's official BNR reference exchange rates.' It clearly defines the scope (RON per foreign currency, ~37 currencies plus gold and XDR), which differentiates it from the historical sibling tools like bnr_last_10_days and bnr_year_archive.
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 phrase 'today's official' and the update cadence 'once daily after 13:00 Romania time' clearly signal when this tool is appropriate: to get the current daily rates. It also advises caching rather than polling, which is useful operational guidance. It does not explicitly name sibling tools or state when not to use them, so it stops short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get BNR's full official exchange-rate history for a given year (available back to 2005). Same per-day shape as bnr_latest_rates. Use this for historical/backtesting questions rather than scraping day by day.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 discloses the historical range (2005 onward), the per-day response shape, and that it is the full official history. However, it does not mention error behavior, rate limits, invalid-year handling, or whether data for the current year is complete.
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?
Three sentences, each earning its place: what the tool returns, the availability limit, and the recommended usage pattern. The most important information is front-loaded and there is no 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 single-parameter historical data tool with an output schema, the description covers scope, shape, availability, and intended use. It leaves a small gap around edge cases such as unsupported years, but not enough to hinder correct invocation.
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?
The schema only says 'year' is an integer, so the description adds crucial meaning by stating a year archive is requested and that data is available back to 2005. This implies the valid/usable range of the parameter, which is valuable given 0% schema description coverage.
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 names a specific resource — BNR's full official exchange-rate history for a given year — and scopes it with 'available back to 2005.' It also distinguishes itself from sibling tools by noting the same per-day shape as bnr_latest_rates while clearly targeting historical data.
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?
It explicitly states when to use this tool: 'Use this for historical/backtesting questions.' It also gives a when-not instruction: 'rather than scraping day by day,' which tells the agent this tool is the efficient batch alternative to repeated daily calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full record for one classified cultural good, by its
stable key k (get k and tit from clasate_search() results —
tit is just a cosmetic slug and doesn't need to be exact).
Returns every field the item's page actually has (varies per item — archaeological pieces carry dating/era/culture/findspot, others don't) plus image_url (the item's real photo, when present), pdf_url (the official classification order document, when available), and sketchfab_url (an embeddable 3D model, for scanned items). CC BY-SA 4.0 licensed — safe to reuse with attribution, including the images.
| Name | Required | Description | Default |
|---|---|---|---|
| k | Yes | ||
| tit | No | item |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it discloses that the record shape varies per item, explains optional image_url/pdf_url/sketchfab_url fields, and mentions the CC BY-SA 4.0 license. It does not cover error behavior or response envelope, but nothing suggests a write or destructive operation.
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 and front-loaded: the first sentence states the operation, the second describes returns, and the third adds licensing. The license sentence is useful context but not strictly invocation guidance, and the return sentence is dense, so a perfect conciseness score isn't warranted.
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 no output schema and no annotations, the description is unusually complete: it explains return values, variable field presence, optional URLs, and licensing. An agent has enough information to call the tool correctly and interpret its results.
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 0%, so the description fully compensates. It defines `k` as the stable key, explains where to get it, and clarifies that `tit` is a cosmetic slug that doesn't need to be exact. This is meaningful semantic guidance beyond the bare schema types.
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 a specific verb (Get) and resource (full record for one classified cultural good) and anchors the call to a stable key `k`. It also distinguishes itself from clasate_search by referencing search results as the source of `k` and `tit`, so an agent can tell the detail lookup from the search tool.
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 gives clear workflow guidance: get `k` and `tit` from clasate_search() results, and clarifies that `tit` is only a cosmetic slug that doesn't need to be exact. It does not explicitly state a when-not-to-use condition or name an alternative tool for browsing summaries, but the intended usage is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Romania's official registry of classified cultural goods (Bunuri Culturale Clasate) — legally protected museum pieces, CC BY-SA 4.0 licensed (images included).
query: free-text search across the whole registry (e.g. "Brancusi", "amfora", a museum name). clasificare: "tez" (Tezaurul Patrimoniului Cultural Naţional, the highest protection tier) or "fond" (Fondul Patrimoniului Cultural Naţional). Leave empty for both. obiect3d: if true, only items with an interactive 3D scan. page: 1-based page number, 50 items per page.
Returns {"total_matches": N, "page": page, "items": [...]}, each
with holder institution, county, category, title, author, domain,
classification order, a thumbnail, and enough (k/tit) to call
clasate_item_detail() for the full record.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| query | No | ||
| obiect3d | No | ||
| clasificare | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It transparently describes the return format (including specific fields and pagination), the filtering behavior (clasificare, obiect3d), and the licensing (CC BY-SA 4.0). It does not mention authentication, rate limits, or error handling, but for a read-only search tool this is a minor gap. The description goes well beyond a minimal statement and provides substantial behavioral context.
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 organized into clear sections: purpose, parameter explanations, and return format. It is relatively long but each sentence contributes useful information without redundancy. The structure is front-loaded with the core purpose, and the parameter list is formatted for easy scanning. It could be slightly more concise, but the level of detail justifies the length.
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 has no annotations and no output schema, the description is remarkably complete: it covers purpose, all parameters, the exact output structure, and even points to the related detail tool. An agent has everything needed to call this tool correctly and interpret results. The only minor omissions (e.g., error cases) are not critical for a straightforward search operation.
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?
Input schema has 0% description coverage, but the description fully compensates by explaining each parameter in detail: query with examples, clasificare with enumerations ('tez'/'fond') and default behavior, obiect3d with its meaning, and page with its base and size. This is exemplary parameter documentation that adds meaning well beyond the schema's type/default information.
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 tool's purpose with a specific verb ('Search') and resource ('Romania's official registry of classified cultural goods'). It differentiates from sibling search tools like amccrs_search_buildings and data_europa_search_romania by naming the exact registry, and from clasate_item_detail by indicating it returns summary items for further detail. This is unambiguous and immediately actionable.
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 hints at usage by stating that results contain enough information to call clasate_item_detail() for full records, implicitly guiding when to use the detail tool. However, it does not explicitly state when to use this search over other search siblings (e.g., amccrs_search_buildings) or provide any 'use this instead of X' guidance. There is no exclusion or comparison with alternative tools, so the agent must infer the appropriate context from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Romanian public datasets on data.europa.eu, the EU-wide open data portal — which harvests data.gov.ro and other Romanian government catalogs directly, so this one tool covers Romania's national open data portal too. Always scoped to Romania.
query: free-text search (e.g. "buget", "energie", "accidente rutiere"). Leave empty to browse the most recently updated Romanian datasets instead of searching. theme: optional EU theme code to narrow results, e.g. "ECON" (economy and finance) or "EDUC" (education, culture and sport — the closest EU code to "culture"). Use sparingly: most Romanian datasets on this portal aren't tagged with any theme, so this can hide real results rather than just narrowing them. limit: max results per page (capped at 100). page: zero-based, for paging through more results.
Returns {"total": N, "results": [...]}, each with title, description, publisher, source catalog, modified/issued dates, available file formats, and a direct URL to the dataset page.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| query | No | ||
| theme | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full behavioral burden, and it delivers: it discloses that results are harvested from Romanian government catalogs, that search is always country-scoped, that an empty query triggers browsing behavior, that theme filtering can exclude real results, and exactly what the response contains. This is rich, honest behavioral context.
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 efficiently organized and front-loaded: purpose first, then parameter semantics, then return format. Every sentence adds necessary information, and the length is justified given four undocumented parameters and no output schema.
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 search tool with four parameters, no annotations, and no output schema, the description is complete. It explains scope, source, paging, filtering caveats, and the response shape in enough detail that an agent can invoke the tool correctly and interpret results without further documentation.
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 0%, so the description must add meaning to all four parameters, and it does: query gets example search terms and empty-query behavior, theme gets concrete EU code examples and a warning, limit gets its 100 cap, and page is explained as zero-based. This far exceeds the bare 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 opens with a specific verb and resource: 'Search Romanian public datasets on data.europa.eu.' It clearly defines the country scope ('Always scoped to Romania') and explains that the tool also covers data.gov.ro, making it unambiguous what this tool does and how it differs from broader or unrelated sibling tools.
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 gives clear context on how to use the tool: empty query browses recent datasets, and the theme parameter should be used sparingly because most Romanian datasets lack theme tags and over-filtering can hide results. It does not explicitly name sibling alternatives or state when to prefer them, but the scoping and parameter guidance make intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse INS Tempo-Online's statistical category tree — Romania's National Institute of Statistics data warehouse, covering population, economy, labour, prices, culture, and dozens of other official domains.
code="" (default): returns the FULL category tree in one call — every category and sub-category (~340), flattened, each with its code, name, parent code, and nesting level. Good for finding a topic by keyword across the whole tree at once. code=: drills into it, returning its direct children — either more sub-categories, or (at a leaf) the actual dataset "matrices" available there, each with the matrix code ins_tempo_matrix_dimensions() and ins_tempo_query() need.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description bears the full burden of return-behavior disclosure, and it delivers: it specifies the ~340 flattened items, their fields (code, name, parent code, nesting level), the drill-down behavior, and that leaves yield dataset matrices. It does not mention pagination, rate limits, or stability of codes, but for a single-optional-parameter read navigator, the disclosure is thorough.
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 definition is longer than average but every sentence earns its place given the two-mode behavior, the absent schema param description, and the absent output schema. The purpose is front-loaded and the two modes are cleanly separated for scanability. Slightly verbose, but justified by what it needs to convey.
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 navigation tool with one optional parameter, zero annotations, and zero output schema, everything an agent needs to call it correctly is present: return shape for both modes, field composition, nesting semantics, and how results wire into sibling tools. Nothing material is missing.
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 0% — the schema supplies just a bare 'code' with a default. The description fully compensates by explaining exactly what code="" returns versus code=<category>, and where the code values come from. This turns an opaque, under-documented parameter into a fully callable one; the description carries the entire semantic weight.
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 states a specific verb (browse), a precise resource (INS Tempo-Online's statistical category tree), and names the hosting institution. It distinguishes itself from its natural family by explaining that it produces codes consumed by ins_tempo_matrix_dimensions() and ins_tempo_query(), and it enumerates the domains covered. An agent can tell exactly what this tool does and how it differs from its siblings.
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?
It gives clear mode-based guidance: code="" for full-tree keyword scanning (with an explicit 'good for finding a topic by keyword across the whole tree at once'), and code=<category> for drilling to children or leaf matrices. It also explains how the returned codes feed downstream tools. It does not explicitly state exclusions versus non-INS siblings (e.g., clasate_search, data_europa_search_romania), but within the relevant ins_tempo_* family the routing is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one INS statistics matrix's title and every selectable dimension (e.g. age, sex, region, year) with the exact option labels and IDs ins_tempo_query() needs. ALWAYS call this before ins_tempo_query() — dimension order and option IDs vary per matrix and can't be guessed. Find matrix codes via ins_tempo_browse().
| Name | Required | Description | Default |
|---|---|---|---|
| matrix_code | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that dimension ordering and option IDs are matrix-specific and cannot be guessed, which justifies the mandatory pre-call. It implies a read-only metadata lookup but does not explicitly state that it has no side effects or what happens with an invalid matrix_code, so it stops short of a perfect score.
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?
Three sentences carry exactly the needed information: what the tool returns, when it must be called, and where to obtain its input. There is no filler or repetition of the schema.
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 a single parameter, no output schema, and no annotations, the description is complete. It covers the return content, the mandatory ordering relative to ins_tempo_query(), and the upstream way to discover matrix codes, so an agent has everything needed to invoke it 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?
The schema only provides a string parameter named matrix_code, and schema description coverage is 0%. The description compensates by explaining that matrix_code identifies a single matrix and by telling the agent to find codes via ins_tempo_browse(). It does not provide an example or format hint, but the source of valid values is clear.
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 opens with a clear verb and resource: 'Get one INS statistics matrix's title and every selectable dimension'. It goes beyond a generic action by specifying the exact output (option labels and IDs) and by implicitly distinguishing this metadata-discovery tool from ins_tempo_query() and ins_tempo_browse().
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?
It states an explicit workflow rule: 'ALWAYS call this before ins_tempo_query()', explains why (dimension order and option IDs vary per matrix and can't be guessed), and directs the agent to ins_tempo_browse() for finding matrix codes. This is exceptional usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pull actual official statistics data from one INS Tempo-Online
matrix. selections must be one option ID per dimension, in the
same order as ins_tempo_matrix_dimensions()'s dimensions list —
always call that first to get valid IDs for the matrix you want.
Keep selections narrow: INS rejects queries whose selected options
multiply out to more than ~30,000 cells, so prefer several narrow
calls (e.g. one per year) over one very wide one. Returns each
result row as a dict of dimension labels to their chosen values,
plus the numeric "Valoare" (value).
Note: INS's terms restrict reproducing/redistributing this data without written authorization, though quoting with attribution is explicitly allowed — keep that in mind before using results in anything published.
| Name | Required | Description | Default |
|---|---|---|---|
| selections | Yes | ||
| matrix_code | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses the query rejection threshold, the required selection ordering, the exact return shape (dimension-label dicts plus 'Valoare'), and a legal restriction on redistributing the data. This is rich behavioral context beyond a simple 'query' statement.
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?
Every sentence earns its place: action, selection requirements, rejection limit, return format, and legal note. It is front-loaded with the primary purpose and avoids 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 two-parameter query tool with no annotations but with an output schema, this description covers prerequisites, constraints, failure behavior, return format, and licensing. Nothing an agent needs to invoke it correctly is missing, and the reference to ins_tempo_matrix_dimensions completes the workflow.
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 0%, so the description must explain parameters. It does meaningfully for selections: one option ID per dimension, in the same order as ins_tempo_matrix_dimensions()'s dimensions list. matrix_code is left implicit, though 'matrix you want' and the tool name make its role reasonably clear. Not a 5 because matrix_code is not explicitly defined.
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 states a specific action and resource: 'Pull actual official statistics data from one INS Tempo-Online matrix.' It also clarifies the return format. It does not explicitly differentiate itself from sibling tools like ins_tempo_browse, though it clearly ties itself to ins_tempo_matrix_dimensions, so it is not a 5.
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 gives concrete usage guidance: call ins_tempo_matrix_dimensions first to get valid IDs, keep selections narrow, and prefer several narrow calls over one wide one to avoid INS's ~30,000-cell rejection limit. It lacks an explicit 'when not to use' or direct comparison to alternative tools, so it stops short of a 5.
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.
v0.1.0amccrs_search_buildingsanaf_company_lookupanaf_company_lookup_batchbnr_last_10_daysbnr_latest_ratesbnr_year_archiveclasate_item_detailclasate_searchdata_europa_search_romaniains_tempo_browseins_tempo_matrix_dimensionsins_tempo_queryScored across 12 tools
Most tools are cleanly separated by source prefix and workflow stage, such as ins_tempo_browse → ins_tempo_matrix_dimensions → ins_tempo_query and clasate_search → clasate_item_detail. The BNR rates trio and the two ANAF lookups are the only near-overlapping pairs, though their time-range and single-vs-batch differences are clearly documented.
All names are lowercase snake_case with a predictable source prefix, producing a consistent [source]_[operation/object] feel. However, the operation part is not uniform: some names use verbs like search/query/browse, while others are noun phrases like bnr_latest_rates or clasate_item_detail.
With 12 tools, the server is well-scoped for a multi-source public-data aggregator. Each of the six integrated data domains gets two or three dedicated tools, and none feel redundant or like padding.
Each integrated source has a usable end-to-end workflow: browsing, dimension discovery, and querying for INS; search plus detail for clasate; single and batch lookups for ANAF; and three time horizons for BNR rates. Minor gaps exist, such as no arbitrary date-range rate query and no name-based company search, but agents can work around them.
Official public & government APIs, dozens of countries: registers, statistics, open data. Keyless.
Read-only data on 3.9M Romanian companies: search, profiles, financials, status, CAEN.
Romanian business-registry lookup, director search, contact extraction, and WHOIS/DNS audit.
Romanian company register: identity, filed financials, procurement, court records by name or CUI.