This server provides access to the UK's official police.uk API, enabling queries on crimes, police forces, neighbourhoods, and stop-and-search incidents across England, Wales, and Northern Ireland.
Crime Data
Retrieve street-level crimes by coordinates, custom polygon area, or location ID
Get crimes at a specific location or fetch unmapped crimes by force and category
Look up outcomes for a specific crime (by persistent ID) or street-level outcomes by area
Retrieve valid crime categories for a given date and check when data was last updated
Police Forces
List all police forces, get detailed information for a specific force, and retrieve senior officers
Neighbourhoods
List neighbourhoods for a given force; get details, boundary coordinates, team members, events, and policing priorities for a specific neighbourhood
Locate the neighbourhood policing team responsible for a given set of coordinates
Stop and Search
Query stop and search incidents by radius or polygon area, at specific locations, those not mapped to a location, or reported by a particular police force
Reliability & Integration
Built with the official MCP TypeScript SDK, with comprehensive error handling, type safety, and respect for police.uk API rate limits, making it easy to integrate with MCP-compatible systems including Claude Desktop.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Server Police UK show me recent crimes near London Bridge"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server providing tools to access and interact with the police.uk API, offering comprehensive data on crimes, police forces, neighbourhoods, and stop-and-search incidents across the UK.
21 distinct tools for querying police.uk API endpoints
Retrieve street-level crimes, neighbourhood details, force information, stop-and-search records, and more
Built with the official MCP TypeScript SDK
Easy integration with MCP-compatible systems
Comprehensive error handling and type safety
Related MCP server: FBI Crime Data MCP Server
Install directly from npm:
npm install -g mcp-server-police-ukOr use with npx (no installation required):
npx mcp-server-police-ukAdd to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"police-uk": {
"command": "npx",
"args": ["-y", "mcp-server-police-uk"]
}
}
}To contribute or run locally:
# Clone the repository
git clone https://github.com/dwain-barnes/police-uk-api-mcp-server.git
cd police-uk-api-mcp-server
# Install dependencies
npm install
# Build the project
npm run build
# Run locally
npm startnpx mcp-server-police-ukget_street_level_crimes - Retrieve street-level crimes by location or area
get_crimes_at_location - Get crimes at a specific location
get_crimes_no_location - Retrieve crimes that couldn't be mapped to a location
get_crime_categories - Get valid crime categories
get_last_updated - Get the date when crime data was last updated
get_outcomes_for_crime - Get outcomes for a specific crime
get_street_level_outcomes - Retrieve outcomes by location or area
get_list_of_forces - Get all police forces
get_force_details - Get details for a specific police force
get_senior_officers - Get senior officers for a police force
get_neighbourhoods - Get neighbourhoods for a police force
get_neighbourhood_details - Get details for a specific neighbourhood
get_neighbourhood_boundary - Get boundary coordinates for a neighbourhood
get_neighbourhood_team - Get team members for a neighbourhood
get_neighbourhood_events - Get scheduled events for a neighbourhood
get_neighbourhood_priorities - Get policing priorities for a neighbourhood
locate_neighbourhood - Find neighbourhood team for given coordinates
get_stop_searches_by_area - Get stop and searches within an area
get_stop_searches_by_location - Get stop and searches at a specific location
get_stop_searches_no_location - Get stop and searches with no location
get_stop_searches_by_force - Get stop and searches by police force
// Get crimes within 1 mile of coordinates
get_street_level_crimes({
lat: 51.5074,
lng: -0.1278,
date: "2024-01"
})// Find neighbourhood team for coordinates
locate_neighbourhood({
lat: 51.5074,
lng: -0.1278
})// Get details about Metropolitan Police
get_force_details({
force_id: "metropolitan"
})This server respects the police.uk API rate limits. The API is free to use but has usage limits in place to ensure fair access for all users.
All data is sourced from the official police.uk API, which provides open data about policing in England, Wales, and Northern Ireland. The data is typically updated monthly.
Contributions are welcome! Please feel free to:
Report issues on GitHub Issues
Submit Pull Requests
Suggest new features or improvements
MIT License - see LICENSE file for details.
If you encounter any issues or have questions:
File an issue on GitHub Issues
Check the police.uk API documentation for API-specific questions
Created by Dwain Barnes
Retrieve valid crime categories for a given date
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Specific month (YYYY-MM) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral info. It only mentions retrieval but does not disclose any side effects, error handling, or rate limits. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with no output schema, the description is adequate but lacks any indication of the return format or behavior for invalid dates. It could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the date parameter as 'Specific month (YYYY-MM)', and the description echoes 'for a given date'. With 100% schema coverage, baseline is 3; description adds no extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve valid crime categories for a given date', specifying the action, resource, and condition. It distinguishes from sibling tools that deal with crimes, forces, or locations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Given the many sibling tools, the description should ideally advise when categories are needed, but it does not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve crimes at a specific location by ID or nearest to lat/lng
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude of the requested crime area | |
| lng | No | Longitude of the requested crime area | |
| location_id | No | The ID of the location | |
| date | No | Limit results to a specific month (YYYY-MM) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It says 'retrieve', implying a read operation, but does not explicitly state it is safe or non-destructive. No mention of rate limits, error conditions, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 10 words, front-loaded with the action and resource. Every word contributes meaning with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 optional parameters, the description lacks details on return format, pagination, error handling, and parameter combination rules (e.g., mutual exclusivity of location_id vs lat/lng). Leaves significant ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, giving baseline 3. The description adds value by explaining that the location can be specified by ID or by lat/lng coordinates, clarifying the optional relationship between parameters. This goes beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves crimes at a specific location, specifying two methods: by ID or by lat/lng coordinates. This distinguishes it from sibling tools like get_crimes_no_location (no location) and get_street_level_crimes (different type of crime data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings, nor when to use location_id versus lat/lng. Does not explain prerequisites or trade-offs between the two location specification methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve crimes that could not be mapped to a location
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | The category of the crimes | |
| force | Yes | Specific police force | |
| date | No | Limit results to a specific month (YYYY-MM) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It only states the purpose without disclosing any behavioral traits such as read-only nature, potential error conditions, or side effects. For a retrieval tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core purpose without extraneous words. It is appropriately sized for a simple retrieval tool but could benefit from slight expansion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters and no output schema, the description should provide hints about return format or constraints, but it does not. It is too minimal given the absence of output schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning all parameters are described in the schema. The description adds no further meaning beyond the schema's parameter descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific purpose: retrieving crimes that could not be mapped to a location. This distinguishes it from sibling tools like get_crimes_at_location which retrieve crimes at a specific location.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_crimes_at_location or get_street_level_crimes. The description does not mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve details for a specific police force
| Name | Required | Description | Default |
|---|---|---|---|
| force_id | Yes | The unique identifier for the force |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'retrieve details'. It does not mention any side effects, data freshness, permissions, or what constitutes 'details'. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose. No unnecessary words. Perfect conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the description does not mention return format or content. Lacking output schema, the description should hint at what 'details' includes. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'force_id' is well-described in the schema. The description adds no additional meaning beyond that. Baseline 3 is appropriate since the schema already provides the necessary parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve details for a specific police force' clearly states the action (retrieve) and resource (details for a police force). It is specific but does not differentiate from sibling tools like get_list_of_forces or get_neighbourhood_details, which could cause confusion. A 4 is appropriate as it is clear but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool over alternatives, nor does it mention any prerequisites or context. A score of 2 reflects the absence of explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the date when crime data was last updated
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. States it is a retrieval, implying read-only, but does not mention return format or side effects. Adequate for a simple tool but lacks details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with 8 words, no redundancy. Extremely concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, description is minimal. Could specify the output format, but is adequate for a simple metadata retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. Description adds no parameter info, which is acceptable, baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves the last updated date of crime data, using a specific verb and resource. Differentiates from siblings which retrieve crime records themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives guidance, but the tool is self-explanatory. Usage is implied for checking data freshness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a list of all police forces
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing behavioral traits such as caching, performance, or response structure. This is minimal for a tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately sized for a simple list-all tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters, no output schema, and no annotations. The description is largely complete, though lacking a hint about the return format (e.g., list of force names). Still, it's adequate for such a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters and 100% coverage, so the description need not add parameter info. Baseline of 4 is appropriate; no compensation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieve a list of all police forces' uses a specific verb ('retrieve') and resource ('list of all police forces'), clearly distinguishing it from siblings that deal with specific forces or other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for getting all forces, but lacks explicit guidance on when to use this tool versus siblings like get_force_details or get_neighbourhoods. No when-not-to-use or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the boundary coordinates for a specific neighbourhood
| Name | Required | Description | Default |
|---|---|---|---|
| force_id | Yes | The unique identifier for the force | |
| neighbourhood_id | Yes | The unique identifier for the neighbourhood |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states 'retrieve', implying read-only, but no details on side effects, data format, or limitations. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, front-loaded with key action. Could be longer to include context but remains direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should clarify return format (e.g., coordinates as polygon). Missing such details makes it incomplete for an agent to understand results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters. Description adds no extra semantic value beyond the schema, which is baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Retrieve the boundary coordinates for a specific neighbourhood', with clear verb and resource. Distinct from siblings like get_neighbourhood_details or get_neighbourhoods which retrieve different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like locate_neighbourhood or get_neighbourhood_details. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve details for a specific neighbourhood within a force
| Name | Required | Description | Default |
|---|---|---|---|
| force_id | Yes | The unique identifier for the force | |
| neighbourhood_id | Yes | The unique identifier for the neighbourhood |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavior. It implies a read-only retrieval but lacks details on authentication, rate limits, data freshness, or any side effects. The description is too minimal for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is direct and contains no unnecessary words. It is well front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple, the description omits what 'details' means (no output schema provided). Compared to siblings that specify boundaries, events, etc., this description lacks completeness. It should mention the typical output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions, achieving 100% coverage. The tool description adds no extra meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Retrieve details for a specific neighbourhood within a force', clearly indicating the action and resources. However, it does not differentiate from siblings like get_neighbourhood_boundary or get_neighbourhood_events, which also retrieve specific neighbourhood data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_neighbourhood_boundary, events, priorities, or team. There is no mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve events scheduled for a specific neighbourhood
| Name | Required | Description | Default |
|---|---|---|---|
| force_id | Yes | The unique identifier for the force | |
| neighbourhood_id | Yes | The unique identifier for the neighbourhood |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it retrieves events, with no details on behavioral traits like pagination, date range, or outcome format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple retrieval tool with two params and no output schema. However, lacks details about the events (e.g., whether they are upcoming or historical) and return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters. The description adds no extra meaning beyond the schema; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves events scheduled for a specific neighbourhood, using a specific verb and resource. It distinguishes itself from sibling tools like get_neighbourhood_boundary or get_neighbourhood_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., other neighbourhood tools). The description only states what it does, not when or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve policing priorities for a specific neighbourhood
| Name | Required | Description | Default |
|---|---|---|---|
| force_id | Yes | The unique identifier for the force | |
| neighbourhood_id | Yes | The unique identifier for the neighbourhood |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'Retrieve,' implying read-only. It fails to disclose important behavioral aspects such as data freshness, pagination, required authorization, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. While very short, it conveys the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain the structure or content of the returned priorities. For a data retrieval tool, important details like whether results are ordered or limited are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions already explaining both parameters as unique identifiers. The description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('Retrieve') and a distinct resource ('policing priorities for a specific neighbourhood'). Among siblings like get_neighbourhood_details, get_neighbourhood_events, and get_neighbourhood_team, this tool's purpose is unique and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives like get_neighbourhood_details or get_neighbourhood_events. The description lacks any context about prerequisites, filtering, or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a list of neighbourhoods for a specific police force
| Name | Required | Description | Default |
|---|---|---|---|
| force_id | Yes | The unique identifier for the force |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden but only states it 'Retrieve a list'. It does not disclose read-only nature, error handling, pagination, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that clearly conveys the tool's purpose with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list retrieval with no output schema and many siblings, the description is adequate but could mention the return format or relation to force_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no new meaning beyond the schema's parameter description; it merely echoes 'specific police force'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action 'Retrieve' and the resource 'a list of neighbourhoods for a specific police force', using a specific verb and resource that distinguishes it from sibling tools like get_neighbourhood_details or get_neighbourhood_boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied but not explicit: it retrieves neighbourhoods for a given force. There is no guidance on when to use this versus alternatives, nor exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the team members for a specific neighbourhood
| Name | Required | Description | Default |
|---|---|---|---|
| force_id | Yes | The unique identifier for the force | |
| neighbourhood_id | Yes | The unique identifier for the neighbourhood |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Retrieve' implying a read operation, but does not disclose any other behavioral traits (e.g., rate limits, authentication, or data freshness).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It follows a simple structure: verb + resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with no output schema and 2 well-described parameters, the description is minimally adequate. However, it lacks expected return value format or any context about the team members structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with clear descriptions (force_id, neighbourhood_id). Schema description coverage is 100%, so the description adds no additional meaning beyond what's already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'team members for a specific neighbourhood'. It is specific and unambiguous, though it does not differentiate from sibling tools like get_neighbourhood_details or get_senior_officers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description does not mention prerequisites, typical use cases, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve outcomes for a specific crime by persistent ID
| Name | Required | Description | Default |
|---|---|---|---|
| persistent_id | Yes | The 64-character unique identifier for the crime |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not state whether the operation is read-only, idempotent, or safe. It does not mention authentication, rate limits, or error behavior (e.g., what happens if the persistent ID is invalid).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the key action. However, it could be slightly more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low parameter count and no output schema, the description is minimally complete. It conveys the core functionality but lacks context on response format, possible error states, or any prerequisites. For a simple tool, this is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the parameter 'persistent_id' described as 'The 64-character unique identifier for the crime'. The description echoes 'by persistent ID' but adds no additional semantics. Baseline 3 is appropriate as the description adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve outcomes for a specific crime by persistent ID', which is a specific verb+resource combination. It distinguishes from sibling tools like 'get_street_level_outcomes' by specifying 'by persistent ID' and 'specific crime'. However, it could be more explicit about how this differs from similar retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'get_street_level_outcomes' or 'get_crimes_at_location'. No when-not-to-use information or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve senior officers for a specific police force
| Name | Required | Description | Default |
|---|---|---|---|
| force_id | Yes | The unique identifier for the force |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is read-only, requires authentication, or any rate limits. The minimal description leaves ambiguity about the return format and behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It could be improved by adding a bit more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with one parameter and no output schema, the description is adequate but lacks information about the return structure (e.g., list of officers with names and ranks). This leaves some uncertainty for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes force_id well. The description adds no additional meaning beyond the schema, so it meets the baseline for 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve', the resource 'senior officers', and the context 'for a specific police force', distinguishing it from sibling tools like get_force_details or get_crime_categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools for police data, explicit usage context would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve stop and searches within a 1-mile radius or custom area
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude of the centre point | |
| lng | No | Longitude of the centre point | |
| poly | No | Lat/lng pairs defining a polygon | |
| date | No | Specific month (YYYY-MM) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions radius and polygon options, but lacks details on behavior when conflicting parameters are provided, rate limits, or data completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that conveys the core functionality. No wasted words, but could benefit from slight expansion on usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks description of return format or any behavioral details beyond the basic scope. For a tool with no output schema, more context on what is returned would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic parameter descriptions. The tool description adds value by explaining the '1-mile radius' concept, which is not in the schema, and frames the parameters as supporting either point+radius or polygon area.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves stop and searches, specifying geographic scope (1-mile radius or custom area). This distinguishes it from siblings like get_stop_searches_by_location or get_stop_searches_by_force.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description implies area-based queries, but does not differentiate from point-based or force-based queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve stop and searches reported by a specific force
| Name | Required | Description | Default |
|---|---|---|---|
| force_id | Yes | The unique identifier for the force | |
| date | No | Specific month (YYYY-MM) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It states that records are reported by a specific force, but does not disclose data freshness, pagination, error handling, or any behavioral traits beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence with no unnecessary words. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with no output schema, the description is adequate. It might benefit from mentioning that the response is a list of records, but it covers the essential purpose well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema's parameter descriptions, which are already clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'stop and searches reported by a specific force', distinguishing it from sibling tools like get_stop_searches_by_area or get_stop_searches_by_location.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention when not to use it or provide any context about other stop search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve stop and searches at a specific location by ID
| Name | Required | Description | Default |
|---|---|---|---|
| location_id | Yes | The ID of the location | |
| date | No | Specific month (YYYY-MM) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It indicates a read operation ('Retrieve') but omits any details about response format, pagination, or side effects. This is minimally acceptable for a simple retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 11 words that is front-loaded with the action and resource. No unnecessary words, but could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description is adequate but does not explain return structure or behavior for optional parameters. It meets basic needs but lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters, so the baseline is 3. The description adds no additional meaning beyond the schema; it only confirms the purpose of location_id via 'by ID'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Retrieve' and the resource 'stop and searches' with the qualifier 'at a specific location by ID', clearly distinguishing it from sibling tools like get_stop_searches_by_area or get_stop_searches_no_location.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention that it requires a location ID and that the date parameter is optional, nor does it direct users to sibling tools for other query types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve stop and searches that could not be mapped to a location
| Name | Required | Description | Default |
|---|---|---|---|
| force_id | Yes | The unique identifier for the force | |
| date | No | Specific month (YYYY-MM) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It only states the filter criterion (no location) but fails to mention whether it is read-only, if it may return empty results, pagination behavior, or any operational constraints. This is insufficient for an agent to understand the tool's behavior fully.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that quickly conveys the tool's purpose. It is front-loaded and contains no fluff. However, it could be slightly expanded with more details without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter input, no output schema, and no annotations, the description is minimally adequate but lacks details about return format, edge cases, or constraints. It is sufficient for a straightforward retrieval but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with both parameters (force_id and date) already described. The tool description does not add any additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Retrieve stop and searches that could not be mapped to a location,' clearly specifying the verb (retrieve) and the resource (stop searches with missing location), which distinguishes it from sibling tools like get_stop_searches_by_area or get_stop_searches_by_location.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for stop searches without a location, but it does not explicitly state when to use it versus other stop search tools (e.g., by force, by area, by location). No alternatives or exclusions are mentioned, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve street-level crimes by lat/lng or custom polygon area
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude of the requested crime area | |
| lng | No | Longitude of the requested crime area | |
| poly | No | The lat/lng pairs defining the boundary of the custom area | |
| date | No | Limit results to a specific month (YYYY-MM) | |
| category | No | The crime category | all-crime |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'retrieve', lacking details on read-only behavior, data freshness, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence is concise but could be expanded with more context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 optional parameters, no output schema, and no annotations, the description is too brief to inform proper usage, missing details on poly format, date requirement, category values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no extra value beyond what parameters already indicate. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve', the resource 'street-level crimes', and the method by lat/lng or polygon, distinguishing it from siblings like get_crimes_at_location.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, such as when to use lat/lng vs polygon, or what scenarios are appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve outcomes by lat/lng, custom polygon, or location ID
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude of the requested area | |
| lng | No | Longitude of the requested area | |
| poly | No | The lat/lng pairs defining the boundary of the custom area | |
| location_id | No | The ID of the location | |
| date | No | Limit results to a specific month (YYYY-MM) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose any behavioral traits beyond the basic capability. Missing details such as response format, pagination, rate limits, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words. However, brevity comes at the cost of omitting useful details. Could include more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and the description does not explain what outcomes are returned (e.g., format, fields). No guidance on required parameters or constraints (e.g., lat and lng must be used together). Incomplete for a tool with 5 optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 5 parameters with descriptions (100% coverage). The description adds minor value by indicating that parameters are organized into alternative query modes (lat/lng, polygon, location ID), but does not elaborate on parameter usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (Retrieve) and resource (outcomes), and specifies three distinct query methods (lat/lng, custom polygon, or location ID) which distinguishes it from sibling tools like get_crimes_at_location or get_outcomes_for_crime.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance relative to siblings. While the purpose is clear, the description does not mention alternatives or contexts where other tools (e.g., get_outcomes_for_crime) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the neighbourhood policing team for a given latitude and longitude
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude of the location | |
| lng | Yes | Longitude of the location |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as rate limits, authentication requirements, or whether results are cached or live. This leaves a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant information. It is well front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 params, no output schema), the description is adequate but could be improved by mentioning coordinate range constraints or output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds no new meaning beyond stating 'latitude and longitude', which is already in the schema. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Find' and the resource 'neighbourhood policing team' using latitude and longitude. It distinguishes from siblings like 'get_neighbourhood_team' which requires a team ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when coordinates are available but does not explicitly state when to use this tool versus alternatives like 'get_neighbourhood_team' or 'get_neighbourhoods'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.1get_crime_categoriesget_crimes_at_locationget_crimes_no_locationget_force_detailsget_last_updatedget_list_of_forcesget_neighbourhood_boundaryget_neighbourhood_detailsget_neighbourhood_eventsget_neighbourhood_prioritiesget_neighbourhood_teamget_neighbourhoodsget_outcomes_for_crimeget_senior_officersget_stop_searches_by_areaget_stop_searches_by_forceget_stop_searches_by_locationget_stop_searches_no_locationget_street_level_crimesget_street_level_outcomeslocate_neighbourhoodScored across 21 tools
Most tools have distinct purposes (crimes, stops, forces, neighbourhoods), but some like get_crimes_at_location and get_street_level_crimes could be confused due to similar inputs and outputs.
All tools follow a consistent 'get_' prefix with descriptive snake_case names, e.g., get_crime_categories, get_neighbourhood_events.
21 tools is appropriate for a police data API covering forces, neighbourhoods, crimes, stop searches, and outcomes without being overwhelming.
Covers key police data aspects: forces, neighbourhoods, crimes, stop searches, outcomes, and location features. No obvious gaps for the intended domain.
Access street-level crime reports, stop and search data, and outcomes across UK police forces
UK Police MCP — wraps the UK Police Data API (free, no auth)
UK property research tools - crime stats, schools, demographics, valuations for AI.
Query UK Parliament, elections, crime stats, ONS census data, and national archives
