# Mercantry Registry (remote · mercantry.org)

Agent-native registry: 168k+ real restaurants in LA, Hong Kong & Tokyo. Unranked, honest signals.

- Trust score: 64/100 (medium)
- Change this week: +5
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `mercantry.org`: 64/100 (this document), [markdown](https://verifymcp.io/servers/org-mercantry-registry/mercantry.md), [page](https://verifymcp.io/servers/org-mercantry-registry/mercantry)

## Channel facts

- Endpoint: `https://mercantry.org/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.1.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 57/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation not fully verified: no authorisation is required to call this server, and 9 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe.
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 67/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 1570 tokens (~174/item across 9 items; 9 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 83/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 49% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http org-mercantry-registry https://mercantry.org/mcp
```

### Codex

```toml
[mcp_servers.org-mercantry-registry]
url = "https://mercantry.org/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "org-mercantry-registry": {
      "type": "remote",
      "url": "https://mercantry.org/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add org-mercantry-registry --url https://mercantry.org/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  org-mercantry-registry:
    url: "https://mercantry.org/mcp"
```

### Other

```json
{
  "mcpServers": {
    "org-mercantry-registry": {
      "type": "http",
      "url": "https://mercantry.org/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-03 (score 64, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27. That category is still filling its 30-day observation window: 7 days of observed history at the previous scan, 8 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-01 (score 63, +1)

No change was recorded against any check on this day. Stability & Change Management went from 17 to 20. That category is still filling its 30-day observation window: 5 days of observed history at the previous scan, 6 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 62, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 61, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-28 (score 60, +1)

No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 59, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 58)

First indexed and scored.

## MCP tools (9)

### `search_merchants` (~426 tokens)

Search merchants

Filter-based search over the restaurant registry (coverage cities + timezones in get_registry_meta). NOT ranked: results come back in deterministic order (merchant_id ASC by default; distance ASC when lat/lng given and order_by="distance"). Returns compact records with pagination. Use get_merchant for the full signal dump on a specific merchant. All filters are optional and combinable.

Input parameters:

- `attribute_tags` (array): Match ALL of these attributes, e.g. ['outdoor_seating','vegetarian_friendly']
- `bookable_only` (boolean): Only merchants the registry can book right now (phone-verified, accepts reservations, not opted out)
- `cuisine_tags` (array): Match ANY of these cuisines, e.g. ['japanese','korean']
- `lat` (number): Latitude for geo-radius filter (requires lng and radius_km)
- `limit` (integer)
- `lng` (number)
- `neighborhood` (string): Exact neighborhood name, e.g. 'Mission'
- `offset` (integer)
- `open_at` (string): ISO-8601 datetime; only merchants open at this time. With an explicit offset ('2026-07-18T19:00:00+09:00' or trailing Z) the instant is evaluated in each merchant's own timezone; without one it means…
- `order_by` (string)
- `party_size` (integer): Only merchants that can seat this party size
- `price_band_max` (integer)
- `price_band_min` (integer)
- `radius_km` (number): Radius in km around lat/lng
- `sandbox` (boolean): Filter by merchant kind. true = sandbox test merchants only (safe integration targets: they book end-to-end and return a SIMULATED confirmation, never dialing a real venue). false = real merchants on…

### `get_merchant` (~63 tokens)

Get merchant (full signal dump)

Every field the registry holds on one merchant: schema fields, structured hours, raw feedback history, platform-observed operational stats, and per-field provenance with timestamps. Maximal data, zero opinion — the registry never scores or ranks.

Input parameters:

- `merchant_id` (string, required)

### `get_availability` (~64 tokens)

Get availability (honest v1 behavior)

V1 does NOT hold live table availability — availability is checked on the phone call at booking time. This tool returns the merchant's reservation policy, structured hours, and holiday exceptions so you can pick a plausible time before calling place_booking.

Input parameters:

- `merchant_id` (string, required)

### `place_booking` (~503 tokens)

Place a booking (async)

Request a table reservation. Returns booking_id with state 'queued' immediately; fulfillment is asynchronous (a call is placed to the merchant). Poll get_booking_status or supply callback_url for webhooks. RETRY SAFETY: pass a unique client_reference_id (recommended: always); if this call times out or errors ambiguously, retry with the SAME client_reference_id and the registry returns the already-created booking instead of double-booking the restaurant. Never re-call place_booking after a timeout without one. If the merchant counter-offers a time within window_minutes and accept_within_window=true, it is auto-accepted (recommended). Otherwise the booking pauses in needs_input for you to resolve via modify_booking. Merchants on the human_call channel are fulfilled by a human operator during the operator window published in get_registry_meta — those bookings queue until worked (up to the channel SLA), so book ahead rather than for the next hour.

Input parameters:

- `accept_within_window` (boolean): Auto-accept merchant counter-offers inside the window (recommended: true)
- `callback_url` (string): Webhook URL for booking state-change events
- `client_reference_id` (string): Your unique ID for this booking request (a UUID is ideal). Retrying with the same value returns the existing booking (idempotent_replay: true) instead of creating a duplicate; the same value with dif…
- `contact` (string): Optional phone/email for confirmation relay to the end human
- `datetime` (string, required): Requested time, ISO-8601. Naive ('2026-07-18T19:00') means the merchant's LOCAL wall time (see the merchant's timezone field); an explicit offset ('2026-07-18T19:00:00+09:00') is also accepted
- `merchant_id` (string, required)
- `party_size` (integer, required)
- `reservation_name` (string, required): Name for the reservation
- `sandbox_outcome` (string): TEST ONLY, sandbox merchants (sandbox: true): force the simulated call's result so you can exercise a specific branch on demand — confirmed, no_answer (retries then fails), counter_offer (pauses in n…
- `special_requests` (string)
- `window_minutes` (integer): Acceptable +/- window around datetime

### `get_booking_status` (~106 tokens)

Get booking status

State machine position for a booking: pending → queued → in_progress → confirmed | failed | needs_input (plus cancelled). Includes structured details on confirmation (confirmed_time, confirmation_code, merchant_instructions), structured failure reason (no_answer | fully_booked | closed | policy_mismatch | merchant_declined | bad_data), or needs_input options awaiting your decision. include_events=true returns the full audit log.

Input parameters:

- `booking_id` (string, required)
- `include_events` (boolean)

### `modify_booking` (~143 tokens)

Modify a booking / resolve needs_input

Amend a booking before or after the call. For a booking in needs_input: pass accept_option_index to take one of the merchant's offered times (confirms immediately), or pass a new datetime/party_size to re-queue an amended request. Modifying an already-confirmed booking cancels it and books the new request (new booking_id returned).

Input parameters:

- `accept_option_index` (integer): Index into needs_input_options to accept
- `booking_id` (string, required)
- `datetime` (string): New requested time, ISO-8601; naive means the merchant's local wall time
- `party_size` (integer)
- `window_minutes` (integer)

### `cancel_booking` (~69 tokens)

Cancel a booking

Cancel a booking in any non-terminal state, or a confirmed reservation (the registry notifies the merchant). Cancellation is mandatory when the human no longer wants the table — no-shows destroy merchant trust and are tracked per developer key.

Input parameters:

- `booking_id` (string, required)
- `reason` (string)

### `submit_feedback` (~136 tokens)

Submit post-visit feedback

Report how a confirmed reservation actually went. Accepted only against a confirmed booking_id, once per booking, within 14 days of confirmation. Structured fields first; optional free text ≤ 500 chars. This corpus is served raw to all agents via get_merchant — it is never editorialized or turned into a score.

Input parameters:

- `booking_id` (string, required)
- `free_text` (string)
- `matched_description` (boolean): Did the merchant match the registry's description?
- `reservation_honored` (boolean, required): Did the merchant honor the reservation?
- `seated_on_time` (boolean)
- `would_repeat` (boolean)

### `get_registry_meta` (~60 tokens)

Get registry metadata

Evaluate the registry itself: per-city coverage (with each city's IANA timezone), merchant/bookable counts, verification and freshness stats, feedback corpus size, schema version, and the documented deterministic ordering rule. Honest by design — including how stale the data is.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/org-mercantry-registry/mercantry#diagnostics

## Score history

- 2026-08-03: 64
- 2026-08-02: 63
- 2026-08-01: 63
- 2026-07-31: 62
- 2026-07-30: 61
- 2026-07-29: 60
- 2026-07-28: 60
- 2026-07-27: 59
- 2026-07-26: 58

## Links

- Remote endpoint: https://mercantry.org/mcp
- Repository: https://github.com/mercantry/registry
- Website: https://mercantry.org/
- Changelog RSS feed: https://verifymcp.io/servers/org-mercantry-registry/mercantry/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/org-mercantry-registry/mercantry/changelog.json
- HTML version of this page: https://verifymcp.io/servers/org-mercantry-registry/mercantry