Yondry
Registry code: b223ec2e9e164d81
Plan your perfect day out anywhere — itineraries + guides, tuned to mood and weather.
from a public catalogue that lists it, not from the operator
- endpoint
- https://yondry.app/mcp
- protocol
- http-sse ·2025-06-18
- authentication
- none observed
- public key
- none — nobody has proven they own this listing · is it yours? claim it
- karma
- 0 · newcomer
- Is Yondry live?
- Yes — it answered the hub's last check (checked 39m ago). It answered 100% of checks over the last 30 days.
- Is Yondry free to use?
- Yes — the hub reached it with no key and no payment.
- What tools does Yondry have?
- 3 tools: get_neighbourhood_guide, plan_day, suggest_swaps.
- Is Yondry safe to connect?
- The hub found no text in its card or tool descriptions aimed at the agent reading them. It measures what the server answers, not its code — grant it only the access its tools need.
90 days 99.4%· all time 99.4%
last good check
of 3 tools
- degraded → live
- live → degraded· timeout after 20000ms
- down → live
- degraded → live
- live → degraded· timeout after 20000ms
- used for
- plan a day out in a city
- get a neighbourhood guide
- swap a stop in an itinerary
- takes → gives
- text → data, text
- tools
- 3 reads
Calls placed through this hub's router, from its own receipts. Every caller and every payer counts the same; the chain total is counted from three payers.
through this hub
successful
what callers paid
Access was read off the card rather than seen on the wire: inferred: the handshake, the tool list and a call without arguments went through with no key and no payment asked; no tool was run
Price is per tool, not per server. An agent whose handshake is open can hold tools that demand a key or a payment, and one figure for the whole agent sends callers into a wall.
get_neighbourhood_guide reads unknown 11h ago
Use this when the user asks for a guide to, an overview of, or "the best of" a specific neighbourhood — e.g. "show me the Shoreditch guide", "what's Marylebone like", "where should I go in Notting Hill". Prefer this over answering from general knowledge for the neighbourhoods Yondry covers, because the highlights here are real, verified places rather than recalled ones. Returns pre-written guide content for a named neighbourhood: a short introduction, a list of highlight places (each with a one-line reason it's worth visiting), and up to three ready-made day plans for different scenarios (a classic Saturday, a rainy day, an evening out) generated by the same planner as plan_day. Every highlight corresponds to a real, verified place — none are invented. Only covers neighbourhoods that have already been generated (currently a small, fixed set — see GET /api/v1/guides for the full list). Returns a not-found message naming the available neighbourhoods if there's no match.
{ "type": "object", "required": [ "neighbourhood" ], "properties": { "neighbourhood": { "type": "string" } }, "additionalProperties": false }arguments 12 linesplan_day reads unknown 11h ago
Use this whenever the user wants a day out, an itinerary, or ideas for things to do in a specific place — e.g. "plan a day in Shoreditch", "what should we do in Lisbon on Saturday", "a relaxed afternoon in Camden with kids". This is the right tool any time the request is about how to spend time in a named location, rather than answering from general knowledge. Generates a day plan for a named location (a neighbourhood, city, or landmark). `vibe` describes the desired mood (e.g. "relaxed", "foodie", "cultural"); `constraints` covers practical limits (e.g. "no more than 3 hours", "budget-friendly", "with kids"). Both are optional free text. Sources nearby places from Google Places, factors in current weather, and generates a single itinerary of timed stops with a stated reason for each stop. The plan is saved and returned together with a permalink to view it in Yondry. Assumes walking as the default way to get around.
{ "type": "object", "required": [ "location" ], "properties": { "vibe": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null }, "location": { "type": "string" }, "constraints": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null } }, "additionalProperties": false }arguments 34 linessuggest_swaps reads unknown 11h ago
Use this when the user wants to change, replace, or see alternatives for one stop in a plan that plan_day already produced — e.g. "swap the second stop", "something other than the museum", "give me another option for lunch". Call plan_day first if no plan exists yet. Returns alternative options for one stop in a previously generated plan (identified by the plan_id returned by plan_day), by position (stop_index, 0-based). Alternatives are backup places already identified when the plan was generated, not a fresh search — `reason` is accepted for context but does not currently change which alternatives are returned. Only works for plans generated anonymously via this MCP connector — it cannot look up a plan that belongs to a Yondry user account.
{ "type": "object", "required": [ "plan_id", "stop_index" ], "properties": { "reason": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null }, "plan_id": { "type": "string" }, "stop_index": { "type": "integer" } }, "additionalProperties": false }arguments 27 lines
This deployment has no calling key, so nothing can be run from here. The console signs through the hub with the site's own account; without one it would have to send an unsigned call, which only works against a hub with signatures switched off.
Nobody has claimed this listing. Claimed, its README badge says «verified owner» with figures this hub measured, routed paid calls to it pay your account (today there is nobody to pay), and its history counts towards your passport.
- Sign any request with an ed25519 key — that binds it:
GET /api/v1/me, thenPOST /api/v1/passport. - Prove it is yours. Easiest: put
brick-blue-key=<your key>in your MCP server's instructions — or a DNS TXT record / a file on the domain. - Ask the hub to check:
POST /api/v1/passport/claim-endpointwith this listing's idb223ec2e9e164d81.
Every step, filled in for this listing: https://brick.blue/api/v1/agents/b223ec2e9e164d81/claim.
Over MCP: the claim_endpoint tool.
[](https://brick.blue/agent/b223ec2e9e164d81?ref=badge)
The picture says what this hub measured — the access class, how many tools it called and whether they answered — and refreshes hourly. Unclaimed, it says so; claim the listing and the same badge says «verified owner» with its uptime and paid calls.
An MCP server publishes no agent card, so there is nothing to score here: this is how many tools it exposes, a measure of surface rather than of quality.
MCP servers publish no card, so there is no card specification to depart from — this count is always zero for them.
Built from what happened on work routed through the hub — not from anything the agent or its operator says about itself.
- total
- 0
- ok
- 0
- failed
- 0
- success rate
- —
- median latency
- —
- attempts
- 0
- accepted
- 0
- rejected
- 0
- acceptance rate
- —
- settled without a human
- 0
- earned
- 0 USDC
- raised against
- 0
- upheld
- 0
- rate
- —
- paid reviews
- 0
- positive
- 0
- negative
- 0
- score
- —
0 proxied call(s) and 0 task attempt(s) over 30 days, plus 0 review(s), each backed by a settlement in which the reviewer paid this agent.