Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Amap (Gaode Maps) MCP Server find nearby coffee shops in Beijing"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Related MCP server: Baidu Map Search MCP Server
⚠ 请务必根据自己的操作系统调整命令，powershell 和 bash 的命令语法有所不同。
作者使用的是windows+git终端。 本教程前半段与官方基本无异，可查考官方文档中server开发示例。
# Linux or macOS
curl -LsSf https://astral.sh/uv/install.sh | sh# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"# 使用UV创建并进入项目目录
uv init build-mcp
cd build-mcp
# 创建虚拟环境
uv venv
source .venv/Scripts/activate
# 安装相关依赖
uv add mcp[cli] httpx pytest在 src/build_mcp/config.yaml 文件中添加以下内容：
# 高德地图API配置
api_key: test
# 高德地图API的基础URL
base_url: https://restapi.amap.com
# 代理设置
proxy:
# 日志等级
log_level: INFO
# 接口重试次数
max_retries: 5
# 接口重试间隔时间（秒）
retry_delay: 1
# 指数退避因子
backoff_factor: 2
# 日志文件路径
log_dir: /var/log/build_mcp⚠ config.yaml 文件需要放在 src/build_mcp/ 目录下，这样在加载配置时可以正确找到。
⚠ 首次安装代码时需要使用 pip install -e . 命令，这样可以将当前目录作为一个可编辑的包安装到虚拟环境中。这样在开发过程中对代码的修改会立即生效，无需重新安装。
uv pip install -e .通过以下命令来运行 MCP 服务：
启动stdio协议的MCP服务：
uv run build_mcp启动streamable-http协议的MCP服务：
uv run build_mcp streamable-httpInspector是官方提供的一个MCP服务调试工具，可以通过它来启动一个本地web界面，在界面中可以直接调用MCP服务的工具。 相对更加直观和易用，比较推荐这种方式，详情可以查看官方文档。
# 使用Inspector调试stdio协议的MCP服务
API_KEY=你的KEY mcp dev src/build_mcp/__init__.py首先你得拥有一个MCP客户端，目前市场上各种类型得MCP客户端层出不穷，至于用什么全凭你的爱好了。
这里有一份非常详细的MCP客户端使用攻略，是github上一个非常棒的项目：MCP客户端使用攻略
选择一个客户端下载安装，然后我们对我们开发的服务进行配置。
{
"mcpServers": {
"build_mcp": {
"command": "uv",
"args": [
"run",
"-m"
"build_mcp"
],
"env": {
"API_KEY": "你的高德API Key"
}
}
}
}⚠ 要注意本地UV环境，如果安装了多个UV可能会导致环境混乱，这是开发过程中比较头疼的一点，要自己注意。
make streamable-http$ make streamable-http
Starting MCP service with streamable-http protocol...
uv run build_mcp streamable-http
INFO: 🚀 Starting MCP server with transport type: streamable-http
INFO: Started server process [6064]
INFO: Waiting for application startup.
INFO: StreamableHTTP session manager started streamable_http_manager.py:109
INFO: Application startup complete.
INFO: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
启动成功后会在8000端口启动一个HTTP服务。
{
"mcpServers": {
"build_mcp_http": {
"url": "http://localhost:8000/mcp"
}
}
}获取用户的 IP 地址定位信息，返回省市区经纬度等信息。
| Name | Required | Description | Default |
|---|---|---|---|
| ip | No | 用户的ip地址 |
| Name | Required | Description |
|---|---|---|
| data | No | |
| meta | No | |
| error | No | |
| success | Yes |
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 mentions the output format but doesn't describe error handling, rate limits, authentication needs, or whether the tool is read-only or has side effects. For a tool with no annotation coverage, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and output. It avoids unnecessary words, though it could be slightly more structured (e.g., separating purpose from output details).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) and the presence of an output schema, the description is minimally adequate. However, it lacks behavioral context (e.g., error cases, performance), which is needed since no annotations are provided. The output schema likely covers return values, so the description doesn't need to detail them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'ip' documented as '用户的ip地址' (user's IP address). The description doesn't add meaning beyond the schema, such as explaining default behavior when 'ip' is null or providing examples. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取用户的 IP 地址定位信息' (get user's IP address location information) and specifies the output '返回省市区经纬度等信息' (returns province, city, district, latitude/longitude, etc.). It uses specific verbs and resources, though it doesn't explicitly differentiate from the sibling tool 'search_nearby'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_nearby'. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
根据经纬度和关键词进行周边搜索，返回指定半径内的 POI 列表。
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | 中心点经纬度，格式为 'lng,lat'，如 '116.397128,39.916527' | |
| keywords | No | 搜索关键词，例如: '餐厅'。 | |
| types | No | POI 分类码，多个分类用逗号分隔 | |
| radius | No | 搜索半径（米），最大50000 | |
| page_num | No | 页码，从1开始 | |
| page_size | No | 每页数量，最大25 |
| Name | Required | Description |
|---|---|---|
| data | No | |
| meta | No | |
| error | No | |
| success | Yes |
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 mentions the basic operation (search and return POI list) but doesn't describe important behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or what happens when no results are found. For a search tool with 6 parameters and no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality without unnecessary words. It's appropriately sized for the tool's complexity and front-loads the essential information (search based on location/keywords, returns POIs within radius). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which should document return values), no annotations, and 100% schema coverage for parameters, the description provides adequate basic context. However, for a search tool with pagination parameters and no behavioral annotations, the description could better address usage patterns, result limitations, or common scenarios. It's minimally viable but lacks depth for optimal agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description mentions '经纬度和关键词' (longitude/latitude and keywords) and '指定半径' (specified radius), which aligns with parameters in the schema but doesn't add meaningful semantic context beyond what's already in the parameter descriptions. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '根据经纬度和关键词进行周边搜索，返回指定半径内的 POI 列表' (Search nearby based on longitude/latitude and keywords, returning a list of POIs within a specified radius). It specifies the verb ('搜索' - search), resource ('POI 列表' - POI list), and scope ('周边' - nearby/within radius). However, it doesn't explicitly differentiate from the sibling tool 'locate_ip', which appears to be a different type of location tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool 'locate_ip' or any other potential alternatives. There's no information about prerequisites, appropriate contexts, or when this tool would be preferred over other search or location tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0locate_ip1 field changedInput schema / titleAdded value: +"locate_ipArguments"search_nearby1 field changedInput schema / titleAdded value: +"search_nearbyArguments"locate_ipsearch_nearbyScored across 2 tools
The two tools have completely distinct purposes: one retrieves location data from an IP address, while the other searches for points of interest near given coordinates. There is no overlap in functionality or ambiguity in their intended use.
Both tools follow a consistent verb_noun naming pattern (locate_ip and search_nearby), using clear, descriptive verbs that align with their actions. The naming style is uniform and predictable across the set.
With only two tools, the server feels under-scoped for a mapping service like Amap, which typically involves broader functionality such as routing, geocoding, or traffic data. This limited set may hinder agents from performing comprehensive mapping-related tasks.
The toolset is severely incomplete for a maps domain, lacking essential operations like geocoding addresses, calculating routes, or retrieving traffic information. Agents will face significant gaps when trying to handle common mapping workflows.
MCP server for IPv4 geolocation with Chinese output: country/region/city, ISP and ASN.
IP Geolocation: This API provides fast, reliable, and developer-friendly IP geolocation, ASN.
Unlock the power of IP geolocation with our tool! Whether you're a developer needing location data
Geolocate Me turns your phone into location context for any AI assistant. Install the iOS or Android app, connect once with OAuth, and your GPS is queryable in natural language. Ask where you are, where you parked, where you were yesterday at 3pm, or how long you were at the office — the assistant calls the tool and answers with a real street address. https://geolocateme.app