finwire.pl - Polish financial data

Pension forecast finwire (future ZUS pension)

get_pension_forecast

Read-onlyIdempotent

Model of the first gross ZUS pension in Poland (finwire_pension_forecast) by birth year 1966-2006, profile (k60 = woman retiring at 60, k65 = woman at 65, m65 = man at 65) and wage level (minimalna = minimum wage, mediana = median wage, przecietna = average wage, dwukrotnosc = twice the average): replacement rate vs own last gross wage and vs the average wage, pension in today's money (rate x today's average wage), P10/P50/P90 from thousands of simulations of wage growth and the number of workers. Built from the statutory indexation of the ZUS account and subaccount (real history since 2000), EUROPOP2023 working-age population and life expectancy, the GUS life table and Ministry of Finance wage assumptions; with the effect of the shrinking workforce and of longer life, and OECD and European Commission benchmarks. Without arguments returns the headline (man, average wage, retiring 30 years after the base year). Full career from age 22; a model, not an individual ZUS statement.

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

Input Schema

Name	Required	Description
`profile`	No	k60 woman retiring at 60, k65 woman at 65, m65 man at 65; default m65.
`threshold`	No	Wage level: minimum wage, median, average, twice the average; default przecietna.
`birth_year`	No	Birth year 1966-2006.

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

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered; the description goes further by disclosing the model's inputs and assumptions (statutory indexation, EUROPOP2023, GUS life table, MF wage assumptions), the simulation-based P10/P50/P90 dispersion, and the 'full career from age 22' limitation.

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 core purpose is front-loaded, but the body is a single dense run-on sentence that packs model provenance, output metrics and caveats together. Because an output schema exists, the long enumeration of replacement rates and P10/P50/P90 values is partly redundant and could be trimmed.

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?

For a zero-required-parameter forecasting model with an output schema, the description supplies everything needed to call it correctly: defaults when called bare, the valid birth-year window, the meaning of profiles and wage levels, the model's data sources, and an explicit accuracy caveat.

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 schema already spells out every enum value (k60/k65/m65, minimalna/mediana/przecietna/dwukrotnosc), so the description's restatement of those codes adds little. The one genuine addition is linking the wage-level parameter to what is reported (replacement rate vs own last wage and vs average wage), which is modest beyond the schema baseline.

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 opens with a concrete statement of what is computed: 'Model of the first gross ZUS pension in Poland ... by birth year 1966-2006, profile ... and wage level'. It also delimits the tool ('a model, not an individual ZUS statement'), which separates it from the descriptive pension-statistics siblings such as get_pension_stats.

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?

It states the behaviour with no arguments ('returns the headline: man, average wage, retiring 30 years after the base year'), which implies a quick-look use case, but it never says when to prefer this over get_pension_stats or the other calc_* tools, and gives no explicit when-not guidance beyond the individual-statement caveat.

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.