MarketCode

Count and summarise a search by group

search_summary

Read-onlyIdempotent

Counts and statistics over EXACTLY what search_entities would match: how many records, grouped by a field, with min, median, mean and max of up to three numeric fields. Use it for "how many", "what share", "median floor area" and "price by type" questions instead of paging through records.

`query` is the same object `search_entities` takes (entity, geography, criteria). Summaries cover `properties`, `buildings`, `land` and `listings`. `group_by` is one choice field of that family and `measures` are its range fields; `entity_search_capabilities` lists them under `summary.families`. For example properties: group_by asset_subtype / asset_class / tenure / epc, measures bedrooms / floor_area; listings: group_by property_type / channel / auction / new_home, measures price / bedrooms / floor_area; buildings (a postcode district or a drawn area): group_by tenure / epc, measures footprint / storeys / units; land: group_by tenure, measures parcel_area / built_coverage.

Example: {"query": {"entity": "listings", "geography": {"kind": "area", "id": "SW11"}, "criteria": {"transaction": ["sale"]}}, "group_by": "property_type", "measures": ["price"]}.

A measure's `count` is the records that have a value for it; missing values are never zero. Groups come largest first, `top` of them (max 50), each with its `share` of the total. No record identities are returned: open records with `search_entities`. Too wide a place (a region) or too slow a summary is refused with what to narrow. Transaction counts by area: `market_volume_series`. Free.

Input Schema

Name	Required	Description	Default
`top`	No
`query`	Yes
`group_by`	No
`measures`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, but the description adds substantial context: missing values are never zero, groups are ordered largest first, `top` is capped at 50, each group includes its share of the total, no record identities are returned, and overly wide/slow requests are refused with narrowing guidance.

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 purpose is front-loaded in the first sentence, followed by parameter guidance, a compact example, and behavioral constraints. Despite its length, every sentence adds necessary information for a complex grouped-statistics tool with no top-level parameter descriptions.

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?

The description covers the input shape, supported entity families, grouping/measure semantics, ordering and top limits, refusal behavior, and alternatives, while the output schema handles return details. It is complete enough for an agent to invoke the tool correctly.

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?

Top-level schema description coverage is reported as 0%, so the description carries the burden and does so well: it explains that `query` is the same object `search_entities` takes, that `group_by` is one choice field of the family and `measures` are its range fields, where `entity_search_capabilities` lists them, that `top` is capped at 50, and it provides a concrete example. It also clarifies the `count` semantics for measures.

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 states a precise verb and resource: counts and statistics over exactly what `search_entities` would match, grouped by a field, with min/median/mean/max of numeric measures. It explicitly distinguishes itself from `search_entities` (records) and `market_volume_series` (transaction counts by area), so an agent can route correctly 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?

It names concrete question types ("how many", "what share", "median floor area", "price by type") and says to use this instead of paging through records. It also names alternatives for adjacent needs: open records with `search_entities`, and use `market_volume_series` for transaction counts by area.

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

All MarketCode 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?