Skip to main content
Glama

Close Knit

by com.getcloseknit
OverviewDiscussionsAdmin

Match areas

match_areas
Read-onlyIdempotent

Score every area against a household's ordered criteria (preference-profile.v2: budget, ranges on any map layer, places, where zones, own criteria; must = filter). Returns a match-pack.v2 with the best top_n (default 20, max 100) areas as a list with score, rank and percentile per area, its top 2 reasons and 2 weakest criteria, the bottom 10, and per-criterion components (value, fit, in/edge/out) as evidence for the listed areas only. Whole-coverage counts (scored, unscored, excluded, and excludedBy per unmet must) cover every area; mapUrl opens the full map for the search. Set analyticsConsent true only if the user agreed to store an anonymised profile summary; the tool works identically with false.

Input Schema

NameRequiredDescriptionDefault
top_nNoHow many of the best-scored areas to list (1-100). values is that top-N list, not the whole map; scored, unscored, excluded and excludedBy count every area Close Knit covers. For the whole map use mapUrl.
profileYespreference-profile.v2 (preferred): {schemaVersion: 'preference-profile.v2', market buy|rent, targetBudget, maximumBudget, bedrooms, criteria: [...]} where criteria is ORDERED, most important first, each one of {kind: budget, must} (fit 1 at or under targetBudget, 0 at maximumBudget; must = within maximumBudget) | {kind: range, layer (a map layer id from list_metrics, e.g. crime, noise, air-no2, station-access, price-per-square-metre, or disorder, schools, epc-share, leasehold-share), scale value|percentile (percentile = percentile 0-100 of the value within the area's region, London's areas among London's, lowest first), min, max, softMin, softMax, must} | {kind: place, id, label, target, mode, targetMinutes, softMinutes, must} | {kind: where, zones (1-3: {kind: station, stationId, maxWalkMinutes 5-30} | {kind: borough, id} | {kind: lsoas, ids <= 50} | {kind: polygon, points}), softMetres (default 1000), must} | {kind: custom, criterion, direction, must}. A must criterion is a filter with no weight; the others weigh by their place in the list. preference-profile.v1 (factors with weights 0-5) is still accepted and migrated (weight order, Must kept).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / profile / description
      Previous value: -"preference-profile.v2 (preferred): {schemaVersion: 'preference-profile.v2', market buy|rent, targetBudget, maximumBudget, bedrooms, criteria: [...]} where criteria is ORDERED, most important first, each one of {kind: budget, must} (fit 1 at or under targetBudget, 0 at maximumBudget; must = within maximumBudget) | {kind: range, layer (a map layer id from list_metrics, e.g. crime, noise, air-no2, station-access, price-per-square-metre, or disorder, schools, epc-share, leasehold-share), scale value|percentile (percentile = London percentile 0-100 of the value, lowest first), min, max, softMin, softMax, must} | {kind: place, id, label, target, mode, targetMinutes, softMinutes, must} | {kind: where, zones (1-3: {kind: station, stationId, maxWalkMinutes 5-30} | {kind: borough, id} | {kind: lsoas, ids <= 50} | {kind: polygon, points}), softMetres (default 1000), must} | {kind: custom, criterion, direction, must}. A must criterion is a filter with no weight; the others weigh by their place in the list. preference-profile.v1 (factors with weights 0-5) is still accepted and migrated (weight order, Must kept)."New value: +"preference-profile.v2 (preferred): {schemaVersion: 'preference-profile.v2', market buy|rent, targetBudget, maximumBudget, bedrooms, criteria: [...]} where criteria is ORDERED, most important first, each one of {kind: budget, must} (fit 1 at or under targetBudget, 0 at maximumBudget; must = within maximumBudget) | {kind: range, layer (a map layer id from list_metrics, e.g. crime, noise, air-no2, station-access, price-per-square-metre, or disorder, schools, epc-share, leasehold-share), scale value|percentile (percentile = percentile 0-100 of the value within the area's region, London's areas among London's, lowest first), min, max, softMin, softMax, must} | {kind: place, id, label, target, mode, targetMinutes, softMinutes, must} | {kind: where, zones (1-3: {kind: station, stationId, maxWalkMinutes 5-30} | {kind: borough, id} | {kind: lsoas, ids <= 50} | {kind: polygon, points}), softMetres (default 1000), must} | {kind: custom, criterion, direction, must}. A must criterion is a filter with no weight; the others weigh by their place in the list. preference-profile.v1 (factors with weights 0-5) is still accepted and migrated (weight order, Must kept)."
    • changedInput schema / properties / top_n / description
      Previous value: -"How many of the best-scored areas to list (1-100). values is that top-N list, not the whole map; scored, unscored, excluded and excludedBy count every area in London. For the whole map use mapUrl."New value: +"How many of the best-scored areas to list (1-100). values is that top-N list, not the whole map; scored, unscored, excluded and excludedBy count every area Close Knit covers. For the whole map use mapUrl."
  2. First observed

TDQS

A4/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that must criteria act as filters with no weight while others weigh by list position, that coverage counts (scored/unscored/excluded/excludedBy) span every area while value/fit/in-edge-out components are returned for listed areas only, and that mapUrl opens the full map because the list is only top-N. It also surfaces a consent requirement for analyticsConsent and states explicitly that the tool behaves identically with false, which is exactly the kind of behavioural disclosure annotations cannot carry.

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?

Purpose is front-loaded in the first clause and returns/consent follow in a logical order, with no filler sentences. The second sentence is a long multi-clause run-on that would read better split, which keeps it out of the top band.

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 two-parameter tool with nested criteria and an output schema, the description covers the semantics an agent actually needs (must-as-filter, top-N vs whole-map coverage, consent). Return-value detail is partly redundant given the output schema exists, and the undeclared analyticsConsent parameter is handled in prose rather than the schema, leaving a small structural gap.

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; the description nevertheless adds real meaning by documenting analyticsConsent, a parameter that does not appear in the input schema at all, including its consent semantics and the fact that it does not change results. Its top_n explanation largely restates the schema, so the added value is real but partial.

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 and object ('Score every area against a household's ordered criteria') and names the concrete input format (preference-profile.v2) and output artifact (match-pack.v2), so an agent knows exactly what the tool produces. It does not explicitly name a sibling it is not (e.g. rank_areas_by_metric or find_areas), so differentiation is by inference from the criteria-scoring framing.

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

Usage Guidelines3/5

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

Usage is implied by the phrasing – this is the tool for scoring a whole market against a ranked preference profile rather than filtering (find_areas/search_areas) or ranking by a single metric. There is no explicit when-to-use/when-not statement and no named alternative, and the only real guidance given ('Set analyticsConsent true only if the user agreed') is a consent rule for a parameter, not a tool-selection rule.

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