Skip to main content
Glama

Query

query
Read-onlyIdempotent

Analyse many areas or schools with a JSON query (never SQL). kind='area' (default): level lsoa, msoa, lad or rgn; scope england, london, a region or typed area ids; filters by value {metric, min, max}, percentile in scope {metric, pct_min}, vs the scope's reference {metric, vs: above}, change over N years {metric, change: {years, min}}, places inside {places: {category, brand, min}} or within_m; sort by a metric, a group stat {stat: median, metric} or deviation; above the metric's carrier level rows are groups: each metric is the group's own figure (its own row where the metric holds one at the level: crime, crime-, green-share, gross-yield; official where the publisher gives the council's or region's; else the weighted mean of all its areas; items[].method says which), with median, p25-p75, best tenth, count and fit share of the passing areas when asked, and group_filters filter them. defs say what each metric measures and is not, with England and region refs. kind='school' ranks schools (phase, ofsted, measure, near). saved='metric:' or 'custom:' runs a named ranking (describe_data(kind: 'ranking')). Pages of 10 (next.release flags moved rows) and a CSV download link. A London-only metric with an England scope is the coverage error with a hint; people metrics (Census) are never filtered or ranked.

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

Input Schema

NameRequiredDescriptionDefault
kindNo[option] What the rows are.area
pageNo[paging] Page; next gives the following one.
sortNo[sort] {metric, dir?} | {stat, metric, dir?} | {deviation: metric, dir?} | {standing: [metrics], dir?}. Default: the first filter's metric, better end first. One key: a list sorts by its first entry, the rest named in caveats.
levelNo[option] Row level. Above the metrics' carrier, rows are groups: each metric is the group's own figure (official, else the weighted mean of all its rows; defs and items[].method say which), with fit counts, the best row and stats of the passing rows when asked.
savedNo[id] A named query: metric:<id>, custom:<preset>, lens:<preset>, school:<axis>; the other params refine it.
scopeNo[scope] england | london | a region name | a typed area id | a list of up to 10 ids. Where rows come from, the reference and the ranking population. Default: what the service covers.
fieldsNo[select fields] Facts per row: metric ids, or group stats {stat, metric}. Default: the filter and sort metrics.
intentNo[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.
periodNo[filter: exact] YYYY-MM; default each metric's latest.
filtersNo[filter: range] Row conditions, ANDed: {metric, min?, max?} | {metric, pct_min?, pct_max?} | {metric, vs: above|below, ref?: scope|london|england, by?} | {metric, change: {years, min?, max?, unit?: abs|pct}} | {places: {category?, brand?, min?, max?, within_m?}} | {in: [ids]} | {not_in: [ids]} | {custom, min?, max?}. Schools: {phase} | {ofsted: [grades]} | {measure, min?, max?} | {near, within_m?}.
releaseNo[paging] From next.release: a caveat says if rows moved between pages.
page_sizeNo[paging] Rows per page, at most 50 (limit reads as page_size).
standoutsNo[option] Groups: up to 3 best rows from groups not on the page.
group_filtersNo[filter: range] Group conditions (HAVING): {stat: value|median|mean|p25|p75|best10|count|fit_share, metric?, min?, max?}; value is the group's own figure.
rate_previousNo[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

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed20 schema fields changed
    • 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 / fields / description
      Previous value: -"Facts per row: metric ids, or group stats {stat, metric}. Default: the filter and sort metrics."New value: +"[select fields] Facts per row: metric ids, or group stats {stat, metric}. Default: the filter and sort metrics."
    • changedInput schema / properties / filters / description
      Previous value: -"Row conditions, ANDed: {metric, min?, max?} | {metric, pct_min?, pct_max?} | {metric, vs: above|below, ref?: scope|london|england, by?} | {metric, change: {years, min?, max?, unit?: abs|pct}} | {places: {category?, brand?, min?, max?, within_m?}} | {in: [ids]} | {not_in: [ids]} | {custom, min?, max?}. Schools: {phase} | {ofsted: [grades]} | {measure, min?, max?} | {near, within_m?}."New value: +"[filter: range] Row conditions, ANDed: {metric, min?, max?} | {metric, pct_min?, pct_max?} | {metric, vs: above|below, ref?: scope|london|england, by?} | {metric, change: {years, min?, max?, unit?: abs|pct}} | {places: {category?, brand?, min?, max?, within_m?}} | {in: [ids]} | {not_in: [ids]} | {custom, min?, max?}. Schools: {phase} | {ofsted: [grades]} | {measure, min?, max?} | {near, within_m?}."
    • changedInput schema / properties / group_filters / description
      Previous value: -"Group conditions (HAVING): {stat: value|median|mean|p25|p75|best10|count|fit_share, metric?, min?, max?}; value is the group's own figure."New value: +"[filter: range] Group conditions (HAVING): {stat: value|median|mean|p25|p75|best10|count|fit_share, metric?, min?, max?}; value is the group's own figure."
    • 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 / kind / description
      Previous value: -"What the rows are."New value: +"[option] What the rows are."
    • changedInput schema / properties / level / description
      Previous value: -"Row level. Above the metrics' carrier, rows are groups: each metric is the group's own figure (official, else the weighted mean of all its rows; defs and items[].method say which), with fit counts, the best row and stats of the passing rows when asked."New value: +"[option] Row level. Above the metrics' carrier, rows are groups: each metric is the group's own figure (official, else the weighted mean of all its rows; defs and items[].method say which), with fit counts, the best row and stats of the passing rows when asked."
    • addedInput schema / properties / page / description
      Added value: +"[paging] Page; next gives the following one."
    • changedInput schema / properties / page_size / description
      Previous value: -"Rows per page, at most 50 (limit reads as page_size)."New value: +"[paging] Rows per page, at most 50 (limit reads as page_size)."
    • changedInput schema / properties / period / description
      Previous value: -"YYYY-MM; default each metric's latest."New value: +"[filter: exact] YYYY-MM; default each metric's latest."
    • 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."
    • changedInput schema / properties / release / description
      Previous value: -"From next.release: pins the pages."New value: +"[paging] From next.release: a caveat says if rows moved between pages."
    • changedInput schema / properties / saved / description
      Previous value: -"A named query: metric:<id>, custom:<preset>, lens:<preset>, school:<axis>; the other params refine it."New value: +"[id] A named query: metric:<id>, custom:<preset>, lens:<preset>, school:<axis>; the other params refine it."
    • changedInput schema / properties / scope / description
      Previous value: -"england | london | a region name | a typed area id | a list of up to 10 ids. Where rows come from, the reference and the ranking population. Default: what the service covers."New value: +"[scope] england | london | a region name | a typed area id | a list of up to 10 ids. Where rows come from, the reference and the ranking population. Default: what the service covers."
    • changedInput schema / properties / sort / description
      Previous value: -"{metric, dir?} | {stat, metric, dir?} | {deviation: metric, dir?} | {standing: [metrics], dir?}. Default: the first filter's metric, better end first. One key: a list sorts by its first entry, the rest named in caveats."New value: +"[sort] {metric, dir?} | {stat, metric, dir?} | {deviation: metric, dir?} | {standing: [metrics], dir?}. Default: the first filter's metric, better end first. One key: a list sorts by its first entry, the rest named in caveats."
    • changedInput schema / properties / standouts / description
      Previous value: -"Groups: up to 3 best rows from groups not on the page."New value: +"[option] Groups: up to 3 best rows from groups not on the page."
  2. Changed2 schema fields changed
    • changedInput schema / properties / page_size / description
      Previous value: -"Rows per page, at most 50."New value: +"Rows per page, at most 50 (limit reads as page_size)."
    • changedInput schema / properties / sort / description
      Previous value: -"{metric, dir?} | {stat, metric, dir?} | {deviation: metric, dir?} | {standing: [metrics], dir?}. Default: the first filter's metric, better end first."New value: +"{metric, dir?} | {stat, metric, dir?} | {deviation: metric, dir?} | {standing: [metrics], dir?}. Default: the first filter's metric, better end first. One key: a list sorts by its first entry, the rest named in caveats."
  3. Changed2 schema fields changed
    • changedInput schema / properties / group_filters / description
      Previous value: -"Group conditions (HAVING): {stat: median|mean|p25|p75|best10|count|fit_share, metric?, min?, max?}."New value: +"Group conditions (HAVING): {stat: value|median|mean|p25|p75|best10|count|fit_share, metric?, min?, max?}; value is the group's own figure."
    • changedInput schema / properties / level / description
      Previous value: -"Row level. Above the metrics' carrier, rows are groups with stats (median, fit counts, the best row)."New value: +"Row level. Above the metrics' carrier, rows are groups: each metric is the group's own figure (official, else the weighted mean of all its rows; defs and items[].method say which), with fit counts, the best row and stats of the passing rows when asked."
  4. Added

TDQS

A3.5/5.0
Behavior4/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: pagination size, next.release flags, CSV download links, group aggregation semantics, and a specific coverage-error behavior. It also discloses limitations such as people metrics never being filtered or ranked, which materially helps correct invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is information-dense and mostly earns its place, but it is delivered as one long run-on paragraph with heavy parenthetical nesting. It lacks clear structure or front-loaded groupings, making it harder to scan than necessary for a 15-parameter tool.

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?

Given the tool's complexity, 15 parameters, and an existing output schema, the description covers both area and school modes, filtering, sorting, grouping, pagination, errors, and limitations. It is nearly complete, though it could more explicitly guide tool selection against siblings.

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 schema already documents parameters well. The description still adds cross-parameter meaning: filter forms, sort behavior, group-level aggregation with items[].method, saved-query formats, and the scope/reference relationship. This goes beyond merely restating 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?

The description states a specific verb and resource: 'Analyse many areas or schools with a JSON query', and distinguishes the two modes via kind='area' and kind='school'. It does not, however, explain how this differs from siblings such as rank_areas_by_metric, rank_schools, or get_area_metric, leaving some ambiguity for tool selection.

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

Usage Guidelines2/5

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

The only explicit usage constraint is 'never SQL'. The description does not say when to use this broad query tool instead of the many narrower siblings, nor does it give exclusions or preferred alternatives beyond pointing to describe_data for saved rankings.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.