Nostr: npub1mgvlrnf5hm9yf0n5mf9nqmvarhvxkc6remu5ec3vf8r0txqkuk7su0e7q2
AI를 위한 공정한 만남 장소 — 단순한 중간 지점이 아닌 등시선 기반의 공정성.
AI 기반 만남 장소 탐색을 위한 MCP 서버입니다. 실제 이동 시간, 장소 가용성 및 공정성 알고리즘을 사용하여 AI가 **"어디서 만날까요?"**라는 질문에 답할 수 있도록 합니다.
별도의 설정 없이 바로 사용할 수 있으며, 무료 공개 라우팅을 제공하므로 API 키가 필요하지 않습니다. 무제한 쿼리를 위해 Valhalla를 직접 호스팅하거나, 호스팅된 엔드포인트에 대해 L402 라이트닝 크레딧을 사용할 수 있습니다.
도구 | 설명 |
| 2~10명의 참가자를 위한 이동 시간 공정성 기준으로 후보 장소 점수 매기기 |
| OpenStreetMap을 사용하여 특정 위치 근처의 장소 검색 |
| 도달 가능성 다각형 가져오기 (N분 이내에 도달 가능한 모든 곳) |
| 두 지점 간의 턴바이턴 경로 안내 가져오기 |
| 라이트닝 결제 후 L402 마카룬(macaroon) + 프리이미지 저장 |
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에서 /mcp 엔드포인트로 Streamable HTTP 서버를 시작합니다.
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)는 무료 요청을 제공합니다. 무료 티어가 소진되면 도구는 라이트닝 인보이스와 함께 payment_required 응답을 반환합니다. 결제 후 store-routing-credentials를 호출하여 세션용 마카룬을 저장하세요.
직접 호스팅하는 Valhalla는 결제가 필요하지 않습니다.
rendezvous-kit 위에 구축된 가벼운 MCP 래퍼입니다. 이는 등시선 교차, 장소 검색 및 공정성 점수 계산을 위한 오픈 소스 TypeScript 라이브러리입니다. 각 도구는 추출된 핸들러 함수(MCP 없이 테스트 가능)와 한 줄짜리 등록 코드로 구성됩니다.
npm install
npm run build
npm test문제 및 기능 요청은 GitHub Issues를 확인하세요.
rendezvous-mcp가 유용했다면 팁을 보내주시는 것을 고려해 보세요:
라이트닝: 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.
