2GIS lanza un servidor MCP con 6 herramientas para consultas geográficas de agentes de IA

2GIS ha lanzado un servidor MCP que da a los agentes de IA acceso directo a los geoservicios de la plataforma de API de la compañía. Incluye seis herramientas: búsqueda de lugares y organizaciones, geocodificación directa e inversa, cálculo de rutas, isócronas y mapas estáticos. Junto con el lanzamiento, el equipo ha publicado en Habr un análisis de ingeniería titulado «cómo enseñamos al LLM a no inventar direcciones». El texto explica la arquitectura interna del servidor y los problemas que hubo que resolver antes de llegar a producción.

La parte abierta de la publicación aporta por ahora pocos detalles de implementación: el grueso técnico está oculto tras el «cut» del artículo. Por eso, a continuación solo figura lo que se sabe por el anuncio y el contexto de para qué sirven este tipo de servidores.

Qué obtiene el agente

MCP (Model Context Protocol) es un protocolo abierto para conectar herramientas y datos externos a los modelos de lenguaje. Lo presentó Anthropic a finales de 2024 y se ha convertido en una de las vías habituales para dar a un agente acceso a servicios sin tener que escribir una capa de integración propia para cada cliente. 2GIS ha elegido precisamente este camino para sus API geográficas.

Parámetros clave del lanzamiento:

• Herramientas: 6, cada una construida sobre la API correspondiente de la plataforma de 2GIS.
• Búsqueda: lugares y organizaciones.
• Geocodificación: directa (de dirección a coordenadas) e inversa (de coordenadas a dirección).
• Rutas: cálculo de rutas entre puntos.
• Isócronas: áreas alcanzables en un tiempo determinado.
• Visualización: mapas estáticos.
• Conexión: descrita en la documentación en docs.2gis.com.

El conjunto refleja un escenario típico. El agente encuentra una organización, obtiene sus coordenadas, calcula una ruta, evalúa la zona de accesibilidad y entrega al usuario una imagen.

Por qué la geografía rompe los LLM

Sin herramientas, un modelo responde a una pregunta como «dónde está la farmacia más cercana en tal calle» a partir de estadísticas de textos, no de datos. Las direcciones, los horarios y los nombres de las organizaciones se quedan obsoletos con rapidez. Los mismos topónimos aparecen en ciudades distintas. Las coordenadas son números en los que un error en la quinta cifra decimal ya significa otro patio. Todo ello favorece respuestas seguras, pero inventadas.

Conectar el modelo a un geoservicio en vivo traslada la fuente de verdad de los pesos del modelo a la API. Pero los problemas no desaparecen, sino que se desplazan. El agente debe decidir cuál de las seis herramientas invocar.

Tiene que pasar los parámetros en el formato correcto y no perder el resultado entre pasos. La dificultad está en los contratos de las herramientas: los nombres, las descripciones, los esquemas de argumentos y el formato de respuesta influyen directamente en que el modelo las llame correctamente. Los autores afirman que de eso trata precisamente su artículo: de los errores en el cruce entre los LLM y los datos geográficos y de lo que hubo que corregir antes de pasar a producción.

A quién le sirve en la práctica

Los desarrolladores que construyen agentes con lógica geográfica (servicios de reparto, retail, inmobiliaria, turismo, asistentes internos) ya no necesitan escribir wrappers sobre las API cartográficas. Basta con conectar el servidor MCP ya hecho a un cliente compatible y comprobar cómo se desenvuelve el modelo en sus escenarios.

Para quienes crean su propio servidor MCP o herramientas para function calling, el mayor valor está en el propio artículo. Qué conviene comprobar ya:

• Cómo elige el modelo la herramienta cuando una consulta se puede resolver de dos maneras, por ejemplo con búsqueda o con geocodificación.
• Qué ocurre ante una dirección ambigua o un resultado vacío: si el agente lo comunica con honestidad o inventa una respuesta verosímil.
• Hasta qué punto el formato de respuesta de la herramienta es cómodo para el modelo, y no solo para una persona.

Que un actor cartográfico de este tamaño tenga un servidor así indica hacia dónde va el mercado. Los datos de la compañía pasan a estar al alcance de los agentes no a través de una interfaz web, sino de un protocolo estandarizado. Para los geoservicios, es un canal más de distribución de su API.