mcp-amap

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct operation: coordinate conversion, geocoding, POI search in different scopes, route planning by mode, and distance calculation. There is no functional overlap, so agents can easily select the correct tool.
Naming Consistency5/5
All tool names use snake_case with a clear verb-prefix (e.g., search_poi, calculate_distance) or standard geospatial terms (geocode, reverse_geocode). The pattern is consistent and predictable.
Tool Count5/5
12 tools is a well-scoped count for a mapping service. Each tool covers a necessary function without redundancy, making the server feel complete yet not bloated.
Completeness5/5
The toolset covers geocoding (both forward and reverse), POI search via keyword, radius, polygon, and detail lookup, plus driving/walking/transit routes, distance calculation, coordinate conversion, and search suggestions. There are no obvious gaps for a typical AMAP use case.
Average 3.5/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 provided, the description carries the full burden of behavioral disclosure. It only states the input types and the conversion action; it does not describe the output format, coordinate system, error handling, or behavior when an address is ambiguous or not found. This is a significant gap for a geocoding tool.
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 front-loads the core action ('将地址转换为经纬度坐标') and then adds a brief capability note. It contains no filler or redundant information.
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 2-parameter tool with no output schema or annotations, the description is adequate but not fully complete. It confirms the core operation and accepted input types, but omits behavioral expectations like return format and failure handling, and gives no usage context relative to sibling tools.
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 the schema already documents both parameters with examples. The description's statement about supporting structured addresses and landmark names adds minor semantic clarification that aligns with the address parameter examples, but it does not provide additional detail beyond what the schema conveys. Baseline 3 is appropriate.
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 addresses to latitude/longitude coordinates, which is a specific verb+resource action. It also notes support for structured addresses and landmark names, which helps distinguish it from reverse_geocode and coordinate_convert, though it does not explicitly name 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?
The description provides no guidance on when to use this tool versus siblings like reverse_geocode or search_poi. The mention of supporting structured addresses and landmark names implies accepted input types, but there is no context about when to prefer this tool, when not to use it, or what alternatives exist.
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 present, so the description must fully disclose behavior. It only mentions that it calculates a transit plan, but does not describe return format, edge cases, or side effects (if any). The mention of including metro/bus adds slight context but is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words, making it concise. However, it is somewhat under-specified for an 8-parameter tool, which prevents a perfect score. There is no structural complexity, but it is not verbose.
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?
The tool has 8 parameters, no output schema, and no annotations. The one-line description does not explain output structure, handling of cross-city queries (cityd), or how it fits into the broader routing workflow. It is not complete enough for an agent to confidently invoke this tool without additional context.
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 100%, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides (e.g., coordinate format, strategy options, date/time defaults). It only loosely refers to 'two points' with no additional detail.
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 it computes public transit transfer plans between two points, including metro and bus. This is a specific verb+resource and implicitly distinguishes it from sibling tools like driving_route or walking_route, though it does not explicitly name 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 implies usage for public transit planning (as opposed to driving or walking), but it does not explicitly state when to use this tool versus alternatives like driving_route or distance_calculate. No exclusions or when-not-to-use guidance is provided.
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 of behavioral disclosure. It only states the primary function without mentioning safety, rate limits, response format, or any constraints, offering minimal transparency about the tool's behavior.
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, front-loaded sentence with no unnecessary words. It earns its place by clearly stating the purpose, though it could include a bit more context without becoming verbose.
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?
The tool has no output schema and the description does not explain the structure of returned suggestions, nor does it provide broader context for an agent deciding when to use it. This leaves significant gaps for a simple autocomplete tool.
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 descriptions cover all parameters (100% coverage), so the description adds no extra parameter semantics. The baseline of 3 is appropriate since the schema handles the explanatory burden.
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 provides search suggestions based on input keywords, using the autocomplete analogy to distinguish it from full search tools like search_poi. The verb and resource are specific, and the scope is well-defined.
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 autocomplete-style suggestions but does not explicitly contrast with sibling tools such as search_poi or search_around. There is no mention of when not to use it or alternatives, so guidance is only implied.
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 transparency burden. It reveals the type of content returned but does not state that this is a safe read operation, error behavior, or any prerequisites. Key behavioral aspects like response format and side effects are absent.
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, front-loaded sentence that clearly communicates purpose without unnecessary detail. It is efficient and well-structured.
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 retrieval tool with one parameter and no output schema, this description covers the essentials: what it does and what data is included. However, without annotations, it would benefit from noting response format or error handling to be fully 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?
The schema already fully documents the single parameter 'id' with 100% coverage, so the description adds little beyond what is in the schema. The mention of using the ID is redundant; the baseline of 3 applies.
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 retrieves detailed POI information by ID, listing example fields like business hours, contact, and ratings. This aligns with the tool name and distinguishes it from sibling search tools, though it doesn't explicitly reference 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 context is implied: use when you have a POI ID and need details, but there is no explicit guidance on when not to use it or what alternative to choose. No exclusions or alternatives are mentioned.
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 bears full responsibility for behavioral disclosure. It mentions support for straight-line and driving distance and includes time, but omits return format, units, accuracy limits, rate limits, or the 100-origin cap already noted in the schema. Behavioral caveats are absent.
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, front-loaded sentence with no redundancy. It efficiently conveys the primary action and supporting detail (distance types), earning its place without wasting tokens.
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?
There is no output schema or annotations, and the description is minimal. It covers the core function but leaves unanswered return values, units, and when to prefer this over sibling tools. For a tool with 3 parameters and an enum, the description is adequate but not fully self-sufficient.
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 100% for all three parameters, so the baseline is 3. The description adds no param-level detail beyond the schema; it does not specify coordinate order, units, or additional semantics beyond what is already documented in the input 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?
Description uses specific verb '计算' (calculate) and identifies the resource (distance/time) plus the scope (multiple origins to one destination). It clearly distinguishes from sibling routing tools like driving_route and walking_route by focusing on distance measurement rather than pathfinding.
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 distance/time queries but provides no explicit guidance on when to use this tool over routing alternatives. It does not mention exclusions or alternative tools, leaving the agent to infer applicability from the tool's name and purpose.
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 provided, the description carries the full burden of behavioral disclosure. It states that the tool provides navigation info, distance, time, and cost estimates, but it does not explicitly disclose whether the operation is read-only, any prerequisites, or side effects. This is insufficient for a tool with no annotations.
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 is front-loaded with the primary purpose and key outputs. There is no wasted content or unnecessary details.
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?
The tool has 9 parameters and no output schema, yet the description only captures the basic function and outputs. It does not mention the tool's advanced capabilities such as waypoints, avoidance areas, vehicle type, or strategies, which are significant features. While the schema covers these, the description lacks a high-level overview of the tool's full scope.
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 100%, so the baseline is 3. The description does not add meaning beyond the schema; it only refers to two points (origin and destination), while the schema already provides detailed descriptions for all parameters. No additional value is provided.
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 calculates driving routes between two points and lists the types of output (navigation info, distance, time, cost estimates). It is specific and distinguishes from sibling tools like walking_route and transit_route by explicitly saying '驾车' (driving).
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 driving directions, as it mentions '驾车' (driving), but it does not explicitly state when to use it over alternatives like walking or transit. No exclusions or alternative tools are mentioned, so the guidance is only implied.
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 carries the full burden. It only lists capabilities and does not disclose behavioral traits like pagination limits, result ordering, error conditions, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the main action, and contains no redundant or filler information.
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?
With 6 parameters and no output schema, the description is adequate for basic usage but lacks guidance on result structure, pagination behavior, and how it differs from spatial search variants. This makes it incomplete for nuanced tool selection.
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 input schema covers 100% of parameters with detailed descriptions. The tool description adds minimal value beyond restating city and type filtering, so the baseline of 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?
The description clearly states the tool searches POIs by keyword, provides examples (restaurants, hotels, attractions), and mentions filtering by city and type. This distinguishes it from spatial search siblings like search_around and search_polygon.
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 searches but does not explicitly contrast with sibling tools such as search_around or search_polygon. It also does not state when not to use the tool or mention alternatives.
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 carries the full burden for behavioral disclosure. It only states the core search behavior and examples, without mentioning any limitations, result format, pagination behavior, or special conditions. This is a significant gap for a tool that likely has more nuanced behavior.
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 front-loads the action (search around a point) and includes relevant scenario examples. There is no wasted information or redundancy.
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?
The description is minimal but sufficient for a simple search tool with fully documented parameters. It lacks explicit notes on return values (no output schema) and does not differentiate from sibling tools beyond the basic purpose, but the schema covers parameter details. The absence of any edge-case or behavior notes makes it only slightly above minimum viability.
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 100%, so all parameters are well-documented in the schema. The tool description adds no additional parameter semantics beyond what the schema already provides, making the baseline score of 3 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?
The description clearly states the tool's function: searching for points of interest around a specified coordinate. It provides concrete scenario examples (nearby restaurants, gas stations) and distinguishes it from sibling search tools by emphasizing the coordinate-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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context with '适用于' (suitable for) and examples of when to use the tool. It does not explicitly mention alternatives or exclusions, but the scenario examples imply the appropriate use case.
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 carries the full burden of behavioral disclosure. It only states the basic function without revealing any behavioral traits such as result format, pagination handling, coordinate system, or edge-case behavior (e.g., polygon validation). This leaves the agent with limited insight into how the tool behaves beyond the initial action.
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, focused sentence that front-loads the verb and scope without any superfluous content. It is exemplary in its conciseness and clarity, achieving maximum information density with minimal words.
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?
The schema covers all parameters, but with no output schema, the description could have provided more context about the result format (e.g., a list of POIs) or pagination behavior. The description implicitly suggests an output (POIs) but does not confirm the structure, leaving room for ambiguity about what the agent can 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?
The input schema provides descriptions for all five parameters, so the baseline is 3. The description adds no additional parameter-level meaning, such as emphasizing that polygon is required or explaining how page_size is constrained. It relies entirely on the schema's existing documentation.
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 specifies the action (search), the resource (points of interest), and the scope (within a specified polygon area), making it distinct from sibling tools like search_around (radius-based) and search_poi (general keyword search). The phrase '在指定多边形区域内搜索兴趣点' unambiguously defines the tool's purpose.
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 provides clear usage context with '适用于特定区域范围的搜索' (suitable for search in a specific area range), indicating when this tool should be preferred. However, it does not explicitly name alternative tools or state exclusion criteria, so it lacks the full compare-and-contrast guidance of the highest tier.
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 transparency burden. It discloses that the tool provides walking navigation information and estimated time, which is useful but lacks details on return structure, errors, or multipath behavior. Adequate for a simple route tool.
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 front-loads the action and outputs. No wasted words or redundant detail.
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 simple 3-parameter tool and high schema coverage, the description is largely complete. It states the purpose and expected outputs. However, it could explicitly mention multipath behavior or coordinate format, though these are covered by the schema.
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 all three parameters, so the schema does the heavy lifting. The description adds no additional parameter semantics beyond what's already stated, and the mention of '预计时间' is output-related. 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?
The description uses a specific verb '计算' and resource '两点间的步行路径', clearly stating it calculates walking routes and provides navigation info and estimated time. This distinguishes it from sibling tools like driving_route and transit_route.
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 use for walking routes, but does not explicitly state when to use this tool versus driving_route or transit_route. No exclusions or alternatives are mentioned, though the '步行' terminology provides clear context.
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 burden. It discloses the conversion target (GCJ02) and supported input systems, which is useful. However, it does not mention output format, error behavior, or whether the operation is read-only (likely but not stated). For a simple conversion tool this is acceptable, but richer context (e.g., 'returns JSON with converted coordinates') would improve 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, front-loaded sentence that conveys the essential purpose and scope. Every word earns its place; no fluff or repetition. It is concise yet informative.
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 simplicity and rich schema, the description is mostly complete. However, there is no output schema, and the description does not explain the return format (e.g., converted coordinates as a string or JSON). It also omits the 40-point batch limit, though that is in the schema. An agent would benefit from knowing what the response looks like, so completeness is adequate but not excellent.
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 100% and includes detailed parameter descriptions (e.g., coordsys enum meanings, locations format and 40-point limit). The tool description adds no parameter-specific information beyond what the schema already provides, so it neither compensates nor adds value. 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?
The description clearly states the tool's function: converting coordinates from other systems (GPS, Baidu, Mapbar) to the AMap GCJ02 system. It uses a specific verb ('convert'), identifies the resource ('coordinates'), and distinguishes from sibling tools like geocoding or routing.
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 when to use the tool: when you have coordinates in a non-GCJ02 system and need GCJ02. It lists supported source systems, but does not explicitly exclude alternatives or state conditions such as 'use this instead of search_poi when you need coordinate conversion'. Context is clear, but no explicit when-not-to-use guidance is given.
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 discloses that the result includes structured address, surrounding POI, and road information, which adds some behavioral context. However, it does not mention that this is a read-only operation, any API requirements, rate limits, or error cases. For a conversion tool, this is moderately transparent but not fully comprehensive.
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 is front-loaded with the core purpose and includes relevant output details. Every word contributes meaning, with no redundancy or filler.
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 tool's simplicity and the fact that all parameters are fully described in the schema, the description is largely complete. It explains what the tool does and hints at the output richness. It lacks usage guidance and explicit read-only disclosure, but the schema and tool name cover much of the needed context. A 5 would require more detail on return format or edge cases.
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 100% for all three parameters, so the baseline is 3. The description adds minimal context beyond the schema by stating output components (POI, roads) that relate to the 'extensions' and 'radius' parameters, but it does not delve into parameter syntax or additional meaning. The schema already provides clear descriptions and an example for location.
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 function: '将经纬度坐标转换为详细的地址信息' (convert latitude/longitude coordinates to detailed address information). It uses a specific verb 'convert' and identifies the resource (coordinates to address), and explicitly mentions outputs like structured address, surrounding POI, and road info. This distinguishes it from sibling 'geocode' (forward geocoding) and other POI search tools.
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 gives clear context: the tool converts coordinates to addresses, implying use when an agent has coordinates and needs a human-readable address. It does not explicitly mention alternatives or exclusions, but the contrast with 'geocode' and other siblings is clear from the reverse conversion nature. No explicit when-not-to-use guidance, so not a 5.
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:

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

Score Badge

Copy to your README.md:

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

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

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