Skip to main content
Glama

List UK Police Reference Data

ukcrime_list_reference
Read-onlyIdempotent

Decode the vocabulary the other ukcrime tools take: police force ids, crime category slugs, a force's neighbourhood ids, and data availability — the published months, and which forces published stop and search in each. Use it when a force, category, neighbourhood id or month is unknown; name_contains filters forces and neighbourhoods by name. The Metropolitan Police has about 680 neighbourhoods, so filter by name there; to get the force and neighbourhood covering a latitude and longitude, call ukcrime_find_neighbourhood instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoForce id such as 'leicestershire', or its name such as 'Leicestershire Police'; case-insensitive, spaces, underscores and hyphens match each other, '&' matches 'and', and a trailing 'Police', 'Police Service' or 'Constabulary' is optional. Required for topic 'neighbourhoods'. On 'availability', where 'btp' (British Transport Police) is also accepted, adds the months this force did and did not publish stop and search. Not accepted on 'forces' or 'categories'.
monthNoMonth as YYYY-MM. Topic 'availability' only: return just that month's row.
topicYesWhat to list: 'forces' (force ids), 'categories' (crime category slugs), 'availability' (published months and stop-and-search publication), or 'neighbourhoods' (one force's neighbourhood ids; needs force).
name_containsNoWords that must all appear in the name, in any order — case, accents and punctuation ignored, so the value needs at least one letter or digit. Topics 'forces' and 'neighbourhoods' only.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
forceNoTopic 'neighbourhoods': the force whose neighbourhoods are listed.
topicNoThe topic listed; its list field below is the one present.
forcesNoTopic 'forces': the forces data.police.uk lists, plus British Transport Police ('btp'), which ukcrime_search_stops takes with area 'force' and ukcrime_search_crimes with area 'force_unplaced'.
noticeNoWhy a list is empty — a name filter that matched nothing, or a month that is not published — and what to do instead.
categoriesNoTopic 'categories': every crime category.
attributionNoOpen Government Licence attribution for data.police.uk data.
availabilityNoTopic 'availability': the published-month window and stop-and-search publication by month.
neighbourhoodsNoTopic 'neighbourhoods': the force's neighbourhoods, sorted by name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld, so the safety profile is covered. The description adds genuine operational context: what the returned vocabulary is used for downstream, the scale of the Met neighbourhood list, and the advice to filter by name there. It does not discuss pagination or rate behavior, but an output schema exists so return-shape disclosure is not required.

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-loads the resource list before the when-to-use and alternative routing. Dense but every clause carries signal; the only mild redundancy is restating the name_contains scope that the schema already gives.

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?

With an output schema present, the description needn't explain return values, and it covers topic selection, prerequisite parameters, filtering guidance, and the sibling alternative. An agent has everything needed to call it correctly.

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% and the schema already documents cross-topic parameter acceptance in detail, so baseline is 3. The description's mention that name_contains filters forces and neighbourhoods adds only marginal meaning beyond the schema.

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?

Opens with a specific verb and resource: decode reference vocabulary (force ids, category slugs, neighbourhood ids, availability). It clearly frames this as the lookup/reference tool, which separates it from the search/outcome siblings without needing their schemas.

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?

Explicitly states when to use it ('when a force, category, neighbourhood id or month is unknown') and routes the geo case to the alternative by name ('to get the force and neighbourhood covering a latitude and longitude, call ukcrime_find_neighbourhood instead'). Includes a concrete filtering caveat for the Met's ~680 neighbourhoods.

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.