Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MapmyIndia Mappls MCP Server Show me driving directions from Mumbai to Pune"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A high-performance Model Context Protocol (MCP) server for MapmyIndia (Mappls) REST APIs, built using the FastMCP open-source framework.
This server enables AI assistants (such as Claude, Gemini, ChatGPT, Cursor, and Antigravity) to query geographic data, perform geocoding, generate driving & walking directions, calculate distance matrix ETAs, discover points of interest (POIs), and look up eLoc place details across India.
FastMCP Framework: Built on Prefect HQ's fastmcp Python framework for automatic schema generation, robust validation, and low latency.
Flexible Authentication:
Static Access Token Mode: Pass a direct bearer MAPPLS_ACCESS_TOKEN.
OAuth 2.0 Client Credentials Flow: Pass MAPPLS_CLIENT_ID and MAPPLS_CLIENT_SECRET for automated token generation and pre-expiry refreshing.
Comprehensive Mappls Tools:
mappls_geocode: Convert location names to lat/long coordinates & eLoc codes.
mappls_reverse_geocode: Convert coordinates to formatted address details.
mappls_autosuggest: Live predictive location search suggestions.
mappls_get_directions: Route directions (driving, biking, walking, trucking) with turn-by-turn steps.
mappls_distance_matrix: N-to-M travel time and distance matrix calculations.
mappls_snap_to_road: Snap noisy GPS coordinate traces to road networks.
mappls_search_nearby: Discover POIs (restaurants, ATMs, hospitals, EV chargers, fuel stations) nearby.
mappls_place_details: Retrieve rich attributes for any 6-character Mappls eLoc code.
mappls_text_search: AI smart place search with spelling correction.
Built-in MCP Prompts: Pre-configured templates like plan_itinerary and optimize_logistics_hub.
Dual Transport Support: Run via stdio (for desktop apps) or sse (for HTTP microservices).
Offline / Mock Mode: Runs seamlessly in dry-run mode when API keys are not provided.
Related MCP server: mcp-tomtom
Python 3.10 or higher
MapmyIndia (Mappls) Developer Credentials or Access Token (from Mappls Console)
Clone or copy this repository, then create a .env file from .env.example:
cp .env.example .envEdit .env and fill in your Mappls token or client credentials:
# Option A: Direct Access Token (Recommended for Token Input)
MAPPLS_ACCESS_TOKEN=your_access_token_here
# Option B: Client Credentials
MAPPLS_CLIENT_ID=your_client_id_here
MAPPLS_CLIENT_SECRET=your_client_secret_here
MCP_TRANSPORT=stdioInstall the package in editable mode:
pip install -e .Or install with development dependencies:
pip install -e ".[dev]"uvx directly from GitHub)Anyone can use this MCP server directly from GitHub without cloning or local installation by using uvx (included with uv).
claude_desktop_config.json){
"mcpServers": {
"mappls": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/Bhupendrajee07/MMI-MCP.git",
"mmi-mcp"
],
"env": {
"MAPPLS_CLIENT_ID": "YOUR_MAPPLS_CLIENT_ID",
"MAPPLS_CLIENT_SECRET": "YOUR_MAPPLS_CLIENT_SECRET"
}
}
}
}mcp_config.json){
"mcpServers": {
"mappls": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/Bhupendrajee07/MMI-MCP.git",
"mmi-mcp"
],
"env": {
"MAPPLS_ACCESS_TOKEN": "YOUR_MAPPLS_ACCESS_TOKEN"
}
}
}
}mmi-mcp
# or
python -m mmi_mcp.server --transport stdiopython -m mmi_mcp.server --transport sse --host 127.0.0.1 --port 8000Run the unit and integration test suite:
$env:PYTHONPATH="src"; python -m pytest tests/ -vMIT License
Auto-suggest location search predictions for user input as text is typed. Returns ranked place recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| zoom | No | Optional map zoom level (1 to 18) for search bounds context. | |
| query | Yes | The search query prefix (e.g. "Taj Mahal" or "Fortis Hosp"). | |
| location | No | Optional lat,lng string center focus for proximity ranking (e.g. "28.6139,77.2090"). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that the tool operates on partial user input, returns suggestions live as text is typed, and ranks places by relevance. It could add more detail about ranking criteria, but it is not misleading or severely incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, information-dense sentences. The core behavior and output type are front-loaded, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and all parameters are documented, the description provides enough context for an agent to understand what to expect. It could be stronger by explicitly contrasting with mappls_text_search or mappls_geocode for complete-query use cases, but the autocomplete context is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with query, zoom, and location each already documented. The description confirms the query prefix pattern but adds no parameter-specific semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific behavior—auto-suggesting location search predictions as text is typed—and notes that it returns ranked place recommendations. This goes beyond a tautology and helps distinguish it from related tools like mappls_text_search or mappls_geocode, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'as text is typed' gives clear contextual guidance for when this tool is appropriate: interactive prefix-based autocomplete. It does not explicitly state when not to use it or name alternative tools, but the intended usage context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate travel distances and durations matrix between multiple origin and destination points in India.
| Name | Required | Description | Default |
|---|---|---|---|
| origins | Yes | List of origin coordinate strings ["lng1,lat1", "lng2,lat2"] or eLocs. | |
| profile | No | Transport profile mode: "driving", "biking", "walking", or "trucking". Default is "driving". | driving |
| destinations | Yes | List of destination coordinate strings ["lng1,lat1", "lng2,lat2"] or eLocs. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 adds the geographic constraint 'in India' and the implied read-only nature of 'Calculate'. It does not disclose potential API limitations, error behavior, or any other operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and resource, with no wasted words. It efficiently conveys the essential purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema and output schema cover parameter details and return structure, but the description lacks explicit usage guidance and behavioral context beyond the basic purpose. For a relatively simple tool, this is adequate but not complete; an agent would benefit from knowing when this tool outranks get_directions or snap_to_road.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of origin, destination, and profile parameters, including coordinate format and default values. The description adds no parameter-specific detail beyond what the schema already contains, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Calculate') and resource ('travel distances and durations matrix'), clearly distinguishing it from sibling tools like get_directions, which focuses on individual routes, and geocoding tools. The geographic scope ('in India') adds further precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'between multiple origin and destination points' implies the tool is suited for matrix-style requests rather than single-route calculations, giving some context. However, it does not explicitly mention when to prefer this over siblings like get_directions or mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Geocode an address or location text to retrieve latitude, longitude, eLoc code, and standardized address details in India.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Country region filter (default: "IND" for India). | IND |
| address | Yes | The target address, city, landmark, or location query string (e.g. "Connaught Place, New Delhi" or "Electronic City, Bengaluru"). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It usefully discloses that this is India-focused geocoding and that results include standardized address details and eLoc codes, but it does not mention limits, edge cases, or any special behavior. The read-only nature of geocoding is reasonably clear from the tool name and description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and captures the resource, geographic scope, and key return values. There is no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with complete schema documentation and an output schema, the description is largely sufficient. The main missing piece is explicit guidance on when to use this instead of closely related location tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters clearly with an example for address and a default for region, so the description adds little beyond restating the output. With 100% schema description coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource — 'Geocode an address or location text' — and names concrete outputs: latitude, longitude, eLoc code, and standardized address details. It does not explicitly contrast with siblings like mappls_autosuggest or mappls_text_search, but the forward-geocoding intent is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through examples like 'Connaught Place, New Delhi', but it never states when to choose this tool over alternatives such as mappls_autosuggest or mappls_text_search. The intended context is inferable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get driving, walking, biking, or trucking navigation directions between origin and destination coordinates/eLocs in India.
| Name | Required | Description | Default |
|---|---|---|---|
| origin | Yes | Start location as "longitude,latitude" or eLoc (e.g. "77.2090,28.6139" or "DEL110"). | |
| profile | No | Transport profile mode: "driving", "biking", "walking", or "trucking". Default is "driving". | driving |
| resource | No | Route resource type: "route_adv", "route_eta", or "route". Default is "route_adv". | route_adv |
| waypoints | No | Optional semicolon-separated intermediate coordinates or eLocs (e.g. "77.25,28.62;77.30,28.63"). | |
| destination | Yes | End location as "longitude,latitude" or eLoc (e.g. "77.3725,28.6273" or "MMI123"). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. It only discloses vehicle modes and India coverage; it does not mention route semantics (e.g., turn-by-turn instructions, traffic/toll behavior), API requirements, or limits. This is a thin behavioral profile for a routing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a tight single sentence that front-loads the action and packs in modes, endpoints, and region. Every word contributes to core meaning; there is no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully documents parameters and an output schema covers return shape, so the minimal description is serviceable. However, it omits sibling differentiation and usage context, and with no annotations the behavioral side is thin, leaving the definition merely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter is already documented in the schema. The description simply restates origin/destination as coordinates/eLocs without adding new meaning, so the schema baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action, 'Get ... navigation directions', and identifies the resource and supported modes (driving/walking/biking/trucking) plus the geographic scope. This makes it distinct from the geocoding/search siblings and from mappls_distance_matrix, which focuses on distance/time rather than routes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but never states when an agent should choose it over mappls_distance_matrix, snap_to_road, or other siblings. There are no exclusions, prerequisites, or route-selection scenarios, leaving the selection decision entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve rich location attributes and details for a location using its 6-character Mappls eLoc code.
| Name | Required | Description | Default |
|---|---|---|---|
| eloc | Yes | The 6-character alphanumeric Mappls eLoc identifier (e.g. "MMI123" or "DEL110"). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 implies a non-destructive read via 'Retrieve', but does not disclose error behavior, invalid eLoc handling, authentication needs, rate limits, or response characteristics. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that states the action, object, and required input format without any filler. Every word contributes meaning and no information is buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup with an output schema, the description is adequate at a basic level, but it lacks sibling differentiation and behavioral context that would help an agent confidently choose and call this tool. It is minimally viable, not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents the eloc parameter with format and examples. The description adds no new parameter semantics beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve'), names the resource ('rich location attributes and details'), and identifies the unique key ('6-character Mappls eLoc code'). This clearly separates it from sibling tools like geocode or reverse_geocode, which use addresses or coordinates instead of eLocs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as mappls_autosuggest or mappls_geocode. The only implied usage is that the caller must have an eLoc, but no explicit conditions or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reverse geocode a pair of geographic coordinates (latitude and longitude) to get the corresponding formatted address and administrative details.
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | The latitude coordinate (e.g. 28.6139). | |
| longitude | Yes | The longitude coordinate (e.g. 77.2090). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It clearly identifies the operation as a read-only lookup ('get') and tells the agent what kind of result to expect: formatted address plus administrative details. It does not describe edge cases or coordinate-system assumptions, but it doe disclose the core behavior without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that starts with the action, names the exact inputs, and states the outcome. There is no filler or repetition; every part of the sentence contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low complexity tool with two fully documented parameters and an existing output schema, the description covers the essential invocation context. The only notable omission is explicit guidance about selecting this tool over its sibling geocoding tools, which is handled separately under usage guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with descriptions and examples, achieving 100% coverage. The description adds no new parameter-level meaning beyond naming latitude and longitude, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Th description clearly states a specific verb-resource action: reverse geocoding coordinate pairs into formatted addresses and administrative details. It is unambiguous about what the tool does, though it does not explicitly contrast itself with the sibling mappls_geocode or other address-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the natural use case: when you have latitude and longitude and need an address. However, it does not explicitly state when to prefer this tool over mappls_geocode, mappls_reverse_geocode sibling alternatives, nor 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.
Search points of interest (POIs) such as restaurants, fuel stations, ATMs, EV chargers, hospitals, hotels near given coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for paginated results (default 1). | |
| radius | No | Search radius in meters (100 to 10000, default 1000). | |
| keywords | Yes | Category or search terms (e.g. "restaurants", "EV charging station", "ATM", "hospital", "fuel pump"). | |
| latitude | Yes | Center search latitude (e.g. 28.6139). | |
| longitude | Yes | Center search longitude (e.g. 77.2090). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses the core behavior: search for POIs around supplied coordinates. With no annotations provided, the description carries the full burden, but it does not disclose pagination behavior, radius constraints, or any auth/rate-limit context beyond what the schema already provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, tightly scoped, with action and object front-loaded. The category examples are useful and concise; there is no fluff or redundant restating of the tool title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter search tool with full schema coverage and an output schema, the description plus structured fields is enough for basic invocation. It lacks explicit sibling-routing guidance, but that is a usage-guidelines concern rather than a blocker to calling this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies. The description's keyword examples roughly mirror those already in the schema and add no new parameter constraints, formats, or relationships beyond what the input schema documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search'), a clear resource ('points of interest'), and the scope ('near given coordinates'), with concrete category examples. This cleanly distinguishes coordinate-based nearby search from sibling tools like geocoding or place details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The coordinate phrase implies this tool is appropriate when the agent has a latitude/longitude and wants nearby POIs. However, it does not explicitly state when not to use it or mention alternatives such as mappls_text_search for text-based queries without coordinates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Snap raw GPS coordinates trace to the nearest road network segments to smooth GPS noise.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | No | Transport mode profile ("driving", "biking", "trucking"). | driving |
| coordinates | Yes | List of GPS coordinate strings ["lng1,lat1", "lng2,lat2", ...]. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. It does state the transformation ('snap to nearest road segments') and the purpose ('smooth GPS noise'), but it does not disclose limitations, edge cases, or behavior differences across transport profiles.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the core operation and purpose with no redundant wording. Every part contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward tool with a fully described schema and an output schema available, the description and schema together provide enough context to invoke the tool correctly. It could be slightly richer, but nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters and their formats. The description adds no additional parameter semantics, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Snap') and names both the input resource ('raw GPS coordinates trace') and the target ('nearest road network segments'). This clearly differentiates it from the geocoding, directions, and search sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied through the description: apply it when you have a noisy raw GPS trace that needs road-network snapping. However, it does not explicitly state when not to use it or mention any alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform smart text search across place entities with auto-correction for spelling variations.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Full text search string (e.g. "Coffee shops near Indiranagar Bangalore"). | |
| location | No | Optional lat,lng string for location biasing (e.g. "12.9716,77.5946"). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden, and it does add one useful trait: auto-correction for spelling variations. It also implies a read-only search over place entities, but it does not disclose ordering, result limits, fallback behavior, or how the optional location bias affects ranking, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no filler or repetition; it front-loads the core action and includes the key behavioral feature. Every word adds value, making it an example of appropriate conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for understanding the basic operation, and the schema plus output schema cover parameters and return structure. However, with eight sibling tools and no mention of how this differs from mappls_autosuggest or mappls_geocode, the definition lacks enough contextual grounding for reliable tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both 'query' and 'location'; the description does not need to repeat parameter details. Baseline 3 applies because the description adds no parameter-specific semantics beyond the general notion of text search already captured by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('perform smart text search') and a clear resource ('place entities'), adding a distinctive feature ('auto-correction for spelling variations'). It does not explicitly differentiate from siblings like mappls_autosuggest or mappls_search_nearby, so it falls short of a 5, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as mappls_autosuggest, mappls_geocode, or mappls_search_nearby. 'Perform smart text search' restates the function rather than providing selection criteria or exclusion conditions, leaving the agent to infer usage context from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0mappls_autosuggestmappls_distance_matrixmappls_geocodemappls_get_directionsmappls_place_detailsmappls_reverse_geocodemappls_search_nearbymappls_snap_to_roadmappls_text_searchScored across 9 tools
Each tool maps to a distinct location API operation: geocoding, reverse geocoding, typeahead suggestions, routing, distance matrix, road snapping, nearby POI search, place details, and text search. The only real overlap is between autosuggest and text_search, but their descriptions clarify the intended use cases.
All tools share a consistent mappls_ prefix and snake_case format. Most names follow a verb-plus-object style like get_directions or search_nearby, though a few are bare nouns such as distance_matrix and place_details, so the pattern is clean but not perfectly uniform.
Nine tools is well-scoped for a location/mapping server. Each tool covers a distinct workflow with no obvious redundancy, and the count is within the ideal range for an MCP toolset.
The server covers the core read-only location lifecycle well: geocode and reverse geocode, place search and details, directions, distance matrix, and map matching. Advanced features like static map rendering or route optimization are absent, but common mapping workflows have no critical gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Geospatial intelligence with Mapbox APIs like geocoding, POI search, directions, isochrones, etc.
Provides AI assistants with direct access to Mapbox developer APIs and documentation.
Geoapify MCP — wraps the Geoapify Location Platform (geoapify.com)
AI access to Mapbox docs, API references, style specs, and guides. No token required.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Bhupendrajee07/MMI-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
