Boundr

find_boundaries_at_point

Find all UK administrative boundaries that geographically contain a coordinate point.

Use this to answer "what county/borough/ward is this location in?" for a latitude/longitude. Returns lightweight metadata only — no geometry. If you need to display a boundary shape, call get_boundary_geojson_by_code() with the returned code.

Multiple boundaries at different administrative levels typically contain the same point (e.g. a ward, a borough, and a county). Filter by boundary_types to restrict which levels are returned.

Call list_boundary_type_codes() first if you are unsure which type codes to use.

Input Schema

TableJSON Schema

Name	Required	Description
`lat`	Yes	Latitude in decimal degrees. Must be between -90 and 90. Example: 51.5074 (central London).
`lng`	Yes	Longitude in decimal degrees. Must be between -180 and 180. Example: -0.1278 (central London).
`boundary_types`	No	Optional list of type codes to restrict results, e.g. ["CTY", "LBO"]. All levels are returned if omitted.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description fully discloses that the tool returns lightweight metadata without geometry, that multiple boundaries may be returned, and that filtering is possible. It does not mention authentication or rate limits, but the behavioral scope is well-covered for a read-only spatial query.

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?

The description is efficiently structured into short, focused paragraphs. Every sentence adds value (purpose, usage, filtering, prerequisite). No unnecessary repetition. Slightly longer due to multiple pieces of guidance, but all are relevant.

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 that an output schema exists, the description does not need to detail return values. It covers purpose, when to use, filtering, and references to sibling tools. It is complete for a tool of moderate complexity with 3 parameters.

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%, so the schema already fully describes the parameters. The description adds some contextual value (e.g., example types like 'CTY', 'LBO') but does not significantly augment the meaning beyond what the schema provides. Baseline of 3 is appropriate.

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?

The description clearly states it finds UK administrative boundaries containing a coordinate point. It specifies 'lightweight metadata only — no geometry', distinguishing it from sibling tools like get_boundary_geojson_by_code. The verb 'find' and resource 'boundaries at point' are explicit.

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?

Provides explicit when-to-use (answer location queries) and when-not-to-use (for geometry, use get_boundary_geojson_by_code). Includes guidance on filtering by boundary_types and a prerequisite call to list_boundary_type_codes if unsure. Alternatives are clearly named.

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

All Boundr tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0

Disambiguation5/5

Each tool targets a distinct operation: point lookup, bounding box, metadata by code, full geometry, simplified geometry, type codes listing, and name search. Even the two geometry tools are clearly differentiated by simplification level.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., find_boundaries_at_point, get_boundary_bbox, list_boundary_type_codes). The naming is predictable and clear.

Tool Count5/5

Seven tools is well-scoped for a UK boundary lookup service. It covers all core operations without being excessive or insufficient.

Completeness5/5

The toolset provides complete coverage for readonly boundary access: name search, point lookup, metadata retrieval, bounding box, and geometry (full and simplified). No obvious gaps for the intended domain.

Resources

Need Help?