2GIS lance un serveur MCP à 6 outils pour les requêtes géographiques des agents IA

2GIS a lancé un serveur MCP qui donne aux agents IA un accès direct aux services géographiques de la plateforme d'API de l'entreprise. Il embarque six outils : recherche de lieux et d'organisations, géocodage direct et inverse, calcul d'itinéraires, isochrones et cartes statiques. En parallèle de cette sortie, l'équipe a publié sur Habr une analyse technique intitulée « comment nous avons appris au LLM à ne pas inventer d'adresses ». Le texte décrit le fonctionnement interne du serveur et les problèmes à résoudre avant le passage en production.

Dans la partie accessible de la publication, les détails d'implémentation restent pour l'instant rares : l'essentiel du contenu technique se trouve sous le « cut » (la partie repliée). Cet article se limite donc à ce que l'on sait de l'annonce, et au contexte qui explique l'intérêt de tels serveurs.

Ce que reçoit l'agent

MCP (Model Context Protocol) est un protocole ouvert pour connecter des outils et des données externes aux modèles de langage. Anthropic l'a présenté fin 2024. Il est devenu l'une des méthodes standard pour donner à un agent l'accès à des services, sans développer une couche d'intégration maison pour chaque client. 2GIS a choisi cette voie pour ses API géographiques.

Principales caractéristiques de la sortie :

• Outils : 6, chacun construit au-dessus de l'API correspondante de la plateforme 2GIS.
• Recherche : lieux et organisations.
• Géocodage : direct (adresse vers coordonnées) et inverse (coordonnées vers adresse).
• Itinéraires : calcul de trajets entre des points.
• Isochrones : zones atteignables en un temps donné.
• Visualisation : cartes statiques.
• Connexion : décrite dans la documentation sur docs.2gis.com.

Cet ensemble illustre un scénario typique. L'agent trouve une organisation, récupère ses coordonnées, calcule un itinéraire, évalue la zone d'accessibilité et renvoie une image à l'utilisateur.

Pourquoi la géographie met les LLM en difficulté

Sans outils, un modèle répond à une question comme « où se trouve la pharmacie la plus proche, rue X » à partir de statistiques textuelles, et non de données. Les adresses, les horaires d'ouverture et les noms d'organisations deviennent vite obsolètes. Des toponymes identiques existent dans des villes différentes. Les coordonnées sont des nombres pour lesquels une erreur à la cinquième décimale désigne déjà une autre cour d'immeuble. Tout cela favorise des réponses assurées, mais inventées.

Connecter le modèle à un service géographique en temps réel déplace la source de vérité : elle ne réside plus dans les poids du modèle, mais dans l'API. Les problèmes ne disparaissent pas pour autant, ils se déplacent. L'agent doit déterminer lequel des six outils appeler. Il doit transmettre les paramètres au bon format et ne pas perdre un résultat entre deux étapes. La difficulté tient aux contrats des outils : noms, descriptions, schémas d'arguments et format de réponse déterminent directement si le modèle les appelle correctement. Les auteurs affirment que c'est précisément le sujet de leur article : les erreurs à la jonction entre LLM et géodonnées, et ce qu'il a fallu corriger avant la mise en production.

À qui cela sert concrètement

Les développeurs qui construisent des agents dotés d'une logique géographique (livraison, commerce, immobilier, tourisme, assistants internes) n'ont désormais plus besoin d'écrire des wrappers autour des API cartographiques. Il suffit de brancher le serveur MCP prêt à l'emploi à un client compatible et de vérifier comment le modèle gère les scénarios.

Pour ceux qui développent leur propre serveur MCP ou des outils pour le function calling, l'essentiel de la valeur se trouve dans l'article lui-même. Voici ce qu'il vaut la peine de tester dès maintenant :

• Comment le modèle choisit un outil quand une requête peut se résoudre de deux façons, par exemple par la recherche ou par le géocodage.
• Ce qui se passe face à une adresse ambiguë ou à un résultat vide : l'agent le signale honnêtement, ou il fournit une réponse plausible.
• Dans quelle mesure le format de réponse de l'outil est adapté au modèle, et pas seulement à l'humain.

L'arrivée d'un tel serveur chez un grand acteur de la cartographie montre la direction que prend le marché. Les données de l'entreprise deviennent accessibles aux agents non pas via une interface web, mais via un protocole standardisé. Pour les services géographiques, c'est un canal de diffusion supplémentaire pour leurs API.