Skip to main content
Glama
enesjakozh
mfukushim

Map Traveler MCP

by mfukushim
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

Virtual Traveling bot environment for MCP

We are currently developing a next-generation traveling bot system. It will take some time to complete, but in the meantime, please enjoy using this MCP server, which operates in MCP v1 mode.

English / Japanese

This is an MCP server that creates an environment for an avatar to virtually travel on Google Maps.

From an MCP client such as Claude Desktop, you can give instructions to the avatar and report on the progress of its journey with photos.

Preparing for MCP Registry Support https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/

Added gemini-2.5-flash-image-preview (nano-banana) to travel image generation

Support for nano-banana has been added. Nano-banana's semantic mask allows you to generate composite travel images in a short time without setting remBg.
Although conventional image synthesis is still possible, we recommend using Gemini nano-banana.

Supports both Streamable-HTTP and stdio (compliant with Smithery.ai's config interface)

It can be used as a stdio-type MCP as before, or as Streamable-HTTP.
Although it supports multiple users, the database API must be specified per session using the Smithery.ai config interface.
Since it supports both Streamable-HTTP and stdio, it is expected to work as is with the previous MCP client, but if you use the previous stdio version, please use v0.0.x (v0.0.81).
npx -y @mfukushim/map-traveler-mcp@0.0.81

Now supports librechat https://www.librechat.ai/.

Now supports Smithery https://smithery.ai/server/@mfukushim/map-traveler-mcp (images are excluded because they are heavy to run).

Now verified MseeP https://mseep.ai/app/mfukushim-map-traveler-mcp

Functions

MCP server tools function

The following functions can be used as an MCP server. The available functions vary depending on the settings and execution state.

You can specify the function name directly, but Claude LLM will automatically recognize it, so you can specify the operation in general terms.

Example: "Where are you now?" "Let's leave for Tokyo Station."

  • get_traveler_view_info(includePhoto:boolean,includeNearbyFacilities:boolean)
    Gets information about the current travel avatar's location.

    • includePhoto: Gets nearby Google Street View photos. If you have set up an image generation AI, it will synthesize the avatar.

    • includeNearbyFacilities: Gets information about nearby facilities.

  • get_traveler_location()
    Gets information about the current travel avatar's address and nearby facilities.

  • reach_a_percentage_of_destination() Reach a specified percentage of the destination (moveMode=skip only) timeElapsedPercentage: Percent progress towards destination(0~100)

  • set_traveler_location(address: string)
    Sets the current travel avatar's location.

    • address: Address information (exact address, or general name that Google Maps or Claude can recognize, etc.)

  • get_traveler_destination_address
    Get the destination of the travel avatar you set

  • set_traveler_destination_address(address: string)
    Set the destination of the travel avatar

    • address: Address information (exact address, or general name that Google Maps or Claude can recognize, etc.)

  • start_traveler_journey
    Start the journey at the destination.(moveMode=realtime only)

  • stop_traveler_journey
    Stop the journey.(moveMode=realtime only)

  • set_traveler_info(settings:string)
    Set the traveler's attributes. Set the traveler's personality that you want to change dynamically, such as name and personality. However, if you use a role script, the script is more stable.

    • settings: Setting information such as name and personality.

  • get_traveler_info
    Get the traveler's attributes. Get the traveler's personality.

  • set_avatar_prompt(prompt:string)
    Set the prompt when generating the travel avatar image. The default is an anime-style woman. The anime style is enforced to prevent fake images.

    • prompt

  • reset_avatar_prompt
    Reset avatar generation prompts to default.

  • get_sns_feeds
    Gets Bluesky SNS articles for the specified custom feed (feeds containing a specific tag).

  • get_sns_mentions
    Gets recent mentions (likes, replies) to Bluesky SNS posts that you made yourself.

  • post_sns_writer(message:string)
    Posts an article to Bluesky SNS with the specified custom feed. Set a specific tag so that it can be determined that the post was generated by the travel bot.

    • message: article

  • reply_sns_writer(message:string,id:string)
    Reply to the article with the specified id. Set a specific tag so that it can be determined that the post was generated by the travel bot.

    • message: reply

    • id: The ID of the post to reply to

  • add_like(id:string)
    Add a like to the specified post.

    • id: The ID of the post to like

  • tips
    Guides you on how to set up features that have not yet been set.

  • get_setting
    Get environment and image settings.

MCP resources

Has five custom prompt samples. When you import a prompt with Claude Desktop, Claude will act as a traveler. The SNS-compatible version controls SNS input and output while having a travel conversation.

  • role.txt
    Claude will act as a traveler.

  • roleWithSns.txt
    Claude will act as a traveler. It also controls reading and posting to SNS.

  • carBattle.txt
    This is a small novel game about a story of transporting secret documents from Yokohama to Tokyo. Scenes are automatically generated. Set moveMode=skip to play.

  • japanMapChallenge.txt,japanMapChallenge2.txt
    Two AIs communicate with each other via SNS and play a challenge game using landscape images.
    To play, you need two Bluesky accounts and two Claude Desktops. Also set moveMode=skip. (However, the operation is somewhat unstable.)
    japanMapChallenge2 has a challenge reflection rule.

Related MCP server: Travel Assistant MCP Server

Setting

You will need to obtain and set access keys for multiple APIs, such as for accessing multiple Google maps and generating images. Use of the API may incur charges.

Settings for using with Claude Desktop

  • claude_desktop_config.json (stdio type)

{
  "mcpServers": {
    "traveler": {
      "command": "npx",
      "args": ["-y", "@mfukushim/map-traveler-mcp"],
      "env":{
        "MT_GOOGLE_MAP_KEY":"(Google Map API key)",
        "MT_GEMINI_IMAGE_KEY": "(Gemini Image Api key)",
        "MT_MAX_RETRY_GEMINI": "(Number of retries when generating Gemini images Default: 0)",
        "MT_AVATAR_IMAGE_URI": "(Character reference image uri (file:// or https://) when generating Gemini image. Multiple settings can be made by separating them with the '|'. When multiple settings are made, they will be selected randomly.)",
        "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_TURSO_URL":"(Turso sqlite API URL)",
        "MT_TURSO_TOKEN":"(Turso sqlite API access token)",
        "MT_REMBG_PATH": "(absolute path of the installed rembg cli)",
        "MT_REMBG_URL": "(rembg API URL)",
        "MT_REMBG_WO_KEY": "(withoutbg.com rembg API key)",
        "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_NO_AVATAR": "(Option: true = Output StreetView image as is without avatar superimposition. Not specified = Superimpose avatar image. 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)",
        "MT_MAX_SESSIONS": "(Maximum number of sessions when using Streamable-http)",
        "MT_SESSION_TTL_MS": "(Session TTL when using Streamable-http)",
        "MT_SERVICE_TTL_MS": "(Service TTL when using Streamable-http)"
      }
    }
  }
}

  • claude_desktop_config.json (streamable-http type)
    The above MT_ environment variables should be set as environment variables for the server that runs the map-traveler-mcp web service.

{
  "mcpServers": {
    "traveler": {
      "type": "streamable-http",
      "url": "https://(mcp server address)/mcp?config=(base64 config json)"
    }
  }
}

base64 config json (Smithery.ai Expansion)
By concatenating the json in the following format into a single line of string, converting it to base64, and setting it as (base64 setting json), you can overwrite different APIs and settings for each user session.
If the database is not set base64 config json, it will be shared across the entire service (the location of the traveler will be shared across the database and counted for one person).
We plan to reconsider the operation of assigning an individual UserId for each session once the MCP authentication mechanism has become a little clearer. 

{
  "MT_GOOGLE_MAP_KEY": "xxxyyyzzz",
  "MT_GEMINI_IMAGE_KEY": "xxyyzz",
  "MT_MAX_RETRY_GEMINI": "1",
  "MT_AVATAR_IMAGE_URI": "file:///C:/Users/xxxx/Desktop/avatar.png",
  "MT_TURSO_URL": "libsql://xxxyyyzzz",
  "MT_TURSO_TOKEN": "abcdabcd",
  "MT_BS_ID": "xyxyxyxyx",
  "MT_BS_PASS": "1234xyz",
  "MT_BS_HANDLE": "aabbccdd",
  "MT_FILTER_TOOLS": "tips,set_traveler_location",
  "MT_MOVE_MODE": "direct",
  "MT_FEED_TAG": "#abcdefgabcdefgabcdefg"
}

(All json values can be omitted)
↓ (json text concatenation) 

{"MT_GOOGLE_MAP_KEY": "xxxyyyzzz", "MT_GEMINI_IMAGE_KEY": "xxyyzz", "MT_MAX_RETRY_GEMINI": "1", "MT_TURSO_URL": "libsql://xxxyyyzzz", "MT_TURSO_TOKEN": "abcdabcd", "MT_BS_ID": "xyxyxyxyx", "MT_BS_PASS": "1234xyz", "MT_BS_HANDLE": "aabbccdd", "MT_FILTER_TOOLS": "tips,set_traveler_location", "MT_MOVE_MODE": "direct", "MT_FEED_TAG": "#abcdefgabcdefgabcdefg"}

↓ (Set the base64 version to config=) 

eyJNVF9HT09HTEVfTUFQX0tFWSI6ICJ4eHh5eXl6enoiLCAiTVRfR0VNSU5JX0lNQUdFX0tFWSI6ICJ4eHl5enoiLCAiTVRfTUFYX1JFVFJZX0dFTUlOSSI6ICIxIiwgIk1UX1RVUlNPX1VSTCI6ICJsaWJzcWw6Ly94eHh5eXl6enoiLCAiTVRfVFVSU09fVE9LRU4iOiAiYWJjZGFiY2QiLCAiTVRfQlNfSUQiOiAieHl4eXh5eHl4IiwgIk1UX0JTX1BBU1MiOiAiMTIzNHh5eiIsICJNVF9CU19IQU5ETEUiOiAiYWFiYmNjZGQiLCAiTVRfRklMVEVSX1RPT0xTIjogInRpcHMsc2V0X3RyYXZlbGVyX2xvY2F0aW9uIiwgIk1UX01PVkVfTU9ERSI6ICJkaXJlY3QiLCAiTVRfRkVFRF9UQUciOiAiI2FiY2RlZmdhYmNkZWZnYWJjZGVmZyJ9

NOTE: The environment variables have been renamed to standard snake case. The MT_ prefix is added because they may be used in conjunction with other environment variables, such as in librechat. The old names can still be used for backward compatibility.

Please set the following three Credentials for Google Map API.

  • Street View Static API

  • Places API (New)

  • Time Zone API

  • Directions API

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

If you want to use the image generation AI, set either pixAi_key or sd_key. You also need to have python3.7~3.11 installed on your PC and rembg cli installed (virtual environment recommended).

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

The bluesky SNS address/password are optional. It is recommended that you create a dedicated account as it will post automatically.

https://bsky.app/

You can also run it in practice mode, which does not require an API key for verification.

Practice mode settings

claude_desktop_config.json

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

How to use

Use the practice mode

  1. Install nodejs 22.

  2. Set up Claude Desktop for use.

  3. Reflect one of the above settings in claude_desktop_config.json.

  4. Restart Claude Desktop. It may take some time to set up (if an error occurs, try restarting Claude Desktop again. If it doesn't work, see the notes below). Make sure the following mark appears in the bottom right of the screen.

  1. Ask "Where are you now?" and "Go on a journey." A conversation will begin. When using the API, a confirmation screen will appear, so select Allow.

  1. Select Attach from MCP and select role.txt.

  1. A travel prompt has been built in, so feel free to talk to it.

Use the full feature

  1. Get a Google Map API access key and set the permissions for Street View Static API, Places API (New), Time Zone API, and Directions API. Set this in the env of claude_desktop_config.json and restart. At this point, the travel log will be based on the real map. Travel images will also be output if they are not superimposed.

  2. Decide on a path that will not interfere with the disk and set it in the sqlite_path of the env of claude_desktop_config.json. (Example: %USERPROFILE%/Desktop/traveler.sqlite $HOME/Documents/traveler.sqlite, etc.) At this point, your travel log will be saved and you can continue your journey even if you close Claude Desktop.

  3. Install python 3.7 to 3.11 and install rembg with cli. We recommend using a virtual environment such as venv.

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

Check if rembg cli works properly using a sample image file. Input an image with a person in it, and if the person is cut out in the output file, it's OK. 

rembg i source_image_file dest_image_file

  1. rembg cli will be installed in the python exe location, so get the path. The file location varies depending on the OS and python installation status, but in the case of venv, it is (virtual environment name)\Scripts\rembg.exe or (virtual environment name)/bin/rembg above the directory you set. If you can't find it, search for the path with a file search software. Set that path to rembg_path of env in claude_desktop_config.json. (Example: "rembg_path": "C:\Users\xxxx\Documents\rembg_venv\venv\Scripts\rembg.exe")

  2. Get an image generation API key from the pixAI or Stability.ai site. Set the key to pixAi_key or sd_key in env of claude_desktop_config.json. The avatar will now be overlaid on the travel image.

  3. Get the bluesky SNS address/password and handle name. Set these in bs_id, bs_pass, and bs_handle in env of claude_desktop_config.json, respectively. Import the travel knowledge prompt roleWithSns.txt to report travel actions to SNS (it will automatically post as a bot, so we recommend allocating a dedicated account)

Instead of preparing rembg with the cli, we have added a setting that allows you to handle rembg as a service API.
If you configure the following rembg service, you can use rembg by setting the URL in remBgUrl.

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

Setup is simple if you use the Docker version to launch a container and access it.

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

Use Turso libsql API for configuration database

If you want to use the cloud API Turso libsql (https://turso.tech/libsql) without having a local sqlite file, sign up for Turso and allocate a sqlite database (paid, free tier available).
This add-in will automatically configure (migrate) the database.
MT_TURSO_URL = turso db URL
MT_TURSO_TOKEN = turso db access token

Use Cloud API for rembg

Local settings around rembg are complicated no matter what method you use, but we have added settings for the paid cloud rembg (https://withoutbg.com/).

Note: There is a small free trial available, but please be aware that this is a commercial API and is quite expensive (about 0.1 euros per image).

MT_REMBG_WO_KEY = withoutbg access token

When using external ComfyUI (for more advanced users)

You can also use a local ComfyUI as an image generation server. You can configure the image generation characteristics yourself in detail to reduce API costs.

However, the configuration will be quite complicated and image generation may take longer.

  1. Configure ComfyUI to run in API mode.

  2. Set the server URL to comfy_url in env.

  3. Set detailed configuration values such as the model to be used in env in the form of a json string. example.

{
  "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. The default workflow can use assets/comfy/t2i_sample.json and assets/comfy/i2i_sample.json in the package. You can specify variables using % and specify the variables in comfy_params.

Using libreChat

It has been adapted to work with libreChat. This makes it easier to use, but some additional settings are required.
Also, it seems that it will not be stable unless the PC you use has a decent level of performance, such as one that can stably run Docker.

Install libreChat

Please make sure it works as described on the official website.
In this case, we recommend using Docker configuration due to additional settings.

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

Configure librechat.yaml using the official procedure.
I think you will need to add a local or API LLM service.

https://www.librechat.ai/docs/configuration/librechat_yaml

Add a user for login.

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

Please set it so that you can have general chat conversations.

Add a rembg container with additional settings

To use rembg with Docker, add pulling and running the rembg Docker container.

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"

Add map-traveler-mcp to the MCP service

Add librechat.yaml

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

Add .env (Same as env in 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.)

After setting, restart the container.
On slow PCs, mcp initialization may fail. Multiple restarts may work, but this may be difficult to run...

llibreChat settings

To use the MCP function in libreChat, use the Agents function.

  1. On the conversation screen, select Agents.

  2. Select Agent Builder from the panel on the right side of the screen and configure your agent.

  3. Select Add Tools to use map-traveler.

  4. The agent tools screen will appear, so select and add all the map-traveler-mcp tools (if the map-traveler-mcp tools are not listed, MCP initialization has failed, so please restart the container or review the settings by checking the logs, etc.)

  5. Enter additional script in the instruction area.
    Since libreChat does not have the MCP resource function, enter the content text of the following URL into the instruction area instead.
    https://github.com/mfukushim/map-traveler-mcp/blob/main/assets/scenario/role.txt

  6. Click the Create button to save the agent.

  7. Start a new chat.

Smithery

Please refer to https://smithery.ai/server/@mfukushim/map-traveler-mcp.
Remote MCP (Streamable-http mode) is supported. Image generation is only available on nano-banana.
Database settings can now be recorded with Turso sqlite, so if you configure Turso, your travel progress will also be saved.

Install guide (Japanese, but lots of photos)

  1. introduction and Practice mode
    https://note.com/marble_walkers/n/n7a8f79e4fb30

  2. DB, Google Map API, Image gen API
    https://note.com/marble_walkers/n/n765257c27f3b

  3. Avatar prompt
    https://note.com/marble_walkers/n/nc7273724faea

  4. SNS integration
    https://note.com/marble_walkers/n/na7c956befe7b

  5. Application 1
    https://note.com/marble_walkers/n/n3c86edd8e817

  6. ComfyUI API
    https://note.com/marble_walkers/n/ncefc7c05d102

  7. Application 2
    https://note.com/marble_walkers/n/ne7584ed231c8

  8. LibreChat setting
    https://note.com/marble_walkers/n/n339bf7905324

  9. AI Agent SNS Battle Map Challenge
    https://note.com/marble_walkers/n/n6db937573eaa

  10. Support Smithery, Turso libSQL, and rembg API
    https://note.com/marble_walkers/n/ne3b3c0f99707

  11. Streamable-HTTP support
    https://note.com/marble_walkers/n/n030063f22dc0

  12. Nano-Banana support
    https://note.com/marble_walkers/n/n5d49514dddec

Additional about the source code

I use Effect.ts to simplify error management & for my own learning.
We also use the Effect Service, but due to the way MCP calls work, we believe that consolidating it using the Service was not optimal.
I think it would be simpler to handle the MCP calls directly in the Effect.
Addendum: I'm aware that I will be able to reconsider how to use the Effect Service and rewrite it neatly, but I'm still considering whether to rewrite it.

Notes on the latest updates

  • Added image_width to env. The default is 512. Setting it smaller may reduce the cost of LLM API.

  • Added an env setting that does not output images for MCP clients that do not have image input/output.
    "MT_NO_IMAGE": "true" will not generate or output any images. Other image-related settings can be omitted.

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

  • You can now specify the tag name to be added when posting to SNS (Bluesky). #Required and must be at least 15 characters. If not specified, it will become "#geo_less_traveler".

  • The information obtained from SNS has been slightly changed. The information posted to SNS has been slightly changed.

  • A script has been added that allows multiple travel bots to converse and play via SNS.

  • Supports remote use from Smithery.
    If you do not want to configure detailed settings, start the app in practice mode. You can also run the app at full speed by configuring each cloud API, but please be aware of charges as it uses many paid APIs such as rembg API. If you do not want to synthesize avatars, you can run the app with the minimum settings of Google Map API and Turso sqlite API.

  • Added the MT_NO_AVATAR option.
    If set, an avatar image will not be composited onto the landscape image. Since there will be no retry processing for avatar composition, the time it takes to obtain a response will be significantly shorter.
    Set this option if image composition is slow or fails unavoidably.

  • Partially applied MCP version 2025-06-18.
    I added title to the schema. I plan to apply outputSchema and structured response in the future, but I haven't implemented them this time. Since the output of Travel Bot is simple text, I don't think structuring is necessary yet.
    https://modelcontextprotocol.io/specification/2025-06-18/server/tools

  • Fixed an issue where some functions, such as SNS functions, could not be called regardless of the env settings due to an initialization error.

  • Added support for Streamable-http. This was done in a hurry, so if you experience any issues, please consider using version 0.0.81 or similar.

  • Support for nano-banana (gemini-2.5-flash-image-preview) image generation has been added. When using nano-banana, no rembg settings are required. The characteristics of the avatar prompt have changed, so image generation may fail with the previous avatar prompt. In this case, you will need to adjust the avatar appearance prompt to one that is acceptable for nano-banana.

  • When generating images for nano-banana, you can now reference the original character image with MT_AVATAR_IMAGE_URI. Please use it in a way that does not infringe on copyrights.

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.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.8/5.0
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

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mfukushim/map-traveler-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server