Skip to main content
Glama
Sign In

normi

by io.github.NormiHQ
OverviewDiscussionsAdmin

Get Market Overview

get_market_overview
Read-only

Get a complete market brief for a location in one call — stats + trend + health score.

Bundles three queries in parallel: market statistics (prices, volume), annual price trend (1-year change %), and health score (0–100).

Use this as the first tool for any "how is the market in X?" question. It replaces calling analyze_market_statistics + analyze_price_trends + score_market_health separately (saves 15–25 credits).

REQUIRED: At least one location filter:

  • code_postal (e.g., "75011")

  • commune (e.g., "PARIS 11" — uppercase; Paris uses "PARIS 01"–"PARIS 20")

  • code_departement (e.g., "69")

  • latitude + longitude for radius search

Optional:

  • type_local: "Maison", "Appartement", "Terrain", "Local commercial"

  • radius_m: search radius in meters (default: 500)

Returns:

  • stats: count, median/avg price, price/m², median surface

  • trend: direction (increasing/stable/decreasing), 1-year change %, overall change %

  • health: score (0–100), label (Calme/Modéré/Dynamique/Très actif), data quality Note: health score requires code_postal/commune/code_departement (not available for lat+lon only searches)

Score interpretation: 0–30 Calme · 31–60 Modéré · 61–80 Dynamique · 81–100 Très actif

Cost: 10 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": "get_market_overview"
  }
}

Input Schema

NameRequiredDescriptionDefault
communeNoNom de commune en MAJUSCULES (ex. 'PARIS 11', 'LYON')
latitudeNoLatitude GPS (nécessite longitude)
radius_mNoRayon en mètres (défaut : 500)
longitudeNoLongitude GPS (nécessite latitude)
type_localNoType de bien
code_postalNoCode postal (ex. '75011')
code_departementNoCode département (ex. '75', '69')

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare it as a safe read; the description adds substantial context beyond them: three queries run in parallel, a 10-credit cost, 15–25 credits saved versus the alternatives, and a real functional limitation (health score requires a postal code, commune, or department). The return shape and score interpretation bands are described since no output schema exists.

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?

Front-loaded summary sentence followed by labeled sections (required filters, optional filters, returns, cost) that scan quickly. Slightly over-long: the health label names appear in the returns block and again in the score interpretation line, a minor duplication.

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 7-parameter aggregation tool with no output schema, the description covers cost, required filters, format constraints, return contents, interpretation bands, and a capability caveat. An agent has everything needed to call it correctly and to decide when not to.

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

Parameters5/5

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

Schema coverage is already 100%, yet the description still adds value: it enumerates the location filter options, gives format examples ("75011", "69"), warns that commune must be uppercase with Paris naming as "PARIS 01"–"PARIS 20", and states the radius default of 500m and the latitude+longitude pairing requirement.

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?

States a specific verb and resource ("Get a complete market brief for a location") and immediately enumerates the three bundled outputs (stats, trend, health score). It also distinguishes itself from the three sibling tools it aggregates, so an agent can identify it without opening any 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?

Explicitly says to use it first for any "how is the market in X?" question and names the exact alternatives it replaces (analyze_market_statistics + analyze_price_trends + score_market_health) with a cost rationale. It also gives an explicit when-not condition by noting health score is unavailable for lat+lon-only searches.

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

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