高德地图

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes (e.g., route planning by mode, POI search, geocoding, weather), but there is some overlap between maps_around_search and maps_text_search for POI search, and between maps_geo and maps_regeocode for address/coordinate conversion, which could cause minor confusion. Descriptions help clarify, but boundaries are not perfectly sharp.
Naming Consistency4/5
Tool names follow a consistent snake_case pattern with a 'maps_' prefix, and most use descriptive verb_noun combinations (e.g., maps_direction_driving_by_address). However, there are minor deviations: maps_around_search uses 'around' instead of a verb, and maps_distance, maps_geo, maps_ip_location, maps_regeocode, maps_search_detail, maps_text_search, and maps_weather lack a clear verb, making the naming slightly less uniform.
Tool Count5/5
With 16 tools, the count is well-suited for a comprehensive mapping and navigation server. It covers route planning (multiple modes and input types), POI search, geocoding, distance measurement, IP location, and weather, providing a robust feature set without being overwhelming or sparse.
Completeness5/5
The tool set offers complete coverage for a mapping domain, including route planning (driving, bicycling, walking, transit with both address and coordinate inputs), POI search and details, geocoding and reverse geocoding, distance measurement, IP location, and weather. There are no obvious gaps; agents can handle typical mapping tasks end-to-end.
Average 3.5/5 across 16 of 16 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on January 10, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'returns relevant information' without disclosing behavior such as pagination, rate limits, authentication needs, or what happens with missing parameters. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but at the expense of necessary information. It does not earn its place because it omits crucial details that would aid the agent.
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 3 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the output format, limitations, or how to use the optional parameters effectively, leaving significant gaps.
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?
Schema coverage is 0%, so the description must compensate. It only mentions 'keywords' generically and fails to explain 'city' and 'citylimit' parameters, their defaults, or how they affect the search. This adds almost no value over the schema names.
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?
Description clearly states it is a keyword search for POI (points of interest) using a specific verb ('搜索' - search) and resource ('POI'). However, it does not differentiate from sibling tools like maps_around_search or maps_search_detail, which could also involve searching.
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 on when to use this tool versus alternatives (e.g., maps_around_search for location-based search). The description only states what it does, not when or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only gives a high-level behavior. It does not disclose what the 'type' parameter values mean, the output format, or any limitations (e.g., coordinate format, error handling).
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 clear sentence that efficiently conveys the core purpose and supported modes. No redundant words.
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, no output schema, and many sibling tools, the description is insufficient for correct invocation. Missing parameter details and output behavior leave an agent guessing.
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?
Schema description coverage is 0%, and the description does not explain any parameter. The 'type' parameter is not described (default '1' meaning unknown), and 'origins'/'destination' lack format specification (e.g., 'lat,lng').
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 measures distance between two latitude/longitude coordinates and supports driving, walking, and spherical modes. This distinguishes it from sibling direction tools (which provide routes) but does not explicitly contrast them.
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 explicit guidance on when to use this tool vs alternatives like direction tools. The usage context is implied from the purpose, but there is no 'when to use' or 'when not to use' advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the tool locates IP location but lacks details on accuracy, data source, rate limits, or what happens with invalid inputs. This is minimal for behavioral transparency.
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 short sentence with no redundant information. It is efficiently front-loaded, delivering the core purpose immediately without extraneous text.
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?
With only one parameter and no output schema, the description could be more complete. It does not explain what '位置' (location) means (e.g., coordinates, address, city) or the format of the result, leaving the agent with insufficient context for understanding the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for the single parameter 'ip'. The description adds that the parameter expects an IP address, which is minimal semantic guidance given the tool's focus. It does not clarify format or constraints (e.g., IPv4 vs IPv6).
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 locates the position of an IP address, using the verb '定位' (locate) and resource 'IP 位置' (IP location). It distinguishes from sibling tools like maps_direction or maps_geo, which have different purposes.
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives like maps_geo or maps_search_detail, nor does it specify any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions conversion and landmark support but does not disclose potential rate limits, coordinate system (e.g., WGS84), accuracy, or whether partial addresses are accepted.
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?
Description is concise (two sentences) and front-loaded with the primary functionality. However, it could be slightly more structured by separating purpose, usage, and parameter details.
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 output schema, no annotations, and 0% schema parameter descriptions, the description is insufficient. It does not explain return values, error handling, or coordinate format, making it incomplete for an agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not clarify the meaning of the 'address' and optional 'city' parameters, nor how to structure the address input. This leaves ambiguity for the agent.
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 structured addresses to latitude/longitude coordinates and can parse landmarks. It distinguishes itself from sibling tools like maps_around_search and various direction tools, which focus on different map functionalities.
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 on when to use this tool versus alternatives such as maps_regeocode or maps_text_search. It does not mention prerequisites, address format expectations, or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the transformation but does not disclose behavior such as read-only nature, required API keys, rate limits, or coordinate format requirements. Minimal disclosure for a tool that likely involves external API calls.
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?
Single sentence, front-loaded with the core action. No unnecessary words, but brevity sacrifices detail that could be added without padding.
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?
For a simple tool with one parameter and no output schema, the description is minimally adequate. It conveys the main purpose but lacks details on output structure and parameter format, which would help the agent invoke it correctly without additional inference.
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 0%, so the description adds some meaning by specifying that the 'location' parameter is a Gaode coordinate. However, it does not clarify the expected format (e.g., 'lng,lat') or provide examples, leaving ambiguity for the agent.
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 converts a Gaode coordinate to administrative division address info, distinguishing it from sibling tools like maps_geo (address to coordinates) and maps_search_detail (POI search). The verb '转换' and resource '经纬度坐标' are specific, but the output could be more precisely defined.
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 on when to use this tool versus alternatives (e.g., maps_geo for reverse geocoding or maps_search_detail for location details). The description implies usage but does not explicitly state context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral transparency. It only states the basic operation (search POIs with keywords, location, radius) but does not describe output format, error conditions, or behavior when no keywords are given.
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 very short—one sentence that front-loads the purpose. It wastes no words, though being in Chinese may reduce readability for English-based agents.
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?
With no output schema and 0% parameter coverage, the description should explain what the tool returns (e.g., list of POI names, addresses, coordinates). It does not, leaving the agent unaware of the output structure. The tool is fairly simple (3 params), but the description is incomplete.
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 description coverage is 0%, so the description adds meaning by explaining that 'location' is coordinates, 'radius' is the search range, and 'keywords' are search terms. However, it lacks specifics such as radius unit (likely meters) and location format (lat,lng), leaving ambiguity.
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 it searches for POIs based on keywords and location within a radius. This distinguishes it from sibling tools like maps_text_search (text-only) and maps_search_detail (retrieve specific POI details). The verb 'search' and resource 'POI' are explicit.
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 on when to use this tool vs. alternatives such as maps_text_search or maps_search_detail. There is no mention of prerequisites, constraints, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose behavioral traits such as what the detailed information includes, potential errors, or any prerequisites beyond the ID.
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 concise sentence that directly states the tool's purpose without extraneous information, though it could be more explicit about usage context.
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 lack of output schema and annotations, the description should explain what 'detailed information' includes. It does not, leaving the agent uncertain about the return value or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds minimal meaning to the 'id' parameter, only hinting its origin (from keyword or surrounding search) but not specifying format, validation, or how to obtain 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?
The description clearly states the tool queries detailed information for a POI ID obtained from keyword or surrounding search, distinguishing it from sibling tools like maps_text_search and maps_around_search which produce the ID.
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 the tool is used after obtaining a POI ID from keyword or surrounding search, but lacks explicit guidance on when to use it versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action without mentioning side effects, read-only nature, authentication needs, or error handling. The tool is likely safe and read-only, but this is not explicit.
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 conveys the core functionality without any unnecessary words or repetition.
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?
For a simple tool with one parameter and no output schema, the description lacks information about the output format or what the response contains. It provides the basic purpose but is not fully complete for an agent to know what to expect.
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 0%, so the description adds some meaning by stating that the 'city' parameter can be a city name or adcode. However, it does not specify format requirements, examples, or whether both are accepted interchangeably, leaving ambiguity.
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's purpose: querying weather for a specified city using city name or standard adcode. It uses a specific verb ('查询') and resource ('天气'), and the siblings are all different types of map tools, so there's no confusion with alternatives.
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 guidelines are provided about when to use this tool versus alternatives, nor any prerequisites or exclusions. The description only explains what the tool does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 mentions that the tool returns commuting route data with distance, duration, and detailed transit info. However, it does not disclose potential behavioral traits like rate limits, dependency on real-time data, or limitations in specific regions. The description is adequate but not thorough.
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 reasonably concise, with a clear main paragraph followed by a structured Args/Returns section. The key purpose and a critical usage condition (cross-city requirement) are front-loaded. Minor redundancy exists but overall the structure is effective.
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 complexity of public transit routing, the description covers the essential purpose and parameters but lacks detailed return structure information (e.g., steps, fares, transit types). Without an output schema, the return value description is too vague for an agent to reliably parse results. Additional detail on the response format would improve completeness.
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 zero description coverage, but the description's docstring adds significant value by explaining each parameter's meaning and format, including an example coordinate format for origin and destination. This compensates well for the schema gaps, though it could further clarify acceptable city names or value constraints.
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 it plans public transit commuting routes using coordinates. It explicitly mentions the inclusion of trains, buses, and subways, and specifies the cross-city scenario requirement. The tool name and sibling tools distinguish it from driving, walking, and bicycling alternatives.
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 provides a crucial usage guideline: in cross-city scenarios, both start and end cities must be provided. However, it lacks explicit guidance on when to use this tool versus other direction tools (e.g., driving, walking) or when not to use it. The guideline is incomplete for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses distance constraint (100km) and return fields (distance, duration, details). No annotations, so description carries full burden. Lacks details on authentication, rate limits, or side effects.
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?
Efficiently structured with a brief overview and parameter descriptions. Could be slightly more concise, but no wasted sentences.
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?
Covers input format, distance limit, and return fields (distance, duration, navigation details). With no output schema, this is adequate. Could add more detail on return structure.
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?
Schema has 0% coverage, but description adds format ("经度,纬度") and example. This compensates well for the lack of schema descriptions.
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?
Clearly states it's for walking path planning using start/end coordinates, within 100km. Distinguishes from siblings by specifying coordinate-based and walking mode.
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?
Implied usage: for walking, by coordinates, up to 100km. No explicit when-not-to-use or alternatives, but sibling tools are present for other modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 indicates the tool returns route data (distance, duration, details), implying a read-only operation, but does not disclose potential side effects, authentication needs, or rate limits. The description is adequate but incomplete for critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: one sentence for the purpose followed by structured Args/Returns. It is front-loaded with the core function and contains no unnecessary words. Every sentence serves a purpose, and the structure is clear and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two simple parameters, no output schema, and no nested objects, the description provides everything needed: purpose, parameter format, and return type (dictionary with distance, duration, details). Despite the lack of output schema, the description's return summary is sufficient for an agent to understand the result. All relevant information is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description for parameters, but the description's Args section fully compensates by providing the exact format ('经度,纬度') and a concrete example. This adds significant meaning beyond the bare schema, enabling correct usage. No enum or nested objects exist, so the description covers the semantic gap entirely.
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 plans driving routes using start and end coordinates for cars/sedans, which is specific and distinguishes it from sibling tools like maps_direction_driving_by_address (for addresses) and maps_direction_transit_integrated_by_coordinates (for transit). The verbose verb 'plan' and resource 'driving route' are explicit.
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 explicit guidance is given on when to use this tool vs. alternatives. The description does not mention scenarios where coordinates are preferred over addresses, nor does it exclude use cases like transit or walking. Sibling tools such as maps_direction_driving_by_address and maps_direction_transit_integrated_by_coordinates require differentiation, but the description lacks such guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It mentions traffic and road restrictions, but lacks details on error handling, auth requirements, or rate limits.
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?
Well-structured with clear sections, but the parameter listing is slightly verbose; could be more concise without losing clarity.
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?
Covers purpose, usage, parameters, and return structure. Missing error handling or prerequisites, but sufficient for a straightforward direction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description fully explains all 4 parameters with examples and purpose, compensating completely for the gap.
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?
Clearly states the tool plans a driving route using addresses, distinguishing it from the coordinates-based sibling via explicit recommendation.
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?
Provides explicit guidance to use addresses unless coordinates are needed, but does not address when to avoid this tool entirely (e.g., for non-driving modes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions the return type (Dict with distance, duration, instructions) and transit modes considered (buses, subways, trains), but lacks details on error handling, time constraints, or edge cases.
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 reasonably concise with a clear intro and structured args/returns sections. The args section is somewhat redundant with the schema but serves as inline documentation.
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?
Given the complexity (4 required params, no output schema, no annotations), the description covers purpose, arguments, and return values adequately. It explains cross-city requirements and transit options, but does not address error scenarios or when to consider alternative travel modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides detailed parameter descriptions, including examples for addresses and notes on city parameters being required for cross-city transit. This adds significant meaning beyond 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 it plans a public transit route between two locations using addresses, which distinguishes it from coordinates-based and other transport mode tools. The verb 'plans a public transit route' is specific and aligns with the tool name.
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 recommends using this tool over the coordinates variant unless there is a specific reason for coordinates, providing a clear usage context. However, it does not explicitly mention when not to use it or alternatives like driving or walking tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool considers bridges, one-way streets, and road closures, and supports routes up to 500km. This adds behavioral context beyond the schema. However, it does not mention error handling, authentication needs, or rate limits. With no annotations provided, the description carries the full burden.
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 with a one-sentence summary, parameter details, and behavioral notes. It is well-structured and front-loaded. Minor redundancy: parameter details could be integrated into schema descriptions, but the description is still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, parameter format, return type (Dict with distance, duration, instructions), and key behavioral constraints (bridges, one-way streets, road closures, 500km limit). With no output schema, it adequately explains return values. The description is complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions for parameters (0% coverage), but the description clearly explains the format 'longitude,latitude' with examples for both origin_coordinates and destination_coordinates. This adds significant meaning beyond the schema, fully compensating for the lack of schema descriptions.
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 'Plans a bicycle route between two coordinates,' with a specific verb and resource. The tool name itself is descriptive, and it distinguishes from siblings like maps_bicycling_by_address (address input) and maps_direction_walking_by_coordinates (different travel mode).
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 bicycle route planning with coordinate inputs but does not explicitly state when to use this tool versus alternatives (e.g., address-based or other modes). No exclusion criteria or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It states the return type (dict with distance, duration, turn-by-turn instructions) and a 100km route limit, which is helpful. It does not mention permissions or rate limits, but the tool is likely read-only and low-risk.
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 well-structured with an introductory sentence, parameter list, and return value description. It is clear but slightly verbose; could be trimmed without losing information.
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?
Given no output schema, the description adequately explains return values and a constraint (100km). It differentiates from the coordinates sibling but does not compare to other walking tools or address-based tools for other modes. Still sufficient for a focused tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explaining all four parameters in plain text, including examples (e.g., '北京市朝阳区阜通东大街6号') and the purpose of optional city parameters for geocoding accuracy, adding significant meaning beyond 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 it plans a walking route between two locations using addresses, and the tool name includes 'walking_by_address', distinguishing it from other tools like maps_bicycling_by_address or maps_direction_walking_by_coordinates.
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 explicitly recommends using this tool over the coordinates version unless there's a specific reason for coordinates, providing clear guidance for address-based walking routes. However, it does not discuss when to choose walking over other modes like driving or bicycling, which are available as siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses important behaviors: considers bridges, one-way streets, road closures, and route limit of 500km. It also describes return structure (distance, duration, turn-by-turn). However, it does not mention authentication or rate limits, which could be relevant.
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 well-structured with a concise main sentence followed by Args/Returns sections. It is slightly verbose with example addresses but maintains clarity. Every sentence serves a purpose, though could be slightly trimmed.
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?
Given 4 parameters, no output schema, and no annotations, the description covers purpose, usage guidance, parameter details, and behavioral traits (bridges, one-ways, limit). It lacks error handling hints but is sufficiently complete for a routing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides detailed parameter info in the Args section, including types and examples (e.g., 'str', example addresses). This compensates fully for the lack of schema descriptions, adding context beyond the bare schema definition.
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 it plans a bicycle route using addresses, with specific verb 'Plans' and resource 'bicycle route'. It distinguishes from sibling tool 'maps_bicycling_by_coordinates' by explicitly mentioning 'using addresses' and recommending addresses unless coordinates are needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly recommends using this tool over coordinates unless there's a specific reason, providing clear when-to-use guidance. It also mentions the route limit of 500km and return format, aiding in decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![amap-mcp-server MCP server](https://glama.ai/mcp/servers/sugarforever/amap-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/sugarforever/amap-mcp-server)

Score Badge

Copy to your README.md:

[![amap-mcp-server MCP server](https://glama.ai/mcp/servers/sugarforever/amap-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/sugarforever/amap-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/sugarforever/amap-mcp-server'

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