Nostr: npub1mgvlrnf5hm9yf0n5mf9nqmvarhvxkc6remu5ec3vf8r0txqkuk7su0e7q2
Справедливые места встречи для ИИ — справедливость на основе изохрон, а не простых средних точек.
MCP-сервер для поиска мест встречи с помощью ИИ. Дайте своему ИИ возможность отвечать на вопрос «где нам встретиться?», используя реальное время в пути, доступность мест и алгоритмы справедливости.
Работает «из коробки» — бесплатная публичная маршрутизация, ключи API не требуются. Разверните Valhalla самостоятельно для неограниченного количества запросов или используйте Lightning-кредиты L402 для нашего хостинг-эндпоинта.
Инструмент | Описание |
| Оценка подходящих мест по справедливости времени в пути для 2–10 участников |
| Поиск мест рядом с локацией с использованием OpenStreetMap |
| Получение полигона доступности (все места, достижимые за N минут) |
| Получение маршрута между двумя точками с пошаговыми инструкциями |
| Сохранение macaroon + preimage после Lightning-платежа |
Related MCP server: Magic Lane MCP Server
Добавьте в конфигурацию вашего MCP-клиента (Claude Code, Claude Desktop, Cursor и т.д.):
{
"mcpServers": {
"rendezvous": {
"command": "npx",
"args": ["rendezvous-mcp"]
}
}
}Затем спросите свой ИИ: «Где справедливое место для встречи Элис в Лондоне, Боба в Бристоле и Кэрол в Бирмингеме, чтобы пообедать?»
Для ChatGPT, удаленных ИИ-агентов или любого клиента, подключающегося через HTTP:
TRANSPORT=http npx rendezvous-mcpЗапускает Streamable HTTP-сервер на порту 3002 с MCP-эндпоинтом по адресу /mcp.
В настройках ChatGPT добавьте MCP-сервер со следующими данными:
URL: http://your-host:3002/mcp
Transport: Streamable HTTP
Переменная | По умолчанию | Описание |
|
| Режим транспорта: |
|
| Порт HTTP-сервера (только в режиме HTTP) |
|
| Адрес привязки HTTP (только в режиме HTTP) |
|
| URL движка маршрутизации |
| Публичные эндпоинты | API поиска мест |
Для неограниченных запросов без лимитов скорости запустите свой собственный экземпляр Valhalla:
{
"mcpServers": {
"rendezvous": {
"command": "npx",
"args": ["rendezvous-mcp"],
"env": {
"VALHALLA_URL": "http://localhost:8002"
}
}
}
}Пользователь спрашивает: «Где нам встретиться?»
ИИ геокодирует местоположения участников
ИИ вызывает search-venues для поиска подходящих мест в этом районе
ИИ вызывает score-venues с участниками и кандидатами — возвращает ранжированные результаты со временем в пути и коэффициентами справедливости
ИИ предлагает самый справедливый вариант с указанием времени в пути для каждого человека
Для более глубокого анализа ИИ может использовать get-isochrone для визуализации доступности и get-directions для пошаговой навигации.
Эндпоинт маршрутизации по умолчанию (routing.trotters.cc) предлагает бесплатные запросы. Когда бесплатный лимит исчерпан, инструменты возвращают ответ payment_required со счетом Lightning. После оплаты вызовите store-routing-credentials для сохранения macaroon для сессии.
Для самостоятельно развернутого Valhalla оплата не требуется.
Легкая MCP-обертка над rendezvous-kit — TypeScript-библиотекой с открытым исходным кодом для пересечения изохрон, поиска мест и оценки справедливости. Каждый инструмент представляет собой извлеченную функцию-обработчик (тестируемую без MCP) плюс одну строку регистрации.
npm install
npm run build
npm testПо вопросам и предложениям функций обращайтесь в GitHub Issues.
Если вы находите rendezvous-mcp полезным, рассмотрите возможность отправить чаевые:
Lightning: thedonkey@strike.me
Nostr zaps: npub1mgvlrnf5hm9yf0n5mf9nqmvarhvxkc6remu5ec3vf8r0txqkuk7su0e7q2
Get directions between two points with distance, duration, and turn-by-turn steps. Returns a GeoJSON LineString of the route geometry.
| Name | Required | Description | Default |
|---|---|---|---|
| from | Yes | Starting point | |
| to | Yes | Destination point | |
| transport_mode | Yes | Travel mode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. Description adds return value details (distance, duration, steps, GeoJSON) but does not disclose rate limits, authentication needs, or potential variability across transport modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes return values. Could mention coordinate system assumptions or global coverage limitations implied by openWorldHint, but not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description reiterates that directions are between two points but adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool gets directions between two points, including distance, duration, and turn-by-turn steps, and identifies the output as GeoJSON LineString. It distinguishes itself from siblings like get-isochrone which provides isochrones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like get-isochrone or score-venues. Does not mention prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a reachability polygon showing everywhere reachable from a point within a given travel time. Returns a GeoJSON polygon. Useful for understanding how far someone can travel.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude of starting point | |
| lon | Yes | Longitude of starting point | |
| transport_mode | Yes | Travel mode | |
| time_minutes | Yes | Maximum travel time in minutes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the tool returns a 'GeoJSON polygon', adding value beyond the annotations, which already indicate readOnlyHint and openWorldHint. However, it does not disclose further behavioral traits (e.g., underlying data source, rate limits, or computational cost). The annotations cover safety, so the description minimally supplements transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with no fluff. It front-loads the core purpose and uses plain language. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (4 required parameters, no nested objects, no output schema), the description is sufficiently complete. It explains the output format (GeoJSON polygon) and the use case. An output schema is not present, so the description partially compensates. It could mention default routing profile or data source, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all four parameters. The tool description does not add any additional meaning beyond what the schema already states. According to the rubric, high schema coverage yields a baseline of 3, and no extra value is provided, so the score is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get a reachability polygon showing everywhere reachable from a point within a given travel time.' This is a specific verb and resource, and it distinguishes the tool from siblings like get-directions and search-venues, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a general use case ('useful for understanding how far someone can travel') but does not explicitly state when to use this tool versus alternatives. It lacks exclusion criteria or context for selecting this tool over siblings, which limits the agent's decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score candidate venues by travel time fairness for multiple participants. Computes travel times from each participant to each venue and ranks by fairness strategy. The AI should suggest venues (from its own knowledge or via search-venues) and pass them here for scoring.
| Name | Required | Description | Default |
|---|---|---|---|
| participants | Yes | Participant locations (2–10 people) | |
| venues | Yes | Candidate venues to score (1–50) | |
| transport_mode | Yes | How participants will travel | |
| fairness | No | Scoring strategy: min_max (default, minimise longest journey), min_total (minimise total travel), min_variance (equalise travel times) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions computing travel times and ranking by fairness strategy, consistent with the readOnlyHint annotation (no mutation). No additional behavioral traits (e.g., unreachable venues handling, caching, or output details) are disclosed beyond the annotations, but annotations already convey non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of three sentences that front-load the main action, explain the computation, and provide usage guidance. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the output format. Given no output schema, it is critical to specify what the tool returns (e.g., ranked list with scores, travel times). This omission hinders the agent's understanding of how to use the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so each parameter's purpose is clear from the schema alone. The description adds minimal extra semantic value beyond reiterating the function; it does not elaborate on fairness strategies or transport mode options beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: scoring candidate venues by travel time fairness for multiple participants. It specifies the action (score), resource (venues), and context (travel time fairness), and distinguishes it from the sibling 'search-venues' by indicating it is used after venues are gathered.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises the AI to suggest venues from its own knowledge or via 'search-venues' before using this tool, providing clear usage context. While it does not explicitly state when not to use or list alternative tools, it implies the appropriate workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for venues (pubs, cafes, restaurants, parks, etc.) near a location using OpenStreetMap data. Returns name, coordinates, type, and OSM ID. Use this when you need comprehensive local venue data that may not be in your training knowledge.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Centre latitude | |
| lon | Yes | Centre longitude | |
| radius_km | No | Search radius in km (default 5) | |
| venue_types | Yes | Venue types to search: pub, cafe, restaurant, park, library, playground, community_centre, bar, fast_food, garden, theatre, arts_centre, fitness_centre, sports_centre, escape_game, swimming_pool, service_station |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds that it uses OSM data and returns specific fields, but does not disclose rate limits, data freshness, or other behavioral traits. With annotations covering safety, the description adds limited behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: first states action and data source, second lists return fields, third gives usage guideline. No redundant information, well-structured and front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 4 parameters and no output schema, the description covers purpose, data source, return fields, and usage guidance. It lacks mention of potential limitations (e.g., OSM data staleness) or explanation of venue_types enum, but the schema fills that gap. Fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so each parameter is documented. The description adds examples ('pubs, cafes, restaurants, parks, etc.') and context like 'near a location', but does not significantly add meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for venues (pubs, cafes, etc.) near a location using OpenStreetMap data, and lists the return fields. This distinguishes it from sibling tools like get-directions or get-isochrone, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a guideline: 'Use this when you need comprehensive local venue data that may not be in your training knowledge.' This implies when to use, though it does not explicitly state when not to use or name alternatives. Given siblings are distinct, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store L402 payment credentials (macaroon + preimage) after paying a routing invoice. Call this after the user has paid the Lightning invoice returned by a payment_required response. Once stored, all subsequent routing calls (score-venues, get-isochrone, get-directions) will authenticate automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| macaroon | Yes | The macaroon from the payment_required response | |
| preimage | Yes | The payment preimage obtained after paying the invoice |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and readOnlyHint=false, consistent with storage. Description adds workflow context (when to call and effect on future calls) beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with key action and context. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple store operation with two well-described parameters, the description provides complete workflow guidance and outcome. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds only minimal context that parameters come from a payment_required response, not enhancing the schema definitions significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Store L402 payment credentials') and the resource ('macaroon + preimage'). It distinguishes from sibling tools by explaining that these credentials enable authentication for routing calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call after the user has paid a Lightning invoice from a payment_required response. Also notes that subsequent routing calls will authenticate automatically. No explicit when-not-to-use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.4get-directionsget-isochronescore-venuessearch-venuesstore-routing-credentialsScored across 5 tools
Each tool targets a distinct aspect of the rendezvous domain: directions, isochrones, venue search, fairness scoring, and credential storage. No two tools overlap in purpose.
All tool names follow a consistent verb-object pattern with hyphens (e.g., get-directions, score-venues). No mixing of conventions.
5 tools cover the core workflow (search, routing, scoring, credential management) without being excessive. Well-scoped for the domain.
Missing minor features like venue detail retrieval or credential deletion, but the essential lifecycle (search venues, compute routes, score fairness, authenticate) is fully supported.
Purpose-aware accessibility scoring for every coordinate in Japan.
Neutral fairness computation for agents: fair division, verifiable random, Shapley shares.
TravelTime MCP — multi-modal isochrones & reachability incl. PUBLIC TRANSPORT
Geocoding, routing, isochrones, traffic, weather, and place search for AI agents. 19 MCP tools.
