finwire.pl - Polish financial data

Vehicle registrations in Poland (Ministry of Digital Affairs, CEPiK)

get_vehicle_registrations

Read-onlyIdempotent

First registrations of vehicles in Poland, monthly since 2014, from the Ministry of Digital Affairs files with CEPiK data: passenger cars and all vehicles, 17 vehicle types, provinces per 1000 residents, top passenger-car brands of the month and of 12 months (nationwide or one province) and the share of brands from China by province, with the finwire indices finwire_car_registrations_pulse (12-month passenger cars, change year on year) and finwire_chinese_brands_share. A first registration in Poland covers new cars and used cars imported from abroad. Months with an inconsistent province or type split are held back and listed. For electric cars use get_electric_vehicles.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_vehicle_registrations"
  }
}

Input Schema

Name	Required	Description
`period`	No	Month YYYY-MM of the brand ranking; default latest.
`history`	No	Number of past months in the summary, default 12.
`province`	No	Province TERYT code 02-32 (e.g. 14 = mazowieckie) for the brand ranking; default Poland.

Output Schema

Name	Required	Description	Default
`url`	Yes
`asOf`	No
`data`	No
`title`	Yes
`source`	Yes
`docsUrl`	Yes
`license`	Yes
`summary`	Yes
`citation`	Yes
`datasetId`	Yes
`sourceUrl`	No
`truncated`	No
`serverDate`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds genuinely useful behavior beyond that: a first registration includes used cars imported from abroad (affecting interpretation of counts), and months with an inconsistent province or type split are held back and listed - a data-quality caveat an agent would otherwise not anticipate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the body is a single run-on sentence packed with parenthetical asides and enumerations, which makes it harder to scan than it needs to be. The content is largely worth keeping; the structure is not.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation, and an annotation set already covers the safety profile. Given that, the description supplies everything else that matters: dataset scope, the definitional caveat about imported used cars, the held-back-months behavior, and the named finwire indices.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so period, history and province are already documented, including that province is a TERYT code and applies to the brand ranking. The description reinforces that province/period affect only the brand ranking while the summary covers 12 months, but adds little syntactic meaning beyond the schema - baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb+resource (first registrations of vehicles in Poland, monthly since 2014, from the Ministry of Digital Affairs/CEPiK) and enumerates exactly which series are included (17 vehicle types, provinces per 1000 residents, brand rankings, China share). It also explicitly distinguishes itself from the closest sibling: 'For electric cars use get_electric_vehicles.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It routes the agent away from this tool for electric cars and toward get_electric_vehicles, and the scope statement (monthly since 2014, nationwide or one province) implies when the tool fits. There is no broader when-not-to-use guidance against the other 50+ siblings, but the main overlap is handled.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All finwire.pl - Polish financial data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.