normi

Analyze Purchasing Power

analyze_purchasing_power

Read-only

Price-to-income ratio: how many years of median income to buy the median property here. Median sale price (same sales as analyze_market_statistics: no VEFA, 1 % €/m² trim) over INSEE Filosofi commune-level median income.

REQUIRED: You MUST provide one of:

code_postal (e.g., "75011")
commune (e.g., "LYON", "PARIS 11" - uppercase)
code_commune: explicit 5-digit INSEE code (e.g., "75111")

NOT SUPPORTED: code_departement alone, or latitude+longitude — a department spans hundreds of communes with no single meaningful income figure, and radius circles cross commune boundaries. Use analyze_market_statistics or find_property_comparables for those scopes instead.

Returns: ratio_prix_revenu (years of income), prix_bien_median, revenu_median_annuel_uc, annee_reference, vintage_gap_years (sale year minus income year: older income inflates the ratio). ratio_prix_revenu is null when INSEE suppresses the commune's income figure (small population).

Cost: 5 credits per call

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": "analyze_purchasing_power"
  }
}

Input Schema

Name	Required	Description
`commune`	No	Commune name in uppercase (e.g., 'LYON', 'PARIS 15')
`date_fin`	No	End date (YYYY-MM-DD)
`date_debut`	No	Start date (YYYY-MM-DD) — subject to an auto-applied cap on large scopes
`type_local`	No	Property type filter (default: all)
`code_postal`	No	Postal code (e.g., '75011')
`code_commune`	No	5-digit INSEE commune code — bypasses commune resolution (e.g., '75111')

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 24, 2026

TDQS

A4.9/5.0

Behavior5/5

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the description is free to add operational context it alone can supply: a 5-credit cost per call, the vintage_gap_years caveat that older income inflates the ratio, and the null-return behavior when INSEE suppresses a small commune's income figure. These are exactly the traits that change how an agent should interpret and budget the call.

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

Conciseness5/5

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

The metric definition is front-loaded in the first line, followed by compressed sections for scope requirements, exclusions, return shape, and cost. Every parenthetical (VEFA exclusion, trim, vintage-gap sign) carries decision-relevant information rather than filler.

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 no output schema, the description compensates by enumerating the returned fields (ratio_prix_revenu, prix_bien_median, revenu_median_annuel_uc, annee_reference, vintage_gap_years) and their null semantics. Combined with the scope rules, cost, and data-source caveats, an agent has everything needed to call and interpret this tool correctly.

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 the baseline is 3, but the description adds semantics the schema cannot express: that the three location parameters are mutually exclusive alternatives (the schema has no oneOf), that code_commune bypasses commune resolution, and that uppercase formatting matters for commune names. It does not explain date_debut, date_fin, or type_local, but those are self-documented in 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 description names a specific derived metric (price-to-income ratio in years of median income) and defines both inputs precisely: median sale price computed identically to analyze_market_statistics (no VEFA, 1% €/m² trim) over INSEE Filosofi commune-level median income. An agent can tell exactly what it will get and how it differs from the statistics sibling.

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?

It states the requirement explicitly ('You MUST provide one of' with three enumerated alternatives and examples) and, more unusually, spells out what is NOT supported ('code_departement alone, or latitude+longitude'), giving the reason and naming the sibling tools to use instead. This is the when/when-not/alternative pattern at its fullest.

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

All normi 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.

Resources

Need Help?