Close Knit

Get places

get_places

Read-onlyIdempotent

The places themselves (2.58 m: shops, gyms, cafes, parks, pubs, GPs, ... in 234 categories) near a typed id or {lat, lon} (radius_m 100-3000) or inside an area, by category (describe_data(kind: 'place') lists them) and brand (PureGym, Waitrose). Each: name, category, brand, metres, walk minutes (straight line, an estimate), its LSOA and sources. ODbL attribution; the full places.csv download link. Places of worship are never listed.

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_places"
  }
}

Input Schema

Name	Required	Description
`area`	No	[scope] Places inside this area's shape: a typed area id.
`near`	No	[scope] Distance from this: a typed id (uk:lsoa:…, uk:msoa:…, uk:lad:…, pc:…, uprn:…, school:…, place:…) or {lat, lon} from search_places. One of near or area.
`page`	No	[paging] Page; next gives the following one.
`brand`	No	[filter: exact] A brand, any case, e.g. PureGym, Waitrose.
`intent`	No	[input value] Optional, one to three sentences you write: what the user is looking for with this call and the criteria that matter, e.g. '2-bed rental near King's Cross, up to £2,500 a month, quiet, good primary schools'. Close Knit reads these to improve its answers. Your own summary, not the user's words or the chat; never names, contact details, exact addresses or family circumstances.
`category`	No	[filter: exact] A place category key from describe_data(kind: 'place'), exact case, e.g. fitness_centre (or gym), cafe, pub.
`radius_m`	No	[scope] With near: metres, 100-3000.
`page_size`	No	[paging] Places per page, at most 50.
`rate_previous`	No	[input value] Optional: your rating of an earlier Close Knit answer, by the callId it carried (none: the last answer). Send it with your next Close Knit call every time you have used an answer: rating 1-5 for how well it served the user's request, what was good, what was bad or missing, and the fix you would want.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedNov 5, 2026

changedInput schema / $defs / RatePrevious / properties / bad / description

Previous value: -"What was wrong, missing or confusing."New value: +"[input value] What was wrong, missing or confusing."

changedInput schema / $defs / RatePrevious / properties / call_id / description

Previous value: -"The callId of the answer you are rating; leave it out when answers carry none."New value: +"[id] The callId of the answer you are rating; leave it out when answers carry none."

changedInput schema / $defs / RatePrevious / properties / fix / description

Previous value: -"The change to the tool or its answer you would want."New value: +"[input value] The change to the tool or its answer you would want."

changedInput schema / $defs / RatePrevious / properties / good / description

Previous value: -"What was useful in the answer."New value: +"[input value] What was useful in the answer."

changedInput schema / $defs / RatePrevious / properties / rating / description

Previous value: -"1 = useless or wrong, 3 = usable with gaps, 5 = exactly what was needed."New value: +"[input value] 1 = useless or wrong, 3 = usable with gaps, 5 = exactly what was needed."

changedInput schema / properties / area / description

Previous value: -"Places inside this area's shape: a typed area id."New value: +"[scope] Places inside this area's shape: a typed area id."

changedInput schema / properties / brand / description

Previous value: -"A brand, any case, e.g. PureGym, Waitrose."New value: +"[filter: exact] A brand, any case, e.g. PureGym, Waitrose."

changedInput schema / properties / category / description

Previous value: -"A place category key from describe_data(kind: 'place'), e.g. fitness_centre (or gym), cafe, pub, supermarket."New value: +"[filter: exact] A place category key from describe_data(kind: 'place'), exact case, e.g. fitness_centre (or gym), cafe, pub."

changedInput schema / properties / intent / description

Previous value: -"Optional, one to three sentences you write: what the user is looking for with this call and the criteria that matter, e.g. '2-bed rental near King's Cross, up to £2,500 a month, quiet, good primary schools'. Close Knit reads these to improve its answers. Your own summary, not the user's words or the chat; never names, contact details, exact addresses or family circumstances."New value: +"[input value] Optional, one to three sentences you write: what the user is looking for with this call and the criteria that matter, e.g. '2-bed rental near King's Cross, up to £2,500 a month, quiet, good primary schools'. Close Knit reads these to improve its answers. Your own summary, not the user's words or the chat; never names, contact details, exact addresses or family circumstances."

changedInput schema / properties / near / description

Previous value: -"Distance from this: a typed id (uk:lsoa:…, uk:msoa:…, uk:lad:…, pc:…, uprn:…, school:…, place:…) or {lat, lon} from search_places. One of near or area."New value: +"[scope] Distance from this: a typed id (uk:lsoa:…, uk:msoa:…, uk:lad:…, pc:…, uprn:…, school:…, place:…) or {lat, lon} from search_places. One of near or area."

addedInput schema / properties / page / description

Added value: +"[paging] Page; next gives the following one."

changedInput schema / properties / page_size / description

Previous value: -"Places per page, at most 50."New value: +"[paging] Places per page, at most 50."

changedInput schema / properties / radius_m / description

Previous value: -"With near: metres, 100-3000."New value: +"[scope] With near: metres, 100-3000."

changedInput schema / properties / rate_previous / description

Previous value: -"Optional: your rating of an earlier Close Knit answer, by the callId it carried (none: the last answer). Send it with your next Close Knit call every time you have used an answer: rating 1-5 for how well it served the user's request, what was good, what was bad or missing, and the fix you would want."New value: +"[input value] Optional: your rating of an earlier Close Knit answer, by the callId it carried (none: the last answer). Send it with your next Close Knit call every time you have used an answer: rating 1-5 for how well it served the user's request, what was good, what was bad or missing, and the fix you would want."

Changed1 schema field changedOct 31, 2026

changedInput schema / properties / category / description

Previous value: -"A place category key from describe_data(kind: 'place'), e.g. gym, cafe, pub, supermarket."New value: +"A place category key from describe_data(kind: 'place'), e.g. fitness_centre (or gym), cafe, pub, supermarket."

AddedOct 31, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely non-obvious behavior: dataset scale and category count, that walk minutes are straight-line estimates, ODbL attribution obligations, an available places.csv download, and the worship-place exclusion. Result-count/page caps are left to the schema.

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 and dense: scope, filters, return fields, caveats and the exclusion all appear in two sentences with no filler. It is somewhat parenthetical-heavy ('2.58 m: shops, gyms... in 234 categories') and reads as a run-on, but nothing is wasted.

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 9-parameter, zero-required read tool with an output schema, this covers scope, filters, exclusions and data provenance well. Minor gaps: no guidance on paging through large result sets or on what happens when neither near nor area is supplied.

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 description coverage is 100%, so the schema already documents every parameter including radius bounds, brand/category exactness, and paging. The description mostly restates those bounds and examples, adding little syntax or meaning the schema lacks. Baseline 3 applies.

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?

Specific verb+resource: returns the actual places (2.58m shops, gyms, cafes, parks, pubs, GPs across 234 categories) near an id or {lat,lon}, or inside an area. The scope and return fields are stated precisely. It does not, however, contrast itself with the sibling search_places, which is the most likely confusion given the near-identical name.

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?

Clear usage context: pick near with an optional radius_m of 100-3000, or area for a shape, and filter by category (keyed from describe_data(kind: 'place')) and brand. It also gives an explicit exclusion: places of worship are never listed. Missing is any statement of when to prefer search_places or query instead.

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

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