Nostr: npub1mgvlrnf5hm9yf0n5mf9nqmvarhvxkc6remu5ec3vf8r0txqkuk7su0e7q2
Faire Treffpunkte für KI — isochronenbasierte Fairness, keine naiven Mittelpunkte.
MCP-Server für KI-gestützte Treffpunkt-Ermittlung. Geben Sie Ihrer KI die Fähigkeit, die Frage „Wo sollen wir uns treffen?“ unter Verwendung echter Reisezeiten, Verfügbarkeiten von Veranstaltungsorten und Fairness-Algorithmen zu beantworten.
Funktioniert sofort — kostenloses öffentliches Routing, keine API-Schlüssel erforderlich. Hosten Sie Valhalla selbst für unbegrenzte Abfragen oder nutzen Sie L402 Lightning-Credits für unseren gehosteten Endpunkt.
Tool | Beschreibung |
| Bewertet potenzielle Veranstaltungsorte nach Reisezeit-Fairness für 2–10 Teilnehmer |
| Sucht nach Veranstaltungsorten in der Nähe eines Standorts mittels OpenStreetMap |
| Erstellt ein Erreichbarkeits-Polygon (alle Orte, die innerhalb von N Minuten erreichbar sind) |
| Ruft Wegbeschreibungen zwischen zwei Punkten mit Abbiegehinweisen ab |
| Speichert L402 Macaroon + Preimage nach Lightning-Zahlung |
Related MCP server: Magic Lane MCP Server
Fügen Sie dies Ihrer MCP-Client-Konfiguration hinzu (Claude Code, Claude Desktop, Cursor, etc.):
{
"mcpServers": {
"rendezvous": {
"command": "npx",
"args": ["rendezvous-mcp"]
}
}
}Fragen Sie dann Ihre KI: „Wo ist ein fairer Ort für Alice in London, Bob in Bristol und Carol in Birmingham, um zu Mittag zu essen?“
Für ChatGPT, Remote-KI-Agenten oder jeden Client, der sich über HTTP verbindet:
TRANSPORT=http npx rendezvous-mcpStartet einen Streamable HTTP-Server auf Port 3002 mit dem MCP-Endpunkt unter /mcp.
Fügen Sie in den ChatGPT-Einstellungen einen MCP-Server hinzu mit:
URL: http://your-host:3002/mcp
Transport: Streamable HTTP
Variable | Standard | Beschreibung |
|
| Transportmodus: |
|
| HTTP-Server-Port (nur im HTTP-Modus) |
|
| HTTP-Bind-Adresse (nur im HTTP-Modus) |
|
| URL der Routing-Engine |
| Öffentliche Endpunkte | API für die Suche nach Veranstaltungsorten |
Für unbegrenzte Abfragen ohne Ratenbegrenzung betreiben Sie Ihre eigene Valhalla-Instanz:
{
"mcpServers": {
"rendezvous": {
"command": "npx",
"args": ["rendezvous-mcp"],
"env": {
"VALHALLA_URL": "http://localhost:8002"
}
}
}
}Der Benutzer fragt: „Wo sollen wir uns treffen?“
Die KI geokodiert die Standorte der Teilnehmer.
Die KI ruft search-venues auf, um potenzielle Veranstaltungsorte in der Nähe des Gebiets zu finden.
Die KI ruft score-venues mit Teilnehmern und Kandidaten auf — gibt bewertete Ergebnisse mit Reisezeiten und Fairness-Scores zurück.
Die KI präsentiert die fairste Option mit Reisezeiten für jede Person.
Für eine tiefere Analyse kann die KI get-isochrone verwenden, um die Erreichbarkeit zu visualisieren, und get-directions für eine schrittweise Navigation.
Der Standard-Routing-Endpunkt (routing.trotters.cc) bietet kostenlose Anfragen. Wenn das kostenlose Kontingent erschöpft ist, geben die Tools eine payment_required-Antwort mit einer Lightning-Rechnung zurück. Rufen Sie nach der Zahlung store-routing-credentials auf, um das Macaroon für die Sitzung zu speichern.
Selbst gehostetes Valhalla erfordert keine Zahlung.
Schlanker MCP-Wrapper über rendezvous-kit — die Open-Source-TypeScript-Bibliothek für Isochronen-Schnittmengen, Veranstaltungsortsuche und Fairness-Bewertung. Jedes Tool ist eine extrahierte Handler-Funktion (testbar ohne MCP) plus ein Registrierungs-Einzeiler.
npm install
npm run build
npm testBei Problemen und Funktionsanfragen siehe GitHub Issues.
Wenn Sie rendezvous-mcp nützlich finden, ziehen Sie ein Trinkgeld in Betracht:
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.
