Skip to main content
Glama
enesjakozh
mfukushim

Map Traveler MCP

by mfukushim
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Entorno de bot de viaje virtual para MCP

Inglés / Japonés

Este es un servidor MCP que crea un entorno para que un avatar viaje virtualmente en Google Maps.

Desde un cliente MCP como Claude Desktop, puedes dar instrucciones al avatar e informar sobre el progreso de su recorrido con fotos.

Ahora es compatible con LibreChat https://www.librechat.ai/ .

Funciones

Función de herramientas del servidor MCP

Las siguientes funciones se pueden utilizar como servidor MCP. Las funciones disponibles varían según la configuración y el estado de ejecución.

Puede especificar el nombre de la función directamente, pero Claude LLM lo reconocerá automáticamente, por lo que puede especificar la operación en términos generales.

Ejemplo: "¿Dónde estás ahora?" "Vámonos a la estación de Tokio".

  • obtener_información_de_vista_del_viajero(incluirFoto:booleano,incluirInstalacionesCercanas:booleano)
    Obtiene información sobre la ubicación del avatar de viaje actual.

    • includePhoto: Obtiene fotos cercanas de Google Street View. Si has configurado una IA para generar imágenes, esta sintetizará el avatar.

    • includeNearbyFacilities: obtiene información sobre las instalaciones cercanas.

  • obtener_ubicación_del_viajero()
    Obtiene información sobre la dirección del avatar de viaje actual y las instalaciones cercanas.

  • reach_a_percentage_of_destination() Alcanzar un porcentaje específico del destino (moveMode=solo omitir) timeElapsedPercentage: Porcentaje de progreso hacia el destino (0~100)

  • set_traveler_location(dirección: cadena)
    Establece la ubicación del avatar de viaje actual.

    • dirección: Información de la dirección (dirección exacta o nombre general que Google Maps o Claude puedan reconocer, etc.)

  • obtener_la_dirección_de_destino_del_viajero
    Obtén el destino del avatar de viaje que configures

  • set_traveler_destination_address(dirección: cadena)
    Establecer el destino del avatar de viaje

    • dirección: Información de la dirección (dirección exacta o nombre general que Google Maps o Claude puedan reconocer, etc.)

  • inicio_viaje_del_viajero
    Comienza el viaje en el destino.(moveMode=solo en tiempo real)

  • detener el viaje del viajero
    Detén el viaje.(moveMode=solo en tiempo real)

  • set_traveler_info(configuración:cadena)
    Establezca los atributos del viajero. Configure la personalidad del viajero que desea cambiar dinámicamente, como el nombre y la personalidad. Sin embargo, si usa un script de rol, este es más estable.

    • Configuración: Configuración de información como nombre y personalidad.

  • obtener información del viajero
    Conoce los atributos del viajero. Conoce su personalidad.

  • set_avatar_prompt(mensaje:cadena)
    Configura el mensaje al generar la imagen del avatar de viaje. El valor predeterminado es una mujer de estilo anime. Este estilo se aplica para evitar imágenes falsas.

    • inmediato

  • mensaje de reinicio de avatar
    Restablecer las indicaciones de generación de avatar a los valores predeterminados.

  • obtener feeds de SNS
    Obtiene artículos de Bluesky SNS para la fuente personalizada especificada (fuentes que contienen una etiqueta específica).

  • obtener_menciones_sns
    Obtiene menciones recientes (me gusta, respuestas) a las publicaciones de Bluesky SNS que usted mismo realizó.

  • post_sns_writer(mensaje:cadena)
    Publica un artículo en la red social Bluesky con el feed personalizado especificado. Establece una etiqueta específica para determinar que la publicación fue generada por el bot de viajes.

    • mensaje: artículo

  • reply_sns_writer(mensaje:cadena,id:cadena)
    Responda al artículo con el ID especificado. Establezca una etiqueta específica para determinar que la publicación fue generada por el bot de viajes.

    • mensaje: responder

    • id: El ID de la publicación a la que responder

  • add_like(id:cadena)
    Añade un me gusta a la publicación especificada.

    • id: El ID de la publicación a la que le darás me gusta

  • consejos
    Le guía sobre cómo configurar funciones que aún no se han configurado.

  • obtener_configuración
    Obtener la configuración del entorno y de la imagen.

Recursos de MCP

Incluye cinco ejemplos de mensajes personalizados. Al importar un mensaje con Claude Desktop, Claude actuará como un viajero. La versión compatible con redes sociales controla la entrada y salida de mensajes mientras se mantiene una conversación de viaje.

  • rol.txt
    Claude actuará como viajero.

  • rolConSns.txt
    Claude actuará como viajero. También controla la lectura y publicación en redes sociales.

  • carBattle.txt
    Este es un pequeño juego novedoso sobre la historia del transporte de documentos secretos de Yokohama a Tokio. Las escenas se generan automáticamente. Configura moveMode=skip para jugar.

  • japanMapChallenge.txt,japanMapChallenge2.txt
    Dos IA se comunican entre sí a través de redes sociales y juegan un juego de desafío utilizando imágenes de paisajes.
    Para jugar, necesitas dos cuentas de Bluesky y dos escritorios Claude. También configura moveMode=skip. (Sin embargo, el funcionamiento es algo inestable).
    japanMapChallenge2 tiene una regla de reflexión de desafío.

Related MCP server: Travel Assistant MCP Server

Configuración

Necesitará obtener y configurar claves de acceso para varias API, como acceder a varios mapas de Google y generar imágenes. El uso de la API puede conllevar cargos.

Configuración para usar con Claude Desktop

claude_desktop_config.json

{
  "mcpServers": {
    "traveler": {
      "command": "npx",
      "args": ["-y", "@mfukushim/map-traveler-mcp"],
      "env":{
        "MT_GOOGLE_MAP_KEY":"(Google Map API key)",
        "MT_MAP_API_URL": "(Optional: Map API custom endpoint. Example: direction=https://xxxx,places=https://yyyy )",
        "MT_TIME_SCALE": "(Optional:Scale of travel time on real roads duration. default 4)",
        "MT_SQLITE_PATH":"(db save path: e.g. %USERPROFILE%/Desktop/traveler.sqlite ,$HOME/traveler.sqlite )",
        "MT_REMBG_PATH": "(absolute path of the installed rembg cli)",
        "MT_REMBG_URL": "(rembg API URL)",
        "MT_PIXAI_KEY":"(pixAi API key)",
        "MT_SD_KEY":"(or Stability.ai image generation API key",
        "MT_PIXAI_MODEL_ID": "(Optional: pixAi ModelId, if not set use default model 1648918127446573124 ",
        "MT_COMFY_URL": "(Option: Generate image using ComfyUI API at specified URL. Example: http://192.168.1.100:8188)",
        "MT_COMFY_WORKFLOW_T2I": "(Optional: Path to API workflow file when using text to image with ComfyUI. If not specified: assets/comfy/t2i_sample.json)",
        "MT_COMFY_WORKFLOW_I2I": "(Optional: Path of API workflow file when image to image in ComfyUI. If not specified: assets/comfy/i2i_sample.json)",
        "MT_COMFY_PARAMS": "(Optional: Variable values to send to the workflow via comfyUI API)",
        "MT_FIXED_MODEL_PROMPT": "(Optional: Fixed avatar generation prompt. You will no longer be able to change your avatar during conversations.)",
        "MT_BODY_AREA_RATIO": "(Optional: Acceptable avatar image area ratio. default 0.042)",
        "MT_BODY_HW_RATIO": "(Optional: Acceptable avatar image aspect ratios. default 1.5~2.3)",
        "MT_BODY_WINDOW_RATIO_W": "(Optional: Avatar composite window horizontal ratio. default 0.5)",
        "MT_BODY_WINDOW_RATIO_H": "(Optional: Avatar composite window aspect ratio. default 0.75)",
        "MT_BS_ID":"(Bluesky sns registration address)",
        "MT_BS_PASS":"(bluesky sns password)",
        "MT_BS_HANDLE":"(bluesky sns handle name: e.g. xxxxxxxx.bsky.social )",
        "MT_FILTER_TOOLS": "(Optional: Directly filter the tools to be used. All are available if not specified. e.g. tips,set_traveler_location)",
        "MT_MOVE_MODE": "(Option: Specify whether the movement mode is realtime or skip. default realtime)",
        "MT_IMAGE_WIDTH": "(Option: Output image width (pixels) Default is 512)",
        "MT_NO_IMAGE": "(Options: true = do not output image, not specified = output image if possible, default is not specified)",
        "MT_FEED_TAG": "(Optional: Specify the feed tag when posting to SNS (#required, 15 characters or more) Default is #geo_less_traveler)"
      }
    }
  }
}

NOTA: Las variables de entorno se han renombrado con el formato estándar de Snake. Se añade el prefijo MT_ porque pueden usarse junto con otras variables de entorno, como en LibreChat. Los nombres antiguos se pueden seguir usando por compatibilidad con versiones anteriores.

Configure las siguientes tres credenciales para la API de Google Maps.

  • API estática de Street View

  • API de lugares (Nueva)

  • API de zona horaria

  • API de direcciones

https://developers.google.com/maps/documentation/streetview/get-api-key

Si desea usar la IA de generación de imágenes, configure pixAi_key o sd_key. También necesita tener instalado Python 3.7-3.11 en su PC y la CLI de rembg (se recomienda un entorno virtual).

https://platform.pixai.art/docs\ https://platform.stability.ai/docs/api-reference#tag/SDXL-1.0-and-SD1.6/operation/textToImage

La dirección y contraseña de Bluesky SNS son opcionales. Se recomienda crear una cuenta dedicada, ya que se publicará automáticamente.

https://bsky.app/

También puede ejecutarlo en modo de práctica, que no requiere una clave API para la verificación.

Configuración del modo de práctica

claude_desktop_config.json

{
  "mcpServers": {
    "traveler": {
      "command": "npx",
      "args": ["-y", "@mfukushim/map-traveler-mcp"]
    }
  }
}

Cómo utilizar

Utilice el modo de práctica

  1. Instalar nodejs 22.

  2. Configurar Claude Desktop para su uso.

  3. Refleje una de las configuraciones anteriores en claude_desktop_config.json.

  4. Reinicie Claude Desktop. La configuración puede tardar un poco (si se produce un error, intente reiniciar Claude Desktop de nuevo. Si no funciona, consulte las notas a continuación). Asegúrese de que aparezca la siguiente marca en la esquina inferior derecha de la pantalla.

  5. Pregunta "¿Dónde estás ahora?" y "Embárcate en un viaje". Se iniciará una conversación. Al usar la API, aparecerá una pantalla de confirmación; selecciona "Permitir".

  6. Seleccione Adjuntar desde MCP y seleccione role.txt.

  7. Se ha incorporado un aviso de viaje, así que no dudes en hablar con él.

Utilice la función completa

  1. Obtén una clave de acceso a la API de Google Maps y configura los permisos para la API estática de Street View, la API de Places (Nueva), la API de zona horaria y la API de indicaciones. Configúrala en el entorno de claude_desktop_config.json y reinicia. En este punto, el registro de viaje se basará en el mapa real. También se mostrarán imágenes de viaje si no están superpuestas.

  2. Elija una ruta que no interfiera con el disco y configúrela en sqlite_path del entorno de claude_desktop_config.json. (Ejemplo: %USERPROFILE%/Desktop/traveler.sqlite $HOME/Documents/traveler.sqlite, etc.) En este punto, se guardará su registro de viaje y podrá continuar su viaje incluso si cierra Claude Desktop.

  3. Instale Python 3.7 a 3.11 e instale rembg con CLI. Recomendamos usar un entorno virtual como venv.

python3 -m venv venv
. venv/bin/activate or .\venv\Scripts\activate
pip install "rembg[cpu,cli]"

Comprueba si rembg CLI funciona correctamente con un archivo de imagen de muestra. Introduce una imagen con una persona y, si esta aparece recortada en el archivo de salida, no hay problema.

rembg i source_image_file dest_image_file

  1. La CLI de rembg se instalará en la ubicación del archivo exe de Python, así que obtenga la ruta. La ubicación del archivo varía según el sistema operativo y el estado de instalación de Python, pero en el caso de venv, es (nombre del entorno virtual)\Scripts\rembg.exe o (nombre del entorno virtual)/bin/rembg, encima del directorio que haya configurado. Si no la encuentra, busque la ruta con un buscador de archivos. Establezca esa ruta como rembg_path del entorno en claude_desktop_config.json. (Ejemplo: "rembg_path": "C:\Users\xxxx\Documents\rembg_venv\venv\Scripts\rembg.exe")

  2. Obtén una clave API para generar imágenes desde el sitio web de pixAI o Stability.ai. Establece la clave en pixAi_key o sd_key en el entorno de claude_desktop_config.json. El avatar se superpondrá a la imagen del viaje.

  3. Obtén la dirección/contraseña y el nombre del usuario de Bluesky SNS. Establécelos en bs_id, bs_pass y bs_handle en el entorno de claude_desktop_config.json, respectivamente. Importa el aviso de información de viajes roleWithSns.txt para informar sobre las acciones de viaje a SNS (se publicará automáticamente como un bot, por lo que recomendamos asignar una cuenta dedicada).

En lugar de preparar rembg con la CLI, hemos agregado una configuración que le permite manejar rembg como una API de servicio.
Si configura el siguiente servicio rembg, puede usar rembg configurando la URL en remBgUrl.

https://github.com/danielgatis/rembg?tab=readme-ov-file#rembg-s

La configuración es sencilla si usa la versión Docker para iniciar un contenedor y acceder a él.

https://github.com/danielgatis/rembg?tab=readme-ov-file#usage-as-a-docker

Al utilizar ComfyUI externo (para usuarios más avanzados)

También puede usar un ComfyUI local como servidor de generación de imágenes. Puede configurar usted mismo las características de generación de imágenes detalladamente para reducir los costos de la API.

Sin embargo, la configuración será bastante complicada y la generación de imágenes puede tardar más tiempo.

  1. Configure ComfyUI para que se ejecute en modo API.

  2. Establezca la URL del servidor en comfy_url en env.

  3. Establezca valores de configuración detallados, como el modelo que se utilizará en env, en forma de una cadena json, ejemplo.

{
  "env": {
    "comfy_url": "http://192.168.1.100:8188",
    "comfy_workflow_t2i": "C:\\Documents\\t2itest.json",
    "comfy_workflow_i2i":"C:\\Documents\\i2itest.json",
    "comfy_params":"ckpt_name='animagineXL40_v40.safetensors',denoise=0.65"
  }
}

  1. El flujo de trabajo predeterminado puede usar assets/comfy/t2i_sample.json y assets/comfy/i2i_sample.json en el paquete. Puede especificar variables usando % y especificarlas en comfy_params.

Usando libreChat

Se ha adaptado para funcionar con libreChat. Esto facilita su uso, pero requiere algunas configuraciones adicionales.
Además, parece que no será estable a menos que la PC que uses tenga un nivel de rendimiento decente, como una que pueda ejecutar Docker de manera estable.

Instalar libreChat

Asegúrese de que funcione como se describe en el sitio web oficial.
En este caso, recomendamos utilizar la configuración de Docker debido a configuraciones adicionales.

https://www.librechat.ai/docs/local/docker

Configure librechat.yaml utilizando el procedimiento oficial.
Creo que necesitarás agregar un servicio LLM local o API.

https://www.librechat.ai/docs/configuration/librechat\_yaml

Añadir un usuario para iniciar sesión.

https://www.librechat.ai/docs/configuration/authentication#create-user-script

Configúrelo para que pueda tener conversaciones de chat generales.

Agregue un contenedor rembg con configuraciones adicionales

Para usar rembg con Docker, agregue la extracción y ejecución del contenedor Docker rembg.

docker-compose.override.yml

 services:
   api:
     volumes:
       - type: bind
         source: ./librechat.yaml
         target: /app/librechat.yaml

   rembg:
     image: danielgatis/rembg:latest
     restart: always
     command: "s --host 0.0.0.0 --port 7000 --log_level info"

Agregar map-traveler-mcp al servicio MCP

Agregar librechat.yaml

mcpServers:
  traveler:
    type: stdio
    command: npx
    args:
      - -y
      - "@mfukushim/map-traveler-mcp"

Agregar .env (igual que env en claude_desktop_config.json)

# map-traveler-mcp
GoogleMapApi_key=(Google Map API key)
sqlite_path=/home/run_test.sqlite (e.g. librechat in an unobtrusive location inside the container, or in an external directory that you don't want to mount.)
remBgUrl=http://rembg:7000 (rembg Service API URL, container URL)
(Other settings such as image generation AI settings, PixAI key, stability.ai API key, ComfyUI settings, etc.)

Después de la configuración, reinicie el contenedor.
En PC lentas, la inicialización de mcp puede fallar. Reiniciar varias veces puede funcionar, pero puede ser difícil.

Configuración de llibreChat

Para utilizar la función MCP en libreChat, utilice la función Agentes.

  1. En la pantalla de conversación, seleccione Agentes.

  2. Seleccione Agent Builder en el panel del lado derecho de la pantalla y configure su agente.

  3. Seleccione Agregar herramientas para utilizar map-traveler.

  4. Aparecerá la pantalla de herramientas del agente, así que seleccione y agregue todas las herramientas map-traveler-mcp (si las herramientas map-traveler-mcp no están en la lista, la inicialización de MCP ha fallado, así que reinicie el contenedor o revise la configuración verificando los registros, etc.)\ \

  5. Introduzca un script adicional en el área de instrucciones.
    Dado que libreChat no tiene la función de recurso MCP, ingrese el texto del contenido de la siguiente URL en el área de instrucciones.
    https://github.com/mfukushim/map-traveler-mcp/blob/main/assets/scenario/role.txt\

  6. Haga clic en el botón Crear para guardar el agente.

  7. Iniciar un nuevo chat.

Guía de instalación (en japonés, pero con muchas fotos)

  1. Introducción y modo de práctica
    https://note.com/marble\_walkers/n/n7a8f79e4fb30

  2. Base de datos, API de Google Maps, API de generación de imágenes
    https://note.com/marble\_walkers/n/n765257c27f3b

  3. Aviso de avatar
    https://note.com/marble\_walkers/n/nc7273724faea

  4. Integración de redes sociales
    https://note.com/marble\_walkers/n/na7c956befe7b

  5. Solicitud 1
    https://note.com/marble\_walkers/n/n3c86edd8e817

  6. API de ComfyUI
    https://note.com/marble\_walkers/n/ncefc7c05d102

  7. Solicitud 2
    https://note.com/marble\_walkers/n/ne7584ed231c8

  8. Configuración de LibreChat
    https://note.com/marble\_walkers/n/n339bf7905324

Más información sobre el código fuente

Utilizo Effect.ts para simplificar la gestión de errores y para mi propio aprendizaje.
También utilizamos el Servicio de efectos, pero debido a la forma en que funcionan las llamadas MCP, creemos que consolidarlo usando el Servicio no fue óptimo.
Creo que sería más sencillo manejar las llamadas MCP directamente en el Efecto.

Notas sobre las últimas actualizaciones

Se agregó el ancho de imagen al entorno. El valor predeterminado es 512. Un valor menor puede reducir el costo de la API LLM.
Se agregó una configuración de entorno que no genera imágenes para clientes MCP que no tienen entrada/salida de imágenes.
"MT_NO_IMAGE": "true" no generará ni mostrará ninguna imagen. Se pueden omitir otras configuraciones relacionadas con las imágenes.

{
  
  "env": {
    "MT_NO_IMAGE": "true"
  }
  
}
or
{
  
  "env": {
    "GoogleMapApi_key": "xxxx",
    "MT_NO_IMAGE": "true"
  }
  
}

Ahora puedes especificar el nombre de la etiqueta que se añadirá al publicar en redes sociales (Bluesky). #Obligatorio y debe tener al menos 15 caracteres. Si no se especifica, se convertirá en "#geo_less_traveler".
La información obtenida de las redes sociales ha sufrido algunos cambios. La información publicada en las redes sociales ha sufrido algunos cambios.
Se ha agregado un script que permite que varios bots de viaje conversen y jueguen a través de SNS.

Available Tools

8 tools
get_settingGet the current settingDInspect

Get current setting

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

D1.9/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it offers no information about traits such as whether this is a read-only operation, if it requires authentication, potential rate limits, or what the return format might be. This is inadequate for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise ('Get current setting'), which could be seen as efficient. However, it's under-specified rather than appropriately sized, failing to provide necessary context. It's front-loaded but lacks substance, making it borderline between conciseness and insufficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'setting' refers to, what data is returned, or how this tool fits into the context of sibling tools (e.g., traveler-related operations). For a tool with no structured data support, the description fails to provide essential context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it doesn't introduce any confusion. A baseline score of 4 is appropriate as the schema fully handles the parameter aspect.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get current setting' is a tautology that merely restates the tool name and title without adding specificity. It doesn't clarify what type of setting (e.g., system, user, application) or which resource it retrieves, nor does it distinguish this tool from its siblings like 'get_traveler_info' or 'get_traveler_location'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, leaving the agent with no information to decide between this tool and sibling tools like 'get_traveler_info' or 'set_traveler_info'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_traveler_infoGet the traveler's preferences (optional).CInspect

get a traveler's setting.For example, traveler's name, the language traveler speak, Personality and speaking habits, etc.

ParametersJSON Schema
NameRequiredDescriptionDefault
settingsNo

TDQS

C2.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden but only mentions what data is retrieved without disclosing behavioral traits like permissions needed, rate limits, or response format. It lacks details on whether this is a read-only operation or has other constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded, using a single sentence with examples to convey the purpose efficiently. However, it could be more structured by explicitly stating the tool's scope or limitations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 1 undocumented parameter, no annotations, and no output schema, the description is incomplete. It provides basic purpose but lacks details on parameters, behavior, and output, making it inadequate for effective tool use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 1 parameter with 0% description coverage, and the tool description does not explain the 'settings' parameter at all. It fails to add any meaning beyond the schema, leaving the parameter undocumented and unclear in usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool retrieves a traveler's settings with examples (name, language, personality), which clarifies the purpose beyond the name. However, it doesn't differentiate from sibling tools like 'get_setting' or 'get_traveler_view_info', making it somewhat vague in comparison.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as 'get_setting' or 'get_traveler_view_info'. The description only lists examples of what it retrieves, offering no context for selection among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_traveler_locationGet the traveler's current locationBInspect

Get the address of the current traveler's location

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't reveal any behavioral traits such as permissions needed, rate limits, whether the location is real-time or cached, or what happens if no traveler exists. This is inadequate for a tool that likely involves sensitive location data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It's front-loaded and wastes no words, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of location data (potentially sensitive) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., address format, coordinates), error conditions, or behavioral context, leaving significant gaps for the agent to operate effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it could briefly note the lack of inputs for clarity. A baseline of 4 is given as it meets the requirement for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and resource ('address of the current traveler's location'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_traveler_info' or 'get_traveler_view_info', which might also provide location-related information, so it doesn't achieve full sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'get_traveler_info' or 'get_traveler_view_info'. It lacks context about prerequisites, timing, or exclusions, leaving the agent to infer usage from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_traveler_view_infoGet the current location's viewCInspect

Get the address of the current traveler's location and information on nearby facilities,view snapshot

ParametersJSON Schema
NameRequiredDescriptionDefault
includeNearbyFacilitiesNoGet information on nearby facilities
includePhotoNoGet scenery photos of current location

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what information is retrieved but lacks details on permissions, rate limits, data freshness, or error handling. For a tool that accesses location and facility data, this is a significant gap in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded, stating the core purpose in a single sentence. However, the phrase 'view snapshot' is ambiguous and could be clarified, slightly reducing efficiency. Overall, it's appropriately sized with minimal waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (retrieving location and facility data), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavioral aspects and output format, which are important for effective use by an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with clear descriptions for both parameters ('includeNearbyFacilities' and 'includePhoto'). The description mentions 'information on nearby facilities' and 'view snapshot', which align with the parameters but don't add significant meaning beyond what the schema provides. Baseline 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get the address of the current traveler's location and information on nearby facilities, view snapshot'. This specifies the verb ('Get') and resources (address, nearby facilities, view snapshot). However, it doesn't explicitly distinguish this tool from sibling tools like 'get_traveler_location' or 'get_traveler_info', which appear related to traveler data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or clarify the context for selecting this specific tool over others like 'get_traveler_location' or 'get_traveler_info', leaving usage ambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_traveler_infoSet the traveler's preferences (optional).CInspect

set a traveler's setting.For example, traveler's name, the language traveler speak, Personality and speaking habits, etc.

ParametersJSON Schema
NameRequiredDescriptionDefault
settingsYestraveler's setting. traveler's name, the language traveler speak, etc.

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a mutation operation ('set'), but doesn't specify whether this requires permissions, if changes are reversible, what happens to existing settings, or any rate limits. The description adds minimal context beyond the basic action, failing to address key behavioral traits for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the core action ('set a traveler's setting'), followed by illustrative examples. It avoids unnecessary elaboration, though the use of 'etc.' and minor grammatical issues ('traveler's name, the language traveler speak') slightly reduce clarity. Overall, it's efficient with minimal waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's mutation nature, lack of annotations, and no output schema, the description is insufficiently complete. It doesn't cover behavioral aspects like permissions, reversibility, or response format, and while the parameter is documented in the schema, the description doesn't compensate for the missing context needed for safe and effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with the parameter 'settings' documented as 'traveler's setting. traveler's name, the language traveler speak, etc.' The description adds examples ('traveler's name, the language traveler speak, Personality and speaking habits, etc.') that align with the schema but don't provide additional syntax, format, or constraints beyond what's already in the schema. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool's purpose ('set a traveler's setting') and provides examples ('traveler's name, the language traveler speak, Personality and speaking habits'), which clarifies the resource and scope. However, it doesn't explicitly differentiate from siblings like 'get_traveler_info' or 'get_setting', and the phrasing is somewhat vague with 'etc.' leaving some ambiguity about the full range of settings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers no guidance on when to use this tool versus alternatives, such as how it differs from sibling tools like 'get_traveler_info' or 'get_setting'. It lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage based on the tool name and examples alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

start_traveler_journeyStart the journeyCInspect

Start the traveler's journey to destination

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It states the action ('Start') but doesn't disclose behavioral traits such as whether this is a mutation, what permissions are needed, if it's idempotent, or what happens if a journey is already in progress. This leaves significant gaps for a tool that likely changes state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence that directly states the tool's action. It's appropriately sized for a simple tool with no parameters, though it could be slightly more informative without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'destination' means, how it's determined, what the expected outcome is, or any error conditions. For a tool that likely initiates a state change, more context is needed to guide effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description doesn't add parameter details, which is acceptable here since there are none to explain, aligning with the baseline for zero parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action ('Start') and resource ('traveler's journey to destination'), making the purpose understandable. However, it doesn't differentiate from the sibling tool 'stop_traveler_journey' beyond the verb, and 'destination' is vague without specifying what it refers to or how it's determined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'stop_traveler_journey' or other sibling tools. The description implies it's for initiating travel, but it doesn't specify prerequisites, conditions, or exclusions for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

stop_traveler_journeyStop the journeyCInspect

Stop the traveler's journey

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.2/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Stop the traveler's journey' implies a mutation or state change, but the description doesn't specify whether this action is reversible, what permissions are required, what side effects occur (e.g., does it cancel ongoing processes?), or what the response looks like. This is inadequate for a tool that likely alters system state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no wasted words, which is efficient. However, it's under-specified rather than appropriately sized—it lacks necessary context for a mutation tool, so its brevity doesn't earn full credit for being 'front-loaded' with helpful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool likely performs a mutation (stopping a journey) with no annotations and no output schema, the description is incomplete. It doesn't explain what 'stopping' entails, what happens post-execution, or any error conditions, leaving significant gaps for an agent to understand the tool's behavior and outcomes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter details, and it correctly implies no parameters are required by not mentioning any. This meets the baseline for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Stop the traveler's journey' is a tautology that merely restates the tool name 'stop_traveler_journey' and title 'Stop the journey' without adding specificity. It doesn't clarify what 'journey' means in this context or what resources are affected, though it does include the verb 'stop' and resource 'traveler's journey' which provides minimal differentiation from siblings like 'start_traveler_journey'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that a journey must be active), exclusions, or comparisons to sibling tools like 'start_traveler_journey', leaving the agent with no contextual usage information beyond the tool's name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tipsTips for using this MCP serverCInspect

Inform you of recommended actions for your device

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Inform you' but doesn't clarify whether this is a read-only operation, if it requires permissions, how recommendations are generated, or what the output format might be. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and safety profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose ('Inform you of recommended actions'), making it easy to parse. However, it could be slightly more specific to improve clarity without sacrificing brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (simple informational tool with no parameters) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'recommended actions' entail, how they're determined, or what the return value looks like. For a tool that might provide actionable advice, more context is needed to guide the agent effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics beyond what the schema provides. A baseline score of 4 is appropriate as the description doesn't contradict the empty schema and the lack of parameters is handled adequately by the structured data.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool's purpose as informing about recommended actions for a device, which is clear but vague. It uses a specific verb ('Inform') and resource ('recommended actions for your device'), but doesn't distinguish this from sibling tools like 'get_setting' or 'get_traveler_info' that might also provide device-related information. The purpose is understandable but lacks specificity about what types of recommendations or actions are involved.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_setting' or 'get_traveler_info' that might retrieve device information, there's no indication of when 'tips' is appropriate—e.g., for proactive advice versus status queries. Usage is implied as informational but without explicit context or exclusions, leaving the agent to guess based on the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 8 tool updatesv1.0.0
    • First observedget_setting
    • First observedget_traveler_info
    • First observedget_traveler_location
    • First observedget_traveler_view_info
    • First observedset_traveler_info
    • First observedstart_traveler_journey
    • First observedstop_traveler_journey
    • First observedtips
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.8/5.0

Scored across 8 tools

Disambiguation3/5

Most tools have distinct purposes, but there is some overlap between get_traveler_info and get_setting, and get_traveler_location and get_traveler_view_info share similar location-related functions. The descriptions help clarify differences, but an agent might occasionally misselect between these pairs.

Naming Consistency4/5

The naming follows a consistent verb_noun pattern with snake_case throughout, such as get_traveler_info and set_traveler_info. The only minor deviation is 'tips', which is a noun rather than a verb_noun pattern, but it fits the overall style and does not break consistency severely.

Tool Count5/5

With 8 tools, the count is well-scoped for a travel or mapping server. Each tool appears to serve a specific function in managing traveler settings, location, and journey control, making the set neither too sparse nor overloaded.

Completeness3/5

The tool set covers core operations like getting/setting traveler info, location, and journey control, but there are notable gaps. For example, there is no tool for updating journey details mid-travel or handling multiple travelers, which could limit agent workflows in a travel domain.

Maintenance

ActivityStale
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches