Skip to main content
Glama
julienkalamon

IGN API Carto MCP Server

Query WFS Geoportail layers

ign_wfs_geoportail
Read-onlyIdempotent

Query French geographic WFS layers by intersecting with a geometry to retrieve spatial data like communes, buildings, or administrative boundaries in GeoJSON format.

Instructions

Generic query interface for Geoportail WFS layers.

This tool provides access to various WFS layers from the IGN Geoportail. It allows querying any WFS layer by intersection with a geometry.

Args:

  • source (string): WFS data source name (e.g., "BDTOPO_V3:commune", "LIMITES_ADMINISTRATIVES_EXPRESS.LATEST:commune")

  • geom (string): GeoJSON geometry to intersect (required, in WGS84/EPSG:4326)

  • _limit (number): Max results (1-1000)

  • _start (number): Pagination offset

Returns: GeoJSON FeatureCollection with features from the requested layer.

Note: Only WGS84 (EPSG:4326) geometries are supported.

Examples:

  • "Get BDTOPO communes at this point" -> source="BDTOPO_V3:commune", geom={"type":"Point","coordinates":[2.35,48.85]}

  • "Find buildings in this area" -> source="BDTOPO_V3:batiment", geom=...

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourceYesWFS data source name (e.g., 'BDTOPO_V3:commune')
geomYesGeoJSON geometry (required, in WGS84/EPSG:4326)
_limitNoMaximum number of results (1-1000)
_startNoStarting position for pagination
response_formatNoOutput format: 'markdown' for human-readable or 'json' for machine-readablemarkdown

Implementation Reference

  • Handler function that processes input parameters, queries the external WFS Geoportail API endpoint via apiRequest, and returns formatted GeoJSON response as JSON or Markdown.
    async (params) => {
      const { source, response_format, ...queryParams } = params;
    
      const data = await apiRequest<unknown>("/wfs-geoportail/search", {
        params: {
          source,
          ...queryParams
        } as Record<string, string | number | boolean | undefined>,
      });
    
      if (response_format === ResponseFormat.JSON) {
        return {
          content: [{ type: "text", text: JSON.stringify(data, null, 2) }],
        };
      }
    
      const markdown = formatGeoJSONToMarkdown(
        data as import("./types.js").GeoJSONFeatureCollection,
        `WFS Geoportail - ${source}`
      );
      return {
        content: [{ type: "text", text: truncateResponse(markdown, CHARACTER_LIMIT) }],
      };
    }
  • Zod input schema defining parameters: source (WFS layer), geom (GeoJSON), pagination (_limit, _start), and response_format.
    inputSchema: z.object({
      source: z.string().describe("WFS data source name (e.g., 'BDTOPO_V3:commune')"),
      geom: GeometrySchema.describe("GeoJSON geometry (required, in WGS84/EPSG:4326)"),
      ...PaginationSchema,
      response_format: ResponseFormatSchema,
    }).strict(),
  • src/index.ts:581-640 (registration)
    Registers the 'ign_wfs_geoportail' MCP tool with metadata, schema, and inline handler function.
    server.registerTool(
      "ign_wfs_geoportail",
      {
        title: "Query WFS Geoportail layers",
        description: `Generic query interface for Geoportail WFS layers.
    
    This tool provides access to various WFS layers from the IGN Geoportail. It allows querying any WFS layer by intersection with a geometry.
    
    Args:
      - source (string): WFS data source name (e.g., "BDTOPO_V3:commune", "LIMITES_ADMINISTRATIVES_EXPRESS.LATEST:commune")
      - geom (string): GeoJSON geometry to intersect (required, in WGS84/EPSG:4326)
      - _limit (number): Max results (1-1000)
      - _start (number): Pagination offset
    
    Returns:
      GeoJSON FeatureCollection with features from the requested layer.
    
    Note: Only WGS84 (EPSG:4326) geometries are supported.
    
    Examples:
      - "Get BDTOPO communes at this point" -> source="BDTOPO_V3:commune", geom={"type":"Point","coordinates":[2.35,48.85]}
      - "Find buildings in this area" -> source="BDTOPO_V3:batiment", geom=...`,
        inputSchema: z.object({
          source: z.string().describe("WFS data source name (e.g., 'BDTOPO_V3:commune')"),
          geom: GeometrySchema.describe("GeoJSON geometry (required, in WGS84/EPSG:4326)"),
          ...PaginationSchema,
          response_format: ResponseFormatSchema,
        }).strict(),
        annotations: {
          readOnlyHint: true,
          destructiveHint: false,
          idempotentHint: true,
          openWorldHint: true,
        },
      },
      async (params) => {
        const { source, response_format, ...queryParams } = params;
    
        const data = await apiRequest<unknown>("/wfs-geoportail/search", {
          params: {
            source,
            ...queryParams
          } as Record<string, string | number | boolean | undefined>,
        });
    
        if (response_format === ResponseFormat.JSON) {
          return {
            content: [{ type: "text", text: JSON.stringify(data, null, 2) }],
          };
        }
    
        const markdown = formatGeoJSONToMarkdown(
          data as import("./types.js").GeoJSONFeatureCollection,
          `WFS Geoportail - ${source}`
        );
        return {
          content: [{ type: "text", text: truncateResponse(markdown, CHARACTER_LIMIT) }],
        };
      }
    );
Behavior4/5

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

The description adds valuable behavioral context beyond annotations: it specifies the coordinate system limitation ('Only WGS84 geometries are supported'), describes the return format ('GeoJSON FeatureCollection'), and provides practical examples. While annotations cover safety (readOnly, non-destructive), the description adds implementation details that help the agent use the tool correctly.

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?

The description is well-structured with clear sections (purpose, args, returns, notes, examples) and front-loads the core functionality. While comprehensive, some redundancy exists between the description and schema (e.g., parameter descriptions), making it slightly less concise than ideal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a query tool with comprehensive annotations (readOnly, openWorld, idempotent) and full schema coverage, the description provides excellent contextual completeness. It explains the tool's generic nature, coordinate system constraints, return format, and includes practical examples - giving the agent everything needed to use this tool effectively.

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?

With 100% schema description coverage, the baseline is 3. The description adds minimal additional parameter semantics beyond what's in the schema - it repeats the source and geom descriptions and provides examples, but doesn't significantly enhance understanding of parameter usage or relationships.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose as a 'generic query interface for Geoportail WFS layers' that 'allows querying any WFS layer by intersection with a geometry.' It distinguishes itself from sibling tools by being generic rather than specific to particular datasets like administrative limits or cadastre parcels.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool ('querying any WFS layer by intersection with a geometry') and includes a note about coordinate system limitations. However, it doesn't explicitly state when NOT to use it or provide direct alternatives among the sibling tools for specific use cases.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/julienkalamon/ign-apicarto-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server