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. 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

TableJSON 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

TableJSON 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.

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and exceeds it: it explains the non-boolean verdicts, the defamation-avoidance rule, how sequence/claimed_time trigger routing-based contradiction checks, the 20-claim limit, and that `summary` is surfaced as text content. This is exemplary disclosure for a tool with this complexity.

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?

Though long, every sentence earns its place: purpose, mode selection, verdict semantics, a crucial behavioral caveat, itinerary feasibility, request limits, and output-format note. The structure front-loads the primary action and then layers necessary detail without fluff.

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 tool with three parameters, no annotations, and real behavioral nuance, the description is complete: it covers input-mode tradeoffs, verdict semantics, constraints, edge-case behavior, and response-format quirks. The presence of an output schema means the description does not need to enumerate return fields, and nothing an agent needs to call the tool correctly is missing.

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 the baseline is 3. The description adds real semantic value beyond the schema by labeling `claims` as the reliable path, `text` as best-effort heuristic extraction, and explaining why `sequence` and `claimed_time` together enable feasibility checks. It does not merely repeat schema text.

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 opening sentence states a specific verb and resource: checking whether places and itineraries an AI mentioned are real, findable, and physically possible. The three-verdict model (verified/contradicted/unverified) further sharpens what the tool does and clearly distinguishes it from geocoding or place-search siblings.

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 description explicitly tells agents when to use structured `claims` versus free `text`, and notes that only `claims` supports itinerary feasibility. It does not explicitly name sibling alternatives like `geocode` or `nearby_places` as things to use instead, but the usage context is clear enough for a unique-purpose tool.

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?