2GIS Releases MCP Server with 6 Tools for AI Agent Geo Queries

2GIS has released an MCP server that gives AI agents direct access to the geoservices of the company's API platform. It includes six tools: search for places and organizations, forward and reverse geocoding, route building, isochrones and static maps. Alongside the release, the team published an engineering write-up on Habr titled "how we taught an LLM not to make up addresses." It describes the server's internal design and the problems the team had to solve before going to production.

The publicly visible part of the post has few implementation details so far: the main technical section is behind a cut. So below is only what is known from the announcement, plus context on why such servers are needed.

What the agent gets

MCP (Model Context Protocol) is an open protocol for connecting external tools and data to language models. Anthropic introduced it in late 2024. It has become one of the standard ways to give an agent access to services without writing custom glue code for each client. 2GIS chose exactly this route for its geo APIs.

Key parameters of the release:

• Tools: 6, each built on top of the corresponding 2GIS platform API.
• Search: places and organizations.
• Geocoding: forward (address to coordinates) and reverse (coordinates to address).
• Routing: building routes between points.
• Isochrones: areas reachable within a given time.
• Visualization: static maps.
• Connection: described in the documentation at docs.2gis.com.

The set reflects a typical scenario. The agent finds an organization, gets its coordinates, builds a route, estimates the accessibility zone and hands the user an image.

Why geography breaks LLMs

Without tools, a model answers a question like "where is the nearest pharmacy on such-and-such street" based on text statistics, not data. Addresses, opening hours and organization names go out of date quickly. Identical place names appear in different cities. Coordinates are numbers where an error in the fifth decimal place already means a different courtyard. All of this invites confident but fabricated answers.

Connecting to a live geoservice moves the source of truth from the model's weights to an API. But the problems do not disappear; they shift. The agent has to work out which of the six tools to call. It has to pass parameters in the right format and not lose the result between steps. The difficulty lies in the tool contracts: names, descriptions, argument schemas and response format directly affect whether the model calls them correctly. The authors say this is exactly what their article is about: errors at the intersection of LLMs and geodata, and what had to be fixed before going to production.

Who will find this useful in practice

Developers building agents with geo logic (delivery services, retail, real estate, tourism, internal assistants) no longer need to write wrappers around mapping APIs. It is enough to connect the ready-made MCP server to a compatible client and check how the model handles their scenarios.

For those building their own MCP server or tools for function calling, the main value is in the article itself. Things worth checking now:

• How the model picks a tool when a request can be solved in two ways, for example with search or with geocoding.
• What happens with an ambiguous address or an empty result: whether the agent says so honestly or substitutes a plausible answer.
• How convenient the tool's response format is for the model, not just for a human.

The very fact that a major mapping player now has such a server shows where the market is heading. A company's data becomes available to agents not through a web interface but through a standardized protocol. For geoservices, it is one more distribution channel for their API.