Skip to main content
Glama
gcszkjpzzv-beep

TravelMind MCP Server

by gcszkjpzzv-beep
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

TravelMind MCP Server

TravelMind (差旅 + 报销 + AI Agent 一体化) 的官方 MCP (Model Context Protocol) server。

让任意 MCP 兼容客户端(Claude Desktop / Cursor / WorkBuddy / 等)直接调用中国境内的差旅核心能力:地理编码、POI 搜索、周边搜索和反向地理编码。

Features

4 个核心 Tools,全部由高德开放 API 提供实时数据:

Tool

Description

API

geocode

地址 → 经纬度 (城市/地址解析)

/v3/geocode/geo

regeocode

经纬度 → 行政区 + POI (逆地理编码)

/v3/geocode/regeo

text_search

关键词搜 POI (酒店/餐厅/景点)

/v3/place/text

around_search

周边搜 POI (坐标 + radius)

/v3/place/around

Related MCP server: AMap Maps MCP Server

Quick Start

Prerequisites

Install

git clone https://github.com/gcszkjpzzv-beep/TravelMind_MCP.git
cd TravelMind_MCP
npm install

Configure

export AMAP_API_KEY="your-amap-api-key"

Run

node index.js

Use in Claude Desktop / Cursor

{
  "mcpServers": {
    "travelmind": {
      "command": "node",
      "args": ["/path/to/TravelMind_MCP/index.js"],
      "env": { "AMAP_API_KEY": "your-key" }
    }
  }
}

Tools Reference

geocode

{
  "address": "北京市朝阳区望京 SOHO",
  "city": "北京"
}

Returns { location: "lng,lat", formatted_address, ... }.

regeocode

{ "location": "116.481,39.990" }

Returns { formatted_address, addressComponent: { province, city, district, ... } }.

text_search

{
  "keywords": "希尔顿酒店",
  "city": "北京",
  "types": "住宿"
}

Returns { pois: [{ id, name, address, location, ... }] }.

around_search

{
  "keywords": "餐厅",
  "location": "116.481,39.990",
  "radius": "1000"
}

Returns { pois: [...] } within radius.

About TravelMind

License

MIT

Available Tools

4 tools
geocodeAInspect

将结构化地址解析为经纬度坐标,例如 '北京市朝阳区望京 SOHO' → location 'lng,lat'。

ParametersJSON Schema
NameRequiredDescriptionDefault
cityNo可选,指定查询城市以提高准确度,例如 '北京'
addressYes待解析的结构化地址,例如 '北京市朝阳区望京 SOHO'

TDQS

A3.8/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. It discloses core behavior (parsing address to lng,lat coordinate string) and output format via example. However, it does not address edge cases (e.g., unresolved address, multiple matches) or any limitations.

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?

Single sentence with an example, no redundant words. Information is front-loaded and efficiently communicated.

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

Completeness4/5

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

For a simple geocoding tool with no output schema, the description adequately explains input and output. It lacks details on error handling or result format variations, but the example compensates partially. Given no annotations, it is reasonably complete.

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?

Schema coverage is 100% with descriptions for both parameters. The tool description adds no additional parameter meaning beyond what the schema already provides (e.g., city is optional, address is structured). Baseline 3 is appropriate.

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

Purpose5/5

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

Description clearly states the verb ('解析', parse/resolve) and resource ('结构化地址' to '经纬度坐标'), with a concrete example. It distinguishes from sibling tools: 'regeocode' (reverse), 'text_search', 'around_search' by being specifically address-to-coordinates.

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

Usage Guidelines3/5

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

Description implies usage context (structured address to coordinates) but does not explicitly state when to use this vs. alternatives like 'regeocode' or 'text_search'. No exclusions or comparison given.

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

regeocodeAInspect

将经纬度坐标转换为行政区划地址(街道级精度)。例如 '116.481,39.990' → '北京市朝阳区望京街道...'

ParametersJSON Schema
NameRequiredDescriptionDefault
radiusNo可选,搜索半径(米),默认 1000
locationYes经纬度坐标,格式 'lng,lat' 例如 '116.481,39.990'

TDQS

A3.6/5.0
Behavior2/5

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

No annotations are provided, so description must bear full burden. It only states the conversion and precision level, but omits important behavioral traits like coverage area, error handling, rate limits, or response format. Minimal disclosure.

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?

Very concise: one sentence plus example. No fluff, but could be better structured with bullet points for readability. Still efficient.

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 no output schema, description should hint at return value (e.g., address components). It doesn't. Schema covers params well, but overall completeness is adequate but not thorough.

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?

Schema coverage is 100%, so baseline accuracy. Description reinforces the location format with an example but adds no new meaning beyond the schema's descriptions. Radius is explained in schema; description doesn't enhance it.

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

Purpose5/5

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

Description clearly states the tool converts coordinates to administrative address with street-level precision, and provides a concrete example. It distinguishes from sibling tools (geocode, text_search, around_search) by its reverse-geocoding nature.

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

Usage Guidelines4/5

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

The description implies the tool is for reverse geocoding, and sibling names suggest different functionalities. However, no explicit guidance on when to use versus when not to, or alternatives.

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

text_searchAInspect

在指定城市内按关键词搜 POI(酒店/餐厅/景点/地标)。返回前 10 条。

ParametersJSON Schema
NameRequiredDescriptionDefault
cityYes查询城市,例如 '北京'(必填以提高准确度)
typesNo可选 POI 大类,例如 '住宿' / '餐饮' / '购物'(高德 types 编码)
keywordsYes搜索关键词,例如 '希尔顿酒店' / '星巴克'

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations provided, the description carries full burden. It discloses the result limit (top 10) but does not mention other behaviors such as ordering, error handling, or auth requirements. This partial disclosure earns a 3.

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, concise sentence that communicates the essential purpose and result limit with no extraneous words. It is well-structured and front-loaded.

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 absence of an output schema and annotations, the description is adequate but not complete. It explains the basic functionality and result limit but lacks details on response structure, error behavior, or interaction between parameters. With three siblings, more comparative context would help.

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?

Schema coverage is 100% with descriptions for each parameter. The description reiterates the purpose of city and keywords but adds no new semantics beyond the schema. The types parameter is already explained in the schema.

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

Purpose5/5

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

The description clearly states the tool searches for POIs (hotels, restaurants, attractions, landmarks) by keyword within a specified city and returns the top 10 results. This distinguishes it from siblings like geocode (address to coordinates) and around_search (location-based search).

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

Usage Guidelines3/5

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

The description implies usage for keyword-based POI search within a city but does not explicitly state when to use this tool over alternatives like around_search. No guidance on prerequisites or exclusions is provided.

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. Dates show when Glama detected each change.

  1. 4 tool updatesv0.1.0
    • First observedaround_search
    • First observedgeocode
    • First observedregeocode
    • First observedtext_search
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

All four tools have clearly distinct purposes: geocode converts address to coordinates, regeocode does the reverse, text_search searches POIs by keyword in a city, and around_search finds POIs near a coordinate. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with descriptive verbs (geocode, regeocode, text_search, around_search). The use of 'regeocode' as a prefix variant is coherent within the domain.

Tool Count5/5

The server has 4 tools, which is perfectly scoped for a geocoding and POI search service. Each tool covers a fundamental operation without being excessive or insufficient.

Completeness4/5

The tool set covers forward and reverse geocoding as well as two common POI search modes (keyword and proximity). A minor gap is the lack of a tool to retrieve details for a specific POI, but the existing tools still provide useful results.

Maintenance

ActivitySlowing
ResponsivenessNo issues

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

  • Google Maps MCP Server

    Moe03
    A
    license
    C
    quality
    D
    maintenance
    Provides access to Google Maps API functionality including geocoding, place search, direction routing, and distance calculations through a structured MCP interface.
    4
    6
    MIT

  • AMap Maps MCP Server

    masx200
    A
    license
    A
    quality
    C
    maintenance
    Enables location-based services through AMap/AutoNavi Maps API including geocoding, weather information, route planning, and POI searches. Supports multiple transportation modes and provides detailed geographic data for Chinese locations.
    12
    3
    Mulan Permissive Software , Version 2

  • Amap MCP Server

    zengzeruidd-a11y
    A
    license
    A
    quality
    D
    maintenance
    A Model Context Protocol (MCP) server that wraps the Amap (高德地图) Web Service APIs, giving AI assistants like Claude Code 9 map tools: geocoding, route planning (driving/transit/walking/cycling), POI search, nearby search, distance measurement, and IP location.
    12
    37
    MIT

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/gcszkjpzzv-beep/TravelMind_MCP'

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