Skip to main content
Glama

Money value: inflation math from the official CPI

check_inflation
Read-only

Returns inflation math for a country: what an amount from one year is worth in another, the total price change, the average yearly rate and the latest inflation rate. The US series is the Bureau of Labor Statistics CPI-U, monthly, from 1913. Eligible European countries use the monthly Eurostat HICP index; other countries use the World Bank index, yearly. Inputs are amount, from, to, country and optional category. Applies to questions about what an amount from one year is worth in another year, or how prices changed over time. Today's interest rates and pay for a job are outside this result.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "amount": "<amount>",
      "from": "<from>"
    },
    "name": "check_inflation"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoYear or month to convert to; defaults to the latest figure
fromYesYear (1990), or for the US and eligible European countries a month (1990-06)
amountYesAmount in the country's currency (dollars for the US)
countryNoCountry name or two-letter code; defaults to the United States. Amounts are in that country's currency.
categoryNoPrice category; availability depends on country.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / category
      Added value: +{
      +  "description": "Price category; availability depends on country.",
      +  "enum": [
      +    "all",
      +    "food",
      +    "food_home",
      +    "shelter",
      +    "energy",
      +    "medical",
      +    "tuition",
      +    "vehicles"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / from / description
      Previous value: -"Year (1990), or for the US a month (1990-06), the amount is from"New value: +"Year (1990), or for the US and eligible European countries a month (1990-06)"
  2. Changed4 schema fields changed
    • changedInput schema / properties / amount / description
      Previous value: -"Dollar amount"New value: +"Amount in the country's currency (dollars for the US)"
    • addedInput schema / properties / country
      Added value: +{
      +  "description": "Country name or two-letter code; defaults to the United States. Amounts are in that country's currency.",
      +  "maxLength": 60,
      +  "type": "string"
      +}
    • changedInput schema / properties / from / description
      Previous value: -"Year (1990) or month (1990-06) the amount is from"New value: +"Year (1990), or for the US a month (1990-06), the amount is from"
    • changedInput schema / properties / to / description
      Previous value: -"Year or month to convert to; defaults to the latest month"New value: +"Year or month to convert to; defaults to the latest figure"
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover only read-only/open-world/non-destructive, but the description adds substantial behavior the annotations cannot: the exact upstream series (BLS CPI-U monthly from 1913, Eurostat HICP monthly, World Bank yearly elsewhere) and the resulting difference in temporal resolution. It also flags that category availability varies by country, which warns the agent of partial-coverage results rather than a uniform response.

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?

The description is front-loaded with what it returns, then provenance, then applicability and exclusions — a logical order with no filler prose. The one wasted clause is the parameter enumeration, which duplicates schema data the agent already has.

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?

There is no output schema, so the description carries the burden of describing return content, and it does so thoroughly while also covering data provenance and resolution limits. For a five-parameter read-only lookup, nothing an agent needs in order to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3; the description earns an extra point because the source-by-region sentence explains why monthly values are only meaningful for the US and eligible European countries, adding real semantics behind the `from`/`to` format constraint. It loses something by restating the parameter list verbatim ('amount, from, to, country and optional category'), which adds nothing over the schema.

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 first sentence names a specific verb (returns inflation math) and enumerates the concrete outputs: converted value, total price change, average yearly rate, latest rate. It also pins the underlying data sources per region, so an agent can distinguish this from the many other 'check_*' lookup siblings 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.

Usage Guidelines5/5

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

'Applies to questions about what an amount from one year is worth in another year, or how prices changed over time' states the trigger condition, and 'Today's interest rates and pay for a job are outside this result' gives an explicit exclusion that routes to check_rates and check_wage. Both the when and the when-not are present.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources