Skip to main content
Glama
Nexauraholding

Services publics

by Nexauraholding
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

adresse_depuis_position

Find nearby addresses from latitude and longitude coordinates to identify locations around a geographic point.

Instructions

Donne lon et lat : tu reçois les adresses proches de cette position. Limite : 50 appels/seconde/IP ; ce connecteur se limite à 40 appels/seconde.

Input Schema

NameRequiredDescriptionDefault
latNoSi searchgeom est utilisé, il s'agit de la latitude du point d'ordonnancement. C'est le point à partir duquel est calculée la distance, puis le score permettant l'ordonnancement des résultats. Dans un soucis de rétro-compatibilité, si searchgeom n'est pas utilisé, il s'agit de la latitude du point de recherche. À partir de ce point, un cercle est créé pour effectuer la recherche. En plus, ce sera aussi la latitude du point d'ordonnancement.
lonNoSi searchgeom est utilisé, il s'agit de la longitude du point d'ordonnancement. C'est le point à partir duquel est calculée la distance, puis le score permettant l'ordonnancement des résultats. Dans un soucis de rétro-compatibilité, si searchgeom n'est pas utilisé, il s'agit de la longitude du point de recherche. À partir de ce point, un cercle est créé pour effectuer la recherche. En plus, ce sera aussi la longitude du point d'ordonnancement.
cityNoFiltre pour les index address et parcel. Il permet de filtrer par nom de commune.
typeNoFiltre pour l'index address. Il permet de filtrer par type de données adresse : numéro de maison, rue, commune, ...
indexNoindex de recherche : - <b>address</b> pour la recherche par adresse - <b>parcel</b> pour la recherche par parcelle cadastrale - <b>poi</b> pour la recherche par lieu et unité administrative Il est possible de spécifier plusieurs indexes séparés par une virgule. Exemples: - /search?index=parcel - /search?index=poi,address address
limitNoNombre maximum de résultats retournés. La valeur ne peut pas dépasser 50. Dans le cas où returntruegeometry est activé, la valeur est automatiquement ramenée à 20.
sheetNoFiltre pour l'index parcel. Il permet de filtrer par feuille.
numberNoFiltre pour l'index parcel. Il permet de filtrer par numéro.
sectionNoFiltre pour l'index parcel. Il permet de filtrer par section.
categoryNoFiltre pour l'index poi. Il permet de filtrer par catégorie de poi. Les valeurs possibles sont listées dans le getCapabilities du service de géocodage. Accepte plusieurs valeurs séparées par des virgules (maximum 10).
citycodeNoFiltre pour les index address et poi. Il permet de filtrer les résultats par code INSEE. Accepte plusieurs valeurs séparées par des virgules (maximum 50).
postcodeNoFiltre pour les index address et poi. Il permet de filtrer les résultats par code postal. Accepte plusieurs valeurs séparées par des virgules (maximum 50).
searchgeomNoGéométrie de recherche. La géométrie est réalisé par intersection géométrique. Si ce paramètre est utilisé seul, c''est que l''on souhaite une recherche sans ordonnancement des résultats (tous les objets intersectant la géométrie de recherche ont un score de 1). Si on veut ordonner les résultats, on peut alors utiliser les paramètres lon et lat pour préciser un point d''ordonnancement. Ce paramètre n''est pas obligatoire pour des raisons de rétro-compatibilité. Si searchgeom n''est pas utilisé alors les paramètres lon et lat doivent l''être et on parle de point de recherche. Lorsque la recherche est réalisée par intersection géométrique. Les types géométrique autorisés sont : - Point - LineString - Polygon - Circle Exemple de géométrie de type Circle : { &nbsp;&nbsp;&nbsp;&nbsp;"type": "Circle", &nbsp;&nbsp;&nbsp;&nbsp;"coordinates": [2.294469, 48.858244], &nbsp;&nbsp;&nbsp;&nbsp;"radius": 100 } Pour l''index <b>address</b>, seules les géométries de type ''Polygon'' et ''Circle'' sont autorisées. Le plus grand côté du rectangle d’emprise de la géométrie ne doit pas excéder 1000 mètres.
districtcodeNoFiltre pour l'index parcel. Il permet de filtrer par code d'arrondissement.
departmentcodeNoFiltre pour l'index parcel. Il permet de filtrer par code de département.
municipalitycodeNoFiltre pour l'index parcel. Il permet de filtrer par code de commune.
returntruegeometryNoindique si la vraie géométrie doit être retournée
oldmunicipalitycodeNoFiltre pour l'index parcel. Il permet de filtrer par code d'ancienne commune.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With zero annotations the description carries the full burden, and it does contribute real behavioral information: the 50 calls/second/IP upstream limit and the connector's self-imposed 40 calls/second ceiling, which an agent cannot infer from the schema. However, it says nothing about what the response contains, whether the configurable index changes the kind of result (address/parcel/poi), or what happens with the default limit of 10.

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?

Two short sentences with no padding, and the core capability is front-loaded before the rate-limit caveat. The first clause is slightly garbled by addressing the reader as the parameter-giver, but nothing is wasted.

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?

This is a complex 18-parameter tool with no annotations and no output schema, yet the description covers only two of the parameters and a rate limit. It omits the index modes (address/parcel/poi), geometry-based search, the result cap interactions, and any hint of the return shape, leaving substantial gaps for an agent that must call it correctly.

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 the 18 parameter descriptions are unusually detailed (including the searchgeom geometry rules and the 1000 m bounding-box cap), so the schema does the heavy lifting. The description only names lon and lat and adds no format or semantics beyond what the schema already states, making baseline 3 correct.

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 phrase "tu reçois les adresses proches de cette position" states a specific resource (nearby addresses) and an implicit operation (reverse geocoding from a point). The verb is framed as an instruction to the caller ("Donne lon et lat") rather than a description of the tool, and it never distinguishes this from the sibling chercher_adresse, but an agent can still tell what comes back.

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?

There is no explicit when-to-use or when-not statement and no reference to the sibling chercher_adresse as the alternative for text-based lookup. The only usage signal is the implied need to supply lon and lat, which the schema already makes evident.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools