How does verify() prevent failed deliveries to closed restaurants?

Before dispatching, the agent calls verify(result_id, claim) with a claim like 'open now' or 'open for dinner'. Loop re-checks the record live and returns a latest_observation with a freshness timestamp. Availability is always labeled inferred: true in search results — verify() upgrades that to an observed status before the agent commits to a dispatch.

What happens when the top result turns out to be closed?

The agent calls report(result_token, 'closed') to signal that the restaurant was closed when checked. Loop updates the record's confidence score and freshness timestamp. The agent then falls back to the next candidate from search() results. Each closure report improves the data for subsequent delivery agents.

What structured data does Loop return for delivery use cases?

Each search result includes: name, address, cuisine[] (typed array), price_band (€/€€/€€€), observed_at timestamp, confidence score (0–1), cross_source_confirmed (boolean), and availability.inferred. get_details() adds opening_hours, phone, website, and the result_token required for report(). All in a consistent typed schema — no HTML parsing, no per-source format negotiation.

Food delivery agent with live restaurant data.

Q: Can a food delivery agent use Loop to find open restaurants?

Yes. The agent calls search(query, location, filters) — for example 'pizza, quick, delivery-friendly' in 'Kreuzberg, Berlin'. Loop returns typed results with cuisine[], price_band, observed_at, confidence score, and cross_source_confirmed. get_details() adds opening_hours, phone, and address for the specific record.

Before your agent dispatches a delivery, it needs to know the restaurant is actually open. Loop's verify() upgrades stale availability labels to live observations. report() feeds outcomes back — every closed-restaurant signal improves the data for the next agent.

the problem stale hours cost every delivery agent

Restaurant hours change without notice. A delivery agent relying on static place data will occasionally dispatch to a closed restaurant — a bad outcome for the user and a wasted signal. Loop's verify() re-checks availability live before the agent acts, and report() writes the outcome back so the next agent starts with fresher data.

agent flow search → verify → dispatch → report

Step 1search()Find restaurants matching the delivery request — natural language, typed filters

search()

{
  "name": "search",
  "arguments": {
    "query": "pizza, quick delivery, open now",
    "location": "Kreuzberg, Berlin",
    "filters": {
      "price_band": "€€"
    }
  }
}

// → typed results:
// {
//   "result_id": "osm_node_98765432",
//   "name": "Pizzeria da Marco",
//   "cuisine": ["italian", "pizza"],
//   "price_band": "€€",
//   "observed_at": "2026-06-12T...",
//   "confidence": 0.91,
//   "cross_source_confirmed": true,
//   "availability": { "status": "likely_open_now", "inferred": true }
// }

Step 2get_details()Fetch phone, address, and hours for the top candidate

get_details()

{
  "name": "get_details",
  "arguments": {
    "result_id": "osm_node_98765432"
  }
}

// → full record:
// {
//   "name": "Pizzeria da Marco",
//   "address": "Oranienstraße 12, 10999 Berlin",
//   "phone": "+49 30 ...",
//   "opening_hours": "Mo-Su 11:00-23:00",
//   "location": { "lat": 52.499, "lng": 13.418 },
//   "result_token": "eyJ...",   // required for report() — expires 30 min
//   "confidence": 0.91
// }

Step 3verify()Confirm the restaurant is open before dispatching the order

verify()

{
  "name": "verify",
  "arguments": {
    "result_id": "osm_node_98765432",
    "claim": "open now"
  }
}

// → live observation:
// {
//   "verified": true,
//   "latest_observation": {
//     "status": "open",
//     "observed_at": "2026-06-12T19:42:00Z",
//     "inferred": false   // ← upgraded from inferred to observed
//   },
//   "confidence": 0.94
// }

Step 4report()Close the feedback loop after the delivery outcome is known

report()

{
  "name": "report",
  "arguments": {
    "result_token": "eyJ...",
    "outcome": "correct"
  }
}

// outcome enum:
// "correct"  — data matched reality (restaurant was open, order placed)
// "wrong"    — hours or details were inaccurate
// "closed"   — restaurant was closed at dispatch time
// "booked"   — order was placed and confirmed
// "other"    — any other outcome

// → { "recorded": true, "confidence_delta": +0.02 }

why verify before dispatch

Without Loop verify()	With Loop verify()
Availability from static tags (inferred)	Live re-check, freshness timestamp
No signal when restaurant is closed	report('closed') updates confidence score
Next agent repeats the same failed lookup	Next agent gets upgraded confidence from reports
Stale hours silently accepted	inferred: true label always surfaced to agent

common questions

Can a food delivery agent use Loop to find open restaurants?

Yes. Call search(query, location, filters) — for example "pizza, open now" in "Kreuzberg, Berlin". Results include cuisine[], price_band, observed_at, and confidence. Use get_details() to get opening_hours and phone.

How does verify() prevent failed deliveries?

Before dispatching, call verify(result_id, "open now"). Loop re-checks the record live and returns a latest_observation with an inferred: false flag. Availability in search results is always inferred: true until verify() confirms it.

What happens if the top result is closed?

Call report(result_token, "closed")to signal the closure. Loop updates the record's confidence score and freshness timestamp. Then fall back to the next result from search(). Each closure report makes the data better for subsequent delivery agents.

Is an API key required?

No. The free tier accepts unauthenticated connections to https://stayinloop.dev/mcp. For higher-volume delivery pipelines, apply for a key at stayinloop.dev/#pricing.

Connect to Loop Restaurant booking agent Hotel concierge agent