Skip to main content
Glama

Close Knit

by com.getcloseknit
OverviewDiscussionsAdmin

Find areas

find_areas
Read-onlyIdempotent

Shortlist London neighbourhoods for a household: budget, bedrooms, weighted priorities (crime, station access, price level, official deprivation decile, noise, disorder, energy rating, leasehold share) and optional stations/boroughs to live near. Returns ranked areas with score, factor values, a ballpark price for the bedroom count and budget fit, postcode districts and website links. Pass rejected areas in exclude_area_ids when refining after the user's feedback (LSOA, MSOA or borough ids).

Input Schema

NameRequiredDescriptionDefault
top_nNoHow many areas to return.
customNoThe user's own criteria from places on the map ('more cafés than kebab shops', 'near gyms'): a preset_id or a criterion, each scored by its percentile within the area's region (London for a London area). Describes places, never who lives there.
marketNoBuying or renting.buy
placesNoWhere the household goes — work, a gym, a particular school, friends (pinned: latitude/longitude from search_places) or the nearest of a kind (category). Each becomes a criterion; must = hard limit.
rangesNoAny other map layer as a range with soft edges, e.g. gigabit broadband at 90% of homes or more: {layer: 'broadband-gigabit', scale: 'value', min: 90}. Bounds are percentiles within each area's region by default (London's areas among London's; min 90 = the region's top 10%); scale 'value' uses the layer's own unit. Only layers list_metrics shows.
bedroomsNoBedrooms needed (0 = studio).
boroughsNoLive in these boroughs (uk:borough:E09…, from search_places). Stations + boroughs ≤ 3.
max_budgetYesMaximum price in £ (buy) or £ per month (rent).
prioritiesNoWhat matters, with importance 1-5 (criteria are ranked by importance, then in the order given; the order sets the weights). Translate the user's words: 'safe' → crime, 'near the tube' → station-access, 'good value' → market-level, 'quiet' → noise, 'no rough streets / graffiti' → disorder, 'low energy bills' → epc-share, 'freehold' → leasehold-share. must = only areas in London's better half for it.
budget_mustNoTrue = areas whose ballpark is over max_budget are out.
near_stationsNoLive within walking distance of these stations (e.g. on the user's commute line).
only_in_zonesNoWith stations/boroughs given: True = only areas inside them (a must Where criterion); False = ranked first in the order, the fit falling with distance outside (zone_soft_metres).
property_typeNoHouse or flat, for the price comparison on the brief page (sales of similar homes).any
target_budgetNoComfortable price; defaults to max less 8% (the site's own rule: £650k max → £600k).
liked_area_idsNoAreas the user liked: carried into the map link and highlighted there.
exclude_area_idsNoAreas the user already rejected — LSOA, MSOA or borough geography ids (boroughs and MSOAs expand to their LSOAs) — so they are not suggested again.
zone_soft_metresNoOutside the zones the fit falls to 0 over this distance (when only_in_zones is False).
budget_importanceNoWhere the budget sits in the order (5 = first). Fit 1 up to target_budget, falling to 0 at max_budget.
include_over_budgetNoKeep areas whose typical home looks over budget.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / $defs / RangeInput / properties / scale / description
      Previous value: -"percentile = bounds are London percentiles of the value, 0 = lowest in London, 100 = highest (e.g. max 30 = the lowest 30% for noise); value = the layer's own unit."New value: +"percentile = bounds are percentiles of the value within each area's region (London's areas among London's), 0 = lowest, 100 = highest (e.g. max 30 = the lowest 30% for noise); value = the layer's own unit."
    • changedInput schema / properties / custom / description
      Previous value: -"The user's own criteria from places on the map ('more cafés than kebab shops', 'near gyms'): a preset_id or a criterion, each scored by its London percentile. Describes places, never who lives there."New value: +"The user's own criteria from places on the map ('more cafés than kebab shops', 'near gyms'): a preset_id or a criterion, each scored by its percentile within the area's region (London for a London area). Describes places, never who lives there."
    • changedInput schema / properties / ranges / description
      Previous value: -"Any other map layer as a range with soft edges, e.g. gigabit broadband at 90% of homes or more: {layer: 'broadband-gigabit', scale: 'value', min: 90}. Bounds are London percentiles by default (min 90 = London's top 10%); scale 'value' uses the layer's own unit. Only layers list_metrics shows."New value: +"Any other map layer as a range with soft edges, e.g. gigabit broadband at 90% of homes or more: {layer: 'broadband-gigabit', scale: 'value', min: 90}. Bounds are percentiles within each area's region by default (London's areas among London's; min 90 = the region's top 10%); scale 'value' uses the layer's own unit. Only layers list_metrics shows."
  2. First observed

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety burden is lifted. The description adds the refinement/exclusion behavior and the geography-id types accepted (LSOA, MSOA, borough), but most of its remaining text recites return fields that the output schema already provides, and it says nothing about cost, latency or result limits beyond top_n.

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?

Three sentences, each load-bearing: purpose and inputs, return shape, then the refinement instruction. Front-loaded with the verb and resource, and the long factor list is contained inside the first sentence rather than sprawling.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 19-parameter tool with an output schema and full annotation coverage, the description supplies the essentials: what it ranks, what comes back, and how to re-run after feedback. Nothing critical is missing, though the soft-vs-must weighting model and the station/borough ≤3 constraint are left entirely to the schema.

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

Parameters3/5

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

Schema coverage is 100%, so every parameter is already documented, which sets the baseline at 3. The description does contribute the factor vocabulary (crime, station access, price level, deprivation decile, noise, disorder, energy rating, leasehold share) that maps onto the priorities enum and the idea of 'weighted' priorities, but it adds no syntax or default guidance beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Shortlist') and resource ('London neighbourhoods') and scopes the inputs a household would supply (budget, bedrooms, weighted priorities, stations/boroughs). An agent can tell this is a ranked-shortlist tool rather than a single-metric ranker, though it never names the near siblings (match_areas, search_areas, rank_areas_by_metric) to sharpen the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

Gives a concrete usage loop: pass rejected areas in exclude_area_ids 'when refining after the user's feedback', which tells the agent this is the iterative tool in a household flow. It stops short of explicit exclusions or a named alternative, so there is no when-not-to-use guidance.

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

All Close Knit 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