Nostr: npub1mgvlrnf5hm9yf0n5mf9nqmvarhvxkc6remu5ec3vf8r0txqkuk7su0e7q2
Puntos de encuentro justos para IA: equidad basada en isócronas, no en puntos medios ingenuos.
Servidor MCP para el descubrimiento de puntos de encuentro impulsado por IA. Dale a tu IA la capacidad de responder "¿dónde deberíamos reunirnos?" utilizando tiempos de viaje reales, disponibilidad de lugares y algoritmos de equidad.
Funciona de inmediato: enrutamiento público gratuito, no se necesitan claves API. Aloja Valhalla tú mismo para consultas ilimitadas, o utiliza créditos Lightning L402 para nuestro endpoint alojado.
Herramienta | Descripción |
| Puntúa lugares candidatos según la equidad en el tiempo de viaje para 2–10 participantes |
| Busca lugares cerca de una ubicación utilizando OpenStreetMap |
| Obtiene un polígono de accesibilidad (todo lo alcanzable en N minutos) |
| Obtiene indicaciones entre dos puntos con instrucciones paso a paso |
| Almacena el macaroon L402 + preimagen después del pago Lightning |
Related MCP server: Magic Lane MCP Server
Añádelo a la configuración de tu cliente MCP (Claude Code, Claude Desktop, Cursor, etc.):
{
"mcpServers": {
"rendezvous": {
"command": "npx",
"args": ["rendezvous-mcp"]
}
}
}Luego pregúntale a tu IA: "¿Cuál es un lugar justo para que Alice en Londres, Bob en Bristol y Carol en Birmingham se reúnan para almorzar?"
Para ChatGPT, agentes de IA remotos o cualquier cliente que se conecte a través de HTTP:
TRANSPORT=http npx rendezvous-mcpInicia un servidor HTTP Streamable en el puerto 3002 con el endpoint MCP en /mcp.
En la configuración de ChatGPT, añade un servidor MCP con:
URL: http://your-host:3002/mcp
Transporte: Streamable HTTP
Variable | Predeterminado | Descripción |
|
| Modo de transporte: |
|
| Puerto del servidor HTTP (solo modo HTTP) |
|
| Dirección de enlace HTTP (solo modo HTTP) |
|
| URL del motor de enrutamiento |
| Endpoints públicos | API de búsqueda de lugares |
Para consultas ilimitadas sin límites de tasa, ejecuta tu propia instancia de Valhalla:
{
"mcpServers": {
"rendezvous": {
"command": "npx",
"args": ["rendezvous-mcp"],
"env": {
"VALHALLA_URL": "http://localhost:8002"
}
}
}
}El usuario pregunta "¿Dónde deberíamos reunirnos?"
La IA geocodifica las ubicaciones de los participantes
La IA llama a search-venues para encontrar lugares candidatos cerca del área
La IA llama a score-venues con los participantes + candidatos — devuelve resultados clasificados con tiempos de viaje y puntuaciones de equidad
La IA presenta la opción más justa con los tiempos de viaje para cada persona
Para un análisis más profundo, la IA puede usar get-isochrone para visualizar la accesibilidad y get-directions para la navegación paso a paso.
El endpoint de enrutamiento predeterminado (routing.trotters.cc) ofrece solicitudes gratuitas. Cuando se agota el nivel gratuito, las herramientas devuelven una respuesta payment_required con una factura Lightning. Después del pago, llama a store-routing-credentials para almacenar el macaroon para la sesión.
Valhalla autohospedado no tiene requisitos de pago.
Un envoltorio MCP ligero sobre rendezvous-kit — la biblioteca TypeScript de código abierto para la intersección de isócronas, búsqueda de lugares y puntuación de equidad. Cada herramienta es una función manejadora extraída (probable sin MCP) más una línea de registro.
npm install
npm run build
npm testPara problemas y solicitudes de funciones, consulta GitHub Issues.
Si encuentras útil rendezvous-mcp, considera enviar una propina:
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.
