MapMap

geo_point_in_polygon

Whether a coordinate lies inside a polygon: delivery zones, catchments, congestion or clean-air zones, site boundaries. Provide point {lat, lon} and polygon as 3+ {lat, lon} coordinates of the outer ring (closed automatically if the last does not repeat the first). Points exactly on the boundary count as OUTSIDE. Local computation: no network call, no quota.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`point`	Yes	The coordinate to test.
`polygon`	Yes	The polygon's outer ring, 3 or more coordinates. Closed automatically if the last point does not repeat the first.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`inside`	Yes	True when the point is strictly inside the ring. Points exactly on the boundary are not counted as inside.

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 carries the full behavioral disclosure burden. It reveals two non-obvious behaviors: boundary points are treated as OUTSIDE, and the polygon closes automatically if the last coordinate doesn't repeat the first. It also reassures about local computation with no network or quota. A brief statement about being read-only is absent but implied by the query phrasing.

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

Conciseness5/5

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

Every sentence earns its place: a clear purpose statement, concrete use cases, required inputs, the boundary caveat, and the local-computation guarantee. The information is front-loaded and there is no wasted wording.

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?

For a two-parameter boolean geospatial predicate with an output schema, the description covers all necessary behavioral context: input shape, closure behavior, boundary semantics, and cost characteristics. Nothing an agent needs to invoke and interpret the tool correctly is missing.

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 baseline is 3. The description restates the point and polygon shape plus the 3+ coordinate requirement, but the schema already documents the LatLon fields, required minimum, and automatic closure. The description adds minimal semantic value beyond the structured 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?

The description begins with a precise predicate — 'Whether a coordinate lies inside a polygon' — and names concrete use cases (delivery zones, catchments, clean-air zones, site boundaries). This clearly distinguishes it from sibling geometry tools like geo_distance, geo_area, or geo_bbox.

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

Usage Guidelines4/5

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

The context is clear: use this when the question is point-in-polygon containment, with examples of typical polygon types. It does not explicitly list sibling alternatives or when-not-to-use it, but the predicate itself makes the applicable situation obvious. The 'local computation, no quota' note further helps selection.

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

All MapMap 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/5.0

Disambiguation4/5

Most tools target a distinct action and resource pair, and descriptions are explicit about which tool fits which scenario. The closest overlaps—plan_ev_route vs cheapest_charging_along_route, and route vs plan_day vs order_stops vs optimise_routes—are mitigated by clear guidance, so an agent can usually pick correctly.

Naming Consistency4/5

Tool names overwhelmingly follow a verb_noun snake_case pattern (plan_ev_route, set_palette, list_style_layers) with a consistent geo_ prefix for geometry helpers. Minor deviations like elevation, route, and matrix are short and readable but break the strict verb_noun convention.

Tool Count2/5

At 39 tools, this surface is well past the 25+ threshold and feels heavy even for a broad mapping platform. The set spans routing, geocoding, places, styles, EV/fuel, telematics, usage, and feedback, which would be easier for an agent to navigate if split into smaller domain-focused servers.

Completeness4/5

For the stated breadth, coverage is strong: routing, multi-stop planning, VRP, EV/fuel detours, geocoding, places, geometry, style lifecycle, and telematics all have workable primary paths. Minor gaps like no style deletion, no route alternatives, and no batch geocoding are present but do not create dead ends for core workflows.

Resources

Need Help?