overture-maps

overture_compare_releases

Read-onlyIdempotent

Compare two Overture Maps release snapshots by ID for the same area and filters. Returns added, removed, modified, and unchanged counts plus paginated changes with before/after properties.

Instructions

Compare two available release snapshots by ID in the same area and filters.

    Returns exact added/removed/modified/unchanged counts and paginated changes, including
    before/after properties and schema changes. Compares all properties regardless of
    fields selection, plus topological geometry equality. <=5000 records per snapshot.
    Added/removed can mean crossing scope/filters; not global creation/deletion. IDs in
    Addresses/Base/building_part lack GERS stability. Use catalog for available releases.

Input Schema

TableJSON Schema

Name	Required	Default
`after`	Yes
`limit`	No
`theme`	Yes
`before`	Yes
`bounds`	Yes
`cursor`	No
`fields`	No
`status`	No	all
`filters`	No
`feature_type`	Yes

Output Schema

TableJSON Schema

Name	Required	Default
`data`	Yes
`scope`	No
`theme`	No
`source`	Yes
`license`	Yes
`release`	Yes
`warnings`	No
`next_cursor`	No
`feature_type`	No
`attribution_url`	No	https://docs.overturemaps.org/attribution/

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 4, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: return payload shape (counts plus paginated changes with before/after properties and schema changes), a size cap (<=5000 records per snapshot), and important semantic caveats about added/removed meaning scope-crossing rather than global creation/deletion, plus the ID-stability warning for Addresses/Base/building_part.

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 core comparison purpose in the first sentence, then packs operational caveats into compact clauses. Dense but nearly every sentence carries non-obvious information; minor redundancy around naming the catalog sibling is acceptable.

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 a 10-parameter tool with a nested Bounds/AttributeFilter schema and an existing output schema, the description covers the critical gaps: scope constraints, result semantics, size limits, and ID reliability. It could do more to explain theme/status/cursor parameters, but for a read-only comparison tool it is largely complete.

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?

The description clarifies that before/after are snapshot IDs, that filtering happens on the same area/filters, and that fields selection does not limit which properties are compared. With schema description coverage at 0% for the 10 top-level params, however, enums (theme, status) and cursor/limit semantics remain undocumented in both places, leaving a real gap.

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?

States a precise verb ('Compare') and resource ('two available release snapshots by ID') with scoping qualifiers (same area, same filters). This is clearly distinguishable from sibling tools like overture_catalog, which it explicitly names as the place to find releases.

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?

Provides clear context (need two release IDs from the same theme/area) and routes the agent to overture_catalog for available releases. It also clarifies the semantic meaning of 'added/removed'. It stops short of an explicit when-to-use-this-vs-alternatives statement, but the routing hint gives usable guidance.

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

Deploy Server