MapMap

verify_places

Check whether places (and itineraries) an AI mentioned are real, findable and physically possible. Pass structured claims (reliable, and the only path that supports itinerary feasibility) or free text (best-effort quoted-phrase extraction). Each claim resolves to exactly one of three verdicts, never a boolean: "verified" (matched a real place, with its stable id and the source/date of the evidence), "contradicted" (a specific, dated, sourced fact rules it out, currently only an itinerary leg the routing engine proves cannot be driven in the stated time, with the computed travel time as evidence), or "unverified" (no evidence either way). This tool NEVER asserts that a named real business does not exist or has closed, that would be a defamation risk with no upside; a missing match is always "unverified". Claims sharing increasing sequence values and both carrying claimed_time (ISO 8601) form itinerary legs checked for feasibility via matrix, catching e.g. "breakfast in Bath, 10am meeting in Edinburgh". Max 20 claims per request. A claim takes only id, name, locality, sequence and claimed_time; any other field (e.g. near) is refused naming the accepted ones, so put disambiguating context such as a town in locality. The response's summary field is a concise plain-text digest (also returned as this tool result's text content) so clients that drop structured/non-text content blocks still see the verdicts.

Input Schema

Name	Required	Description	Default
`text`	No	Free text to extract place claims from (best-effort heuristic: quoted phrases and Title Case runs after "at/in/near/to/from/ visiting", not NLP or an LLM call, and it does not attempt itinerary feasibility since there are no explicit times to anchor legs to). Mutually exclusive with `claims`. Max 8,000 characters.
`claims`	No	Structured claims, the reliable path, and the only path that supports itinerary feasibility. Mutually exclusive with `text`. Max 20 per request.
`costing`	No	Costing for feasibility legs: "auto" (default), "truck", "bicycle", "pedestrian" or "motor_scooter".	auto

Output Schema

Name	Required	Description	Default
`results`	Yes
`summary`	Yes	Always present: a concise plain-text summary alongside the structured `results`, several MCP clients (notably ChatGPT connectors) drop non-text content blocks, so this must stand on its own. This same string is also returned as the tool call's text content block, not only inside the structured JSON.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 19, 2026

addedInput schema / $defs / VerifyClaimInput / additionalProperties
```
Added value: +false
```

changedInput schema / $defs / VerifyClaimInput / description

Previous value: -"One place claim for the `verify_places` tool: a place an AI mentioned,\nto be checked for existence and (as part of an itinerary) feasibility."New value: +"One place claim for the `verify_places` tool: a place an AI mentioned,\nto be checked for existence and (as part of an itinerary) feasibility.\n\nUnknown fields are refused, naming the accepted ones. A dev-lane run\n(19 Oct 2026) passed `near` instead of `locality`; it was silently\ndropped, \"Roman Baths\" matched Ankara, and the itinerary leg became\nuncomputable with nothing telling the caller why."

addedInput schema / additionalProperties
```
Added value: +false
```

Changed7 schema fields changedOct 17, 2026

changedInput schema / $defs / VerifyClaimInput / properties / locality / description

Previous value: -"Optional disambiguating context, e.g. \"Oxford\". Country-level words\n(\"UK\", \"England\", …) are stripped before querying — they add noise,\nnot signal, to name search."New value: +"Optional disambiguating context, e.g. \"Oxford\". Country-level words\n(\"UK\", \"England\", …) are stripped before querying, they add noise,\nnot signal, to name search."

changedInput schema / properties / claims / description

Previous value: -"Structured claims — the reliable path, and the only path that\nsupports itinerary feasibility. Mutually exclusive with `text`.\nMax 20 per request."New value: +"Structured claims, the reliable path, and the only path that\nsupports itinerary feasibility. Mutually exclusive with `text`.\nMax 20 per request."

changedInput schema / properties / text / description

Previous value: -"Free text to extract place claims from (best-effort heuristic:\nquoted phrases and Title Case runs after \"at/in/near/to/from/\nvisiting\" — not NLP or an LLM call, and it does not attempt\nitinerary feasibility since there are no explicit times to anchor\nlegs to). Mutually exclusive with `claims`. Max 8,000 characters."New value: +"Free text to extract place claims from (best-effort heuristic:\nquoted phrases and Title Case runs after \"at/in/near/to/from/\nvisiting\", not NLP or an LLM call, and it does not attempt\nitinerary feasibility since there are no explicit times to anchor\nlegs to). Mutually exclusive with `claims`. Max 8,000 characters."

changedOutput schema / $defs / VerifyEvidence / properties / detail / description

Previous value: -"Short factual note, always from a fixed template (see\n`crate::verify`) — never free-form text that could assert\nnon-existence or closure."New value: +"Short factual note, always from a fixed template (see\n`crate::verify`), never free-form text that could assert\nnon-existence or closure."

changedOutput schema / $defs / VerifyFeasibilityStatus / oneOf

Previous value: -[
-  {
-    "enum": [
-      "feasible",
-      "impossible"
-    ],
-    "type": "string"
-  },
-  {
-    "const": "implausible",
-    "description": "Tight — flagged, but not asserted as impossible (not certain enough\nto contradict).",
-    "type": "string"
-  }
-]New value: +[
+  {
+    "enum": [
+      "feasible",
+      "impossible"
+    ],
+    "type": "string"
+  },
+  {
+    "const": "implausible",
+    "description": "Tight, flagged, but not asserted as impossible (not certain enough\nto contradict).",
+    "type": "string"
+  }
+]

changedOutput schema / $defs / VerifyVerdict / description

Previous value: -"The three-state verdict — see `crate::verify` module docs for why\nthere is no fourth \"does not exist\" state and never a boolean."New value: +"The three-state verdict, see `crate::verify` module docs for why\nthere is no fourth \"does not exist\" state and never a boolean."

changedOutput schema / properties / summary / description

Previous value: -"Always present: a concise plain-text summary alongside the\nstructured `results` — several MCP clients (notably ChatGPT\nconnectors) drop non-text content blocks, so this must stand on\nits own. This same string is also returned as the tool call's text\ncontent block, not only inside the structured JSON."New value: +"Always present: a concise plain-text summary alongside the\nstructured `results`, several MCP clients (notably ChatGPT\nconnectors) drop non-text content blocks, so this must stand on\nits own. This same string is also returned as the tool call's text\ncontent block, not only inside the structured JSON."

First observedSep 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: it enumerates the three verdicts, forbids boolean returns, discloses the defamation-driven rule that a missing match is always 'unverified' (never 'does not exist'), names the only contradiction case, describes the sequence+claimed_time leg mechanics, and warns that unknown fields are refused with the accepted list.

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?

Purpose, then the two input paths, then verdict semantics, then constraints and the summary fallback – a sensible front-loaded order. It runs long and repeats the leg-feasibility rule that the schema also states, which keeps it short of maximally tight.

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 non-trivial verification tool with an output schema, the description supplies everything the schema cannot: verdict semantics, the never-assert-nonexistence policy, the one contradiction path, the 20-claim and 8,000-char limits, and the text-content `summary` fallback for clients that drop structured blocks.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds interpretation: it restates the accepted claim fields, explains that `near` is refused and disambiguating context belongs in `locality`, and ties `sequence`/`claimed_time` to leg building. Much of this overlaps with the schema's own field descriptions, so the marginal gain is real but not large.

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+resource+scope: 'Check whether places (and itineraries) an AI mentioned are real, findable and physically possible.' The three-verdict model and the itinerary-feasibility angle clearly separate it from siblings like nearby_places, geocode and matrix, which it references as an internal component rather than a peer.

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?

Explicitly frames the two entry paths and when each applies: structured `claims` is 'reliable, and the only path that supports itinerary feasibility', while free `text` is 'best-effort quoted-phrase extraction'. It also states the mutual exclusion and the 20-claim limit, so selection between the modes is unambiguous.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?