Bloki.si

How often property changes hands

market_activity

Read-onlyIdempotent

Report how OFTEN property changes hands in an area — the counterpart to market_stats, which says what it costs. INPUT: an area ref from find_area, or omit area for the national figures. Four segments are kept apart because business space churns FASTEST to let and SLOWEST to sell; a single 'commercial' rate would hide that. READ: n_events and n_stock beside every per_1000_per_year, and check thin. NEVER: read activity as a price level. It says nothing about what anything costs. THEN: it answers in municipalities where market_stats is silent for want of comparables.

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

Input Schema

Name	Required	Description	Default
`area`	No
`segment`	No

Output Schema

Name	Required	Description	Default
`as_of`	Yes
`level`	Yes
`caveats`	Yes
`area_eid`	Yes
`segments`	Yes
`area_name`	Yes
`window_to`	Yes
`window_from`	Yes
`window_is_settled`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 1, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already carry readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real interpretive behavior the annotations cannot: read `n_events` and `n_stock` beside `per_1000_per_year` and check `thin`, plus the warning not to conflate turnover with price. It stops short of stating caveats like rounding or coverage limits, keeping it at 4.

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?

Front-loaded purpose followed by labelled INPUT/READ/NEVER/THEN blocks; each line adds a distinct instruction (routing, interpretation, a hard caveat, a use case) and none is redundant padding.

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?

An output schema exists, so return values need not be explained, and the description instead supplies the interpretation rules an agent needs (`thin`, sample-size companions) plus the price-vs-activity boundary. Nothing essential to calling or reading the tool 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 0%, so the description must carry the params and it largely does: `area` is defined as a ref from find_area or omitted for national figures, and `segment` is motivated by the explanation that four segments are kept apart because churn rates differ wildly. The actual enum values are left to the schema, so it does not fully compensate for zero coverage.

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 ('Report how OFTEN property changes hands in an area') and explicitly positions itself against the sibling market_stats as the counterpart that measures turnover rather than cost. An agent can distinguish it from market_stats and price_index without opening either 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?

Gives explicit input routing ('an area `ref` from find_area, or omit `area` for the national figures'), an explicit exclusion ('NEVER read activity as a price level'), and a use-case where it beats the alternative ('answers in municipalities where market_stats is silent for want of comparables'). When-to-use, when-not, and the alternative are all named.

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

All Bloki.si 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?