finwire.pl - Polish financial data

Housing demand vs supply and forecasts (finwire)

get_housing_balance

Read-onlyIdempotent

finwire housing balance for Poland and 17 cities: finwire_housing_pressure (new residents per 1 dwelling completed in the same year, from GUS migration for permanent residence and foreigners insured in ZUS, yearly), finwire_housing_pipeline (forecast of dwellings completed in 4 quarters up to 2 years ahead from GUNB building permits, 80% interval and backtest accuracy per horizon) and finwire_rent_forecast (6-month change of asking rent per m2, published only after passing the accuracy threshold). Present forecasts as model estimates with the interval and accuracy, never as certainty.

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_housing_balance"
  }
}

Input Schema

Name	Required	Description	Default
`city`	No	City name or slug (e.g. "Kraków" or "krakow") one of 17 cities; omit for Poland and all cities.

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 4, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already establish this as a safe read-only, idempotent call, so the description's job is to add substance — and it does: data provenance (GUS migration, ZUS-insured foreigners, GUNB permits), forecast horizons (4 quarters to 2 years, 6 months), an 80% interval, per-horizon backtest accuracy, and a publication gate where the rent forecast appears only after passing an accuracy threshold. That publication-gating detail is real behavioral context an agent would not otherwise know.

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

Conciseness4/5

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

Everything stated earns its place — series definitions, sources, horizons, and the interpretation rule. The structure is slightly dense, one long run-on enumeration of the three series with embedded parentheticals, which makes the final caveat easy to skim past, but there is no filler.

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

Completeness4/5

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

An output schema exists, so return values need not be described, and the methodology plus forecast-interpretation rule cover the interpretive risk of model estimates. What is missing is any routing signal relative to the many housing and rent siblings, which matters given how crowded this namespace is.

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% and the single city parameter is fully documented in the schema, including slug format and the omit-for-Poland default. The description only indirectly reinforces this by saying the data covers 'Poland and 17 cities' and never explains the per-city granularity or what happens when city is omitted. Baseline 3 fits.

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

Purpose4/5

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

The description names the resource and spells out the three concrete series returned (housing pressure, pipeline forecast, rent forecast) with units, which lets an agent tell it apart from plain price tools. It never explicitly contrasts itself with close siblings like get_housing_prices, get_rents or get_housing_carry, so the differentiation is implicit rather than stated.

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

Usage Guidelines3/5

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

Usage guidance is limited to an output-handling instruction ('Present forecasts as model estimates with the interval and accuracy, never as certainty'), which is useful but is not tool-selection guidance. There is no statement of when to call this versus get_housing_prices, get_rents or get_housing_carry, leaving the choice to inference.

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.