OSM Edit MCP Server

Overview Schema Source Related Servers Discussions Admin

preview_track_road_edit

Read-onlyIdempotent

Preview a proposed road edit as a non-writing GeoJSON and element diff without uploading to OSM, so you can review OAuth-bound changes before applying them.

Instructions

Build a non-writing GeoJSON and element diff preview for a road edit. Requires OAuth with write_api: the stored proposal is bound to the verified OSM account and API target before review. Read-only means no OSM upload, not anonymous access. For an OAuth-free geometry view use analyze_gpx_track, create_track_selection and its preview_uri instead. After the user explicitly asks to publish the reviewed proposal, call apply_osm_edit immediately. Do not ask for another chat confirmation: apply_osm_edit itself opens the single required digest-bound confirmation.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>",
      "changeset_comment": "<changeset_comment>",
      "changeset_source": "<changeset_source>"
    },
    "name": "preview_track_road_edit"
  }
}

Input Schema

Name	Required	Default
`tags`	No
`action`	Yes
`gpx_xml`	No
`gpx_path`	No
`segment_id`	No
`selection_id`	No
`evidence_kind`	No	survey_gpx
`target_way_ids`	No
`changeset_source`	Yes
`changeset_comment`	Yes
`evidence_provider`	No
`evidence_observed_at`	No
`simplify_tolerance_m`	No
`max_alignment_distance_m`	No
`connect_endpoints_to_ways`	No
`endpoint_snap_tolerance_m`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.1Sep 5, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the readOnlyHint/idempotent/openWorld annotations, it discloses the auth requirement, that the stored proposal is bound to the verified OSM account and API target before review, and resolves the potentially confusing 'read-only' framing by stating it means no OSM upload, not anonymous access. It also discloses that apply_osm_edit itself opens the single digest-bound confirmation, preventing a redundant confirmation loop.

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 purpose and the read-only clarification are front-loaded, and each sentence contributes auth, alternative routing, or workflow sequencing. It runs slightly long for the content, but there is no filler or repeated information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Auth, safety semantics, sibling routing, and the downstream apply step are covered, and an output schema exists so return values need no explanation. However, for a 16-parameter tool with zero schema descriptions, the complete absence of parameter guidance leaves a material gap in an otherwise complete definition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 16 parameters, and the description names none of them: action, changeset_comment/source, target_way_ids, simplify_tolerance_m, max_alignment_distance_m, connect_endpoints_to_ways and the rest are left entirely unexplained. Only indirect framing (a 'road edit' proposal bound to an account) hints at what must be supplied, so the description largely fails to compensate for the schema 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?

The description gives a specific verb and artifact: builds a 'non-writing GeoJSON and element diff preview for a road edit'. It distinguishes itself from apply_osm_edit (the publishing step) and from the OAuth-free geometry path (analyze_gpx_track / create_track_selection), so an agent can route correctly without opening a schema.

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?

It states preconditions (OAuth with write_api), names the alternative for the OAuth-free case, and specifies the exact follow-on action after the user explicitly asks to publish (call apply_osm_edit immediately, no extra chat confirmation). That is explicit when-to-use, when-not, and sequencing.

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