Nostr: npub1mgvlrnf5hm9yf0n5mf9nqmvarhvxkc6remu5ec3vf8r0txqkuk7su0e7q2
AIのための公平な待ち合わせ場所 — 単純な中間地点ではなく、等時線に基づいた公平性。
AI主導の待ち合わせ場所発見のためのMCPサーバーです。実際の移動時間、施設の空き状況、公平性アルゴリズムを使用して、AIに**「どこで待ち合わせるべき？」**という質問への回答能力を与えます。
設定不要ですぐに使えます。無料のパブリックルーティングが利用可能で、APIキーは不要です。Valhallaをセルフホストして無制限にクエリを実行するか、ホストされたエンドポイントでL402 Lightningクレジットを使用してください。
ツール | 説明 |
| 2〜10人の参加者に対する移動時間の公平性に基づいて候補地をスコアリングします |
| OpenStreetMapを使用して場所の近くの施設を検索します |
| 到達可能性ポリゴン（N分以内に到達可能なすべての場所）を取得します |
| 2点間のターンバイターン形式の経路案内を取得します |
| Lightning支払い後のL402マカロンとプリイメージを保存します |
Related MCP server: Magic Lane MCP Server
MCPクライアントの設定（Claude Code、Claude Desktop、Cursorなど）に追加してください：
{
"mcpServers": {
"rendezvous": {
"command": "npx",
"args": ["rendezvous-mcp"]
}
}
}次に、AIにこう尋ねてください：「ロンドンのアリス、ブリストルのボブ、バーミンガムのキャロルがランチで待ち合わせるのに公平な場所はどこ？」
ChatGPT、リモートAIエージェント、またはHTTP経由で接続するクライアントの場合：
TRANSPORT=http npx rendezvous-mcpポート3002でStreamable HTTPサーバーを起動し、/mcpにMCPエンドポイントを配置します。
ChatGPTの設定で、以下のようにMCPサーバーを追加します：
URL: http://your-host:3002/mcp
トランスポート: Streamable HTTP
変数 | デフォルト | 説明 |
|
| トランスポートモード: |
|
| HTTPサーバーポート (HTTPモードのみ) |
|
| HTTPバインドアドレス (HTTPモードのみ) |
|
| ルーティングエンジンURL |
| パブリックエンドポイント | 施設検索API |
レート制限なしで無制限にクエリを実行するには、独自のValhallaインスタンスを実行してください：
{
"mcpServers": {
"rendezvous": {
"command": "npx",
"args": ["rendezvous-mcp"],
"env": {
"VALHALLA_URL": "http://localhost:8002"
}
}
}
}ユーザーが「どこで待ち合わせるべき？」と尋ねる
AIが参加者の位置情報をジオコーディングする
AIが search-venues を呼び出し、そのエリア周辺の候補地を検索する
AIが参加者と候補地を指定して score-venues を呼び出し、移動時間と公平性スコアを含むランキング結果を返す
AIが各人の移動時間とともに最も公平な選択肢を提示する
より詳細な分析のために、AIは get-isochrone を使用して到達可能性を可視化したり、 get-directions を使用してターンバイターン形式のナビゲーションを提供したりできます。
デフォルトのルーティングエンドポイント (routing.trotters.cc) はリクエストを無料で提供しています。無料枠を使い切ると、ツールはLightningインボイスを含む payment_required レスポンスを返します。支払い後、 store-routing-credentials を呼び出してセッション用のマカロンを保存してください。
セルフホスト型のValhallaには支払い要件はありません。
rendezvous-kit 上の軽量なMCPラッパーです。これは、等時線の交差、施設検索、公平性スコアリングのためのオープンソースのTypeScriptライブラリです。各ツールは抽出されたハンドラー関数（MCPなしでテスト可能）と、1行の登録コードで構成されています。
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.
