Skip to main content
Glama
deenesjakoruzh
datagouv

datagouv-mcp

by datagouv
OverviewSchemaRelated ServersScoreDiscussions
Python

data.gouv.fr MCP Server

TIP

Got feedback?Tell us about it here

CircleCI License: MIT

Model Context Protocol (MCP) server that allows AI chatbots (Claude, ChatGPT, Gemini, etc.) to search, explore, and analyze datasets from data.gouv.fr, the French national Open Data platform, directly through conversation.

Instead of manually browsing the website, you can simply ask questions like "Quels jeux de données sont disponibles sur les prix de l'immobilier ?" or "Montre-moi les dernières données de population pour Paris" and get instant answers.

TIP

Use it now: A public instance is available for everyone athttps://mcp.data.gouv.fr/mcp with no access restrictions. To connect your favorite chatbot, simply follow the connection instructions below.

🌐 Connect your chatbot to the MCP server

Use the hosted endpoint https://mcp.data.gouv.fr/mcp (recommended). If you self-host, swap in your own URL.

The MCP server configuration depends on your client. Use the appropriate configuration format for your client:

AnythingLLM | Autohand Code | ChatGPT | Claude Code | Claude Desktop | Cursor | Gemini CLI | HuggingChat | IBM Bob | Kiro CLI | Kiro IDE | Le Chat (Mistral) | Mistral Vibe | OpenCode | VS Code | Windsurf

AnythingLLM

  1. Locate the anythingllm_mcp_servers.json file in your AnythingLLM storage plugins directory:

    • Linux: ~/.config/anythingllm-desktop/storage/plugins/anythingllm_mcp_servers.json

    • MacOS: ~/Library/Application Support/anythingllm-desktop/storage/plugins/anythingllm_mcp_servers.json

    • Windows: C:\Users\<username>\AppData\Roaming\anythingllm-desktop\storage\plugins\anythingllm_mcp_servers.json

  2. Add the following configuration:

{
  "mcpServers": {
    "datagouv": {
      "type": "streamable",
      "url": "https://mcp.data.gouv.fr/mcp"
    }
  }
}

For more details, see the AnythingLLM MCP documentation.

Autohand Code

Use the Autohand Code CLI to register the hosted endpoint:

autohand mcp add --transport http datagouv https://mcp.data.gouv.fr/mcp

Add --scope project to keep the registration in the current workspace.

ChatGPT

Available for paid plans only (Plus, Pro, Team, and Enterprise).

  1. Access Settings: Open ChatGPT in your browser, go to Settings, then Apps and connectors.

  2. Enable Dev Mode: Open Advanced settings and enable Developer mode.

  3. Add Connector: Return to Settings > Connectors > Browse connectors and click Add a new connector.

  4. Configure the connector: Set the URL to https://mcp.data.gouv.fr/mcp and save to activate the tools.

Claude Code

Use the claude mcp command to add the MCP server:

claude mcp add --transport http datagouv https://mcp.data.gouv.fr/mcp

Claude Desktop

Add the following to your Claude Desktop configuration file (typically ~/.config/Claude/claude_desktop_config.json on Linux, ~/Library/Application Support/Claude/claude_desktop_config.json on MacOS, or %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "datagouv": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://mcp.data.gouv.fr/mcp"
      ]
    }
  }
}

Claude Desktop on Windows: If the server appears in the list but never connects (no handshake, tools missing), Claude may be using its built-in Node.js runtime, which does not see packages installed with your system npm (including a global mcp-remote). Set isUsingBuiltInNodeForMcp to false at the root of the same config file so npx uses your installed Node — then restart Claude Desktop:

{
  "isUsingBuiltInNodeForMcp": false,
  "mcpServers": {
    "datagouv": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://mcp.data.gouv.fr/mcp"
      ]
    }
  }
}

See issue #69 for background.

Cursor

Cursor supports MCP servers through its settings. To configure the server:

  1. Open Cursor Settings

  2. Search for "MCP" or "Model Context Protocol"

  3. Add a new MCP server with the following configuration:

{
  "mcpServers": {
    "datagouv": {
      "url": "https://mcp.data.gouv.fr/mcp",
      "transport": "http"
    }
  }
}

Gemini CLI

Add the following to your ~/.gemini/settings.json file (Linux: ~/.gemini/settings.json, MacOS: ~/.gemini/settings.json, Windows: %USERPROFILE%\.gemini\settings.json):

{
  "mcpServers": {
    "datagouv": {
      "httpUrl": "https://mcp.data.gouv.fr/mcp"
    }
  }
}

HuggingChat

  1. Access Settings: In the chat interface, click the + icon, select MCP Servers, and click Manage MCP Servers.

  2. Add Server: Click the + Add Server button in the server management window.

  3. Configure the Server: Enter a Server Name (e.g., "Data Gouv") and set the Server URL to https://mcp.data.gouv.fr/mcp. Click Add Server to save.

  4. Verify Connection: Click the Health Check button on the new server card to confirm it displays as Connected. Ensure the toggle is activated to use the tools in your chat.

IBM Bob

IBM Bob supports MCP servers through its settings. To configure the server:

  1. Click the setting icon in the Bob panel.

  2. Select the MCP tab.

  3. Click the appropriate button:

  • Edit Global MCP: Opens the global mcp_settings.json file

  • Edit Project MCP: Opens the project-specific .bob/mcp.json file (Bob creates it if it does not exist)

Both files use JSON format with an mcpServers object containing named server configurations.

{
  "mcpServers": {
    "datagouv": {
      "url": "https://mcp.data.gouv.fr/mcp",
      "type": "streamable-http"
    }
  }
}

Kiro CLI

Add the following to ~/.kiro/settings/mcp.json (Linux: ~/.kiro/settings/mcp.json, MacOS: ~/.kiro/settings/mcp.json, Windows: %USERPROFILE%\.kiro\settings\mcp.json):

{
  "mcpServers": {
    "datagouv": {
      "url": "https://mcp.data.gouv.fr/mcp"
    }
  }
}

Kiro IDE

Add the following to your Kiro MCP configuration file (.kiro/settings/mcp.json in your workspace, or for global config: Linux: ~/.kiro/settings/mcp.json, MacOS: ~/.kiro/settings/mcp.json, Windows: %USERPROFILE%\.kiro\settings\mcp.json):

{
  "mcpServers": {
    "datagouv": {
      "url": "https://mcp.data.gouv.fr/mcp"
    }
  }
}

Le Chat (Mistral)

Available on all plans, including free.

  1. Go to Connectors: Open Mistral in your browser, then go to Intelligence > Connectors.

  2. Add a custom connector: Click Add connector > Custom MCP Connector, give it a name (for example DataGouv), and set the server URL to https://mcp.data.gouv.fr/mcp.

  3. No authentication: Leave authentication disabled.

  4. Create: Click Create.

Mistral Vibe CLI

Edit your Vibe config (default: Linux: ~/.vibe/config.toml, MacOS: ~/.vibe/config.toml, Windows: %USERPROFILE%\.vibe\config.toml) and add the MCP server:

[[mcp_servers]]
name = "datagouv"
transport = "streamable-http"
url = "https://mcp.data.gouv.fr/mcp"

See the full Vibe MCP options in the official docs: MCP server configuration.

OpenCode

Add to opencode.json (e.g. ~/.config/opencode/opencode.json or your project root). Remote servers use the top-level mcp object with type: "remote". See OpenCode MCP servers.

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "datagouv": {
      "type": "remote",
      "url": "https://mcp.data.gouv.fr/mcp",
      "enabled": true
    }
  }
}

VS Code

Add the following to your VS Code mcp.json file (Linux: ~/.config/Code/User/mcp.json, MacOS: ~/Library/Application Support/Code/User/mcp.json, Windows: %APPDATA%\Code\User\mcp.json). Run MCP: Open User Configuration from the Command Palette to open it.

{
  "servers": {
    "datagouv": {
      "url": "https://mcp.data.gouv.fr/mcp",
      "type": "http"
    }
  }
}

Windsurf

Add the following to your ~/.codeium/windsurf/mcp_config.json (Linux: ~/.codeium/windsurf/mcp_config.json, MacOS: ~/.codeium/windsurf/mcp_config.json, Windows: %USERPROFILE%\.codeium\windsurf\mcp_config.json):

{
  "mcpServers": {
    "datagouv": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.data.gouv.fr/mcp"
      ]
    }
  }
}

Note:

  • The hosted endpoint is https://mcp.data.gouv.fr/mcp. If you run the server yourself, replace it with your own URL (see “Run locally” below for the default local endpoint).

  • This MCP server only exposes read-only tools for now, so no API key is required.

Related MCP server: mcp-gouv-fr

🖥️ Run locally

1. Run the MCP server

Before starting, clone this repository and browse into it:

git clone git@github.com:datagouv/datagouv-mcp.git
cd datagouv-mcp

Docker is required for the recommended setup. Install it via Docker Desktop or any compatible Docker Engine before continuing.

🐳 With Docker (Recommended)

# With default settings (port 8000, prod environment)
docker compose up -d

# With custom environment variables
MCP_PORT=8007 DATAGOUV_API_ENV=demo LOG_LEVEL=DEBUG docker compose up -d

# Stop
docker compose down

Environment variables:

  • MCP_HOST: host to bind to (defaults to 0.0.0.0). Set to 127.0.0.1 for local development to follow MCP security best practices.

  • MCP_PORT: port for the MCP HTTP server (defaults to 8000 when unset).

  • MCP_ENV: environment name reported to Sentry (defaults to local when unset). Set explicitly to prod, preprod, or demo in your deployment.

  • DATAGOUV_API_ENV: prod (default) or demo. This controls which data.gouv.fr environement it uses the data from (https://www.data.gouv.fr or https://demo.data.gouv.fr). By default the MCP server talks to the production data.gouv.fr. Set DATAGOUV_API_ENV=demo if you specifically need the demo environment.

  • LOG_LEVEL: Python logging level for the application (defaults to INFO). Common values: DEBUG, INFO, WARNING, ERROR, CRITICAL.

  • SENTRY_DSN: Sentry DSN to enable error and performance monitoring. Monitoring is disabled when unset.

  • SENTRY_SAMPLE_RATE: sampling rate for Sentry traces and profiles (float 0.0–1.0, defaults to 1.0).

⚙️ Manual Installation

You will need uv to install dependencies and run the server.

  1. Install dependencies

uv sync

  1. Prepare the environment file

Copy the example environment file to create your own .env file:

cp .env.example .env

Then optionally edit .env and set the variables that matter for your run:

MCP_HOST=127.0.0.1  # (defaults to 0.0.0.0, use 127.0.0.1 for local dev)
MCP_PORT=8007  # (defaults to 8000 when unset)
MCP_ENV=local  # environment name sent to Sentry (defaults to local when unset)
DATAGOUV_API_ENV=prod  # Allowed values: demo | prod (defaults to prod when unset)
LOG_LEVEL=INFO  # Python log level (default: INFO)

Load the variables with your preferred method, e.g.:

set -a && source .env && set +a

  1. Start the HTTP MCP server

uv run main.py

2. Connect your chatbot to the local MCP server

Follow the steps in Connect your chatbot to the MCP server and simply swap the hosted URL for your local endpoint (default: http://127.0.0.1:${MCP_PORT:-8000}/mcp).

🚚 Transport support

The MCP server is built using the official Python SDK for MCP servers and clients and uses the Streamable HTTP transport only.

STDIO and SSE are not supported.

📋 Available Endpoints

Streamable HTTP transport (standards-compliant):

  • POST /mcp - JSON-RPC messages (client → server)

  • GET /health - Health check endpoint: runs search_datasets in-process (no recursive HTTP call). Returns {"status":"ok",...} with HTTP 200 if healthy, or {"status":"mcp_unavailable"} with HTTP 503 if the MCP stack is not responding correctly.

🛠️ Available Tools

The MCP server provides tools to interact with data.gouv.fr datasets and third-party APIs cataloged on the platform.

Note: data.gouv.fr exposes these third-party APIs (e.g., Adresse API, Sirene API) over HTTP under the dataservices resource paths; that is separate from data.gouv.fr's own internal APIs (Main/Tabular/Metrics) that power this MCP server.

Datasets (static data files)

  • search_datasets - Search for datasets by keywords. Returns datasets with metadata (title, description, organization, tags, resource count).

    Parameters: query (required), page (optional, default: 1), page_size (optional, default: 20, max: 100)

  • search_organizations - List or search publishing organizations on data.gouv.fr. Returns trimmed rows (id, name, slug, acronym, badges, metrics, URLs).

    Parameters: query (optional; AND-style keyword search; omit or leave empty to browse), page (optional, default: 1), page_size (optional, default: 20, max: 100), sort (optional; e.g. datasets, -datasets), badge (optional; e.g. public-service, certified, association, company, local-authority), name (optional, exact name filter), business_number_id (optional).

  • get_dataset_info - Get detailed information about a specific dataset (metadata, organization, tags, dates, license, etc.).

    Parameters: dataset_id (required)

  • list_dataset_resources - List all resources (files) in a dataset with their metadata (format, size, type, URL).

    Parameters: dataset_id (required)

  • get_resource_info - Get detailed information about a specific resource (format, size, MIME type, URL, dataset association, Tabular API availability).

    Parameters: resource_id (required)

  • query_resource_data - Query data from a specific resource via the Tabular API. Fetches rows from a resource to answer questions.

    Parameters: resource_id (required), page (optional, default: 1), page_size (optional, default: 20, max: 200)

    Note: Recommended workflow: 1) Use search_datasets to find the dataset, 2) Use list_dataset_resources to see available resources, 3) Use query_resource_data with default page_size (20) to preview data structure. For small datasets (<500 rows), increase page_size or paginate. For large datasets (>1000 rows), continue paginating or use get_resource_info to retrieve the raw file URL and fetch it directly. Works for CSV/XLS resources within Tabular API size limits (CSV ≤ 100 MB, XLSX ≤ 12.5 MB).

Third-party APIs

These tools use data.gouv.fr HTTP paths under dataservices; tool and parameter names match that API (search_dataservices, dataservice_id).

  • search_dataservices - Search for third-party APIs cataloged on data.gouv.fr by keywords. Returns entries with metadata (title, description, organization, base API URL, tags).

    Parameters: query (required), page (optional, default: 1), page_size (optional, default: 20, max: 100)

  • get_dataservice_info - Get detailed metadata for one third-party API (title, description, organization, base API URL, OpenAPI spec URL, license, dates, related datasets).

    Parameters: dataservice_id (required) — same as in the data.gouv.fr API and as the id from search results.

  • get_dataservice_openapi_spec - Fetch and summarize the OpenAPI/Swagger specification for a third-party API. Returns a concise overview of available endpoints with their parameters.

    Parameters: dataservice_id (required)

    Note: Recommended workflow: 1) Use search_dataservices to find the API, 2) Use get_dataservice_info for metadata and documentation URL, 3) Use get_dataservice_openapi_spec for endpoints and parameters, 4) Call the API using the base_api_url per the spec.

Metrics

  • get_metrics - Get metrics (visits, downloads) for a dataset and/or a resource.

    Parameters: dataset_id (optional), resource_id (optional), limit (optional, default: 12, max: 100)

    Returns monthly statistics including visits and downloads, sorted by month in descending order (most recent first). At least one of dataset_id or resource_id must be provided. Note: This tool only works with the production environment (DATAGOUV_API_ENV=prod). The Metrics API does not have a demo/preprod environment.

🧪 Tests

✅ Automated Tests with pytest

Run the tests with pytest (these cover helper modules; the MCP server wiring is best exercised via the MCP Inspector):

# Run all tests
uv run pytest

# Run with verbose output
uv run pytest -v

# Run specific test file
uv run pytest tests/test_tabular_api.py

# Run with custom resource ID
RESOURCE_ID=3b6b2281-b9d9-4959-ae9d-c2c166dff118 uv run pytest tests/test_tabular_api.py

# Run with prod environment
DATAGOUV_API_ENV=prod uv run pytest

🔥 Stress Tests

Stress tests send many concurrent requests against a running MCP server. They require a running server and make real HTTP requests, so they are excluded from default pytest runs.

# Start the server first, then in another terminal:
uv run pytest -m stress

Currently includes a test that mixes normal requests with abrupt client TCP disconnects, verifying the server stays healthy and keeps serving despite the disruption. It uses MCP_PORT (default: 8000) to connect to the local server.

🩺 Run a Health Check from the CLI

Runs search_datasets in-process to validate end-to-end stack health (tool layer + data.gouv.fr API). Requires network access to data.gouv.fr. Excluded from default pytest runs.

uv run pytest -m health_check

🛠️ Local Tool Testing Script

scripts/call_tool.py lets you call any MCP tool directly without manually managing the curl handshake. Requires a running server.

# Start the server first, then in another terminal:
python scripts/call_tool.py search_datasets '{"query": "IRVE"}'
python scripts/call_tool.py get_resource_info '{"resource_id": "<id>"}'

🔍 Interactive Testing with MCP Inspector

Use the official MCP Inspector to interactively test the server tools and resources.

Prerequisites:

  • Node.js with npx available

Steps:

  1. Start the MCP server (see above)

  2. In another terminal, launch the inspector:

    npx @modelcontextprotocol/inspector --http-url "http://127.0.0.1:${MCP_PORT}/mcp"

    Adjust the URL if you exposed the server on another host/port.

🤝 Contributing

We welcome contributions! To keep the project stable and reviews manageable, please observe these rules before submitting:

  • Human review and accountability: Issues and pull requests must not be raw, unreviewed AI output. You must have read, fully understood, and (for code) tested what you submit. By opening an issue or a pull request, you certify you could explain and defend it in review without relying on an AI assistant.

  • Keep it small: We strictly follow a 1 feature = 1 PR workflow.

  • Conventional commits: Use the Conventional Commits format for git commit messages and PR titles (e.g. feat: add dataset search, fix: handle empty API response). See the specification for allowed types, scopes, and breaking-change markers.

We use a standard review-and-deploy process:

  1. Submit a PR: Propose your changes via a Pull Request against the main branch.

  2. Continuous integration: CI runs automatically on the pull request. All required checks must pass before the PR can be merged (tests, linting, formatting, and type checking). Run the same checks locally—tests per Tests, and lint/format/type via Code linting and formatting or the pre-commit hook—to avoid surprise CI failures.

  3. Review: All PRs must be reviewed and approved by a maintainer before merging.

  4. Deployment process: Once merged into main, maintainers deploy changes periodically to pre-production for more tests and validation before wider release.

🧹 Code Linting and Formatting

This project follows PEP 8 style guidelines using Ruff for linting and formatting, and ty for type checking.

Either running these commands manually or installing the pre-commit hook is required before submitting contributions.

# Lint (including import sorting) and format code
uv run ruff check --fix && uv run ruff format

# Type check (ty)
uv run ty check

🔗 Pre-commit Hooks

This repository uses a pre-commit hook which lint and format code before each commit. Installing the pre-commit hook is strongly recommended so the checks run automatically.

Install pre-commit hooks:

uv run pre-commit install

The pre-commit hook that automatically:

  • Check YAML syntax

  • Fix end-of-file issues

  • Remove trailing whitespace

  • Check for large files

  • Run Ruff linting and formatting

🏷️ Releases and versioning

The release process uses the tag_version.sh script to create git tags, GitHub releases and update CHANGELOG.md automatically. Package version numbers are automatically derived from git tags using setuptools_scm, so no manual version updates are needed in pyproject.toml.

Prerequisites: GitHub CLI must be installed and authenticated, and you must be on the main branch with a clean working directory.

# Create a new release
./tag_version.sh <version>

# Example
./tag_version.sh 2.5.0

# Dry run to see what would happen
./tag_version.sh 2.5.0 --dry-run

The script automatically:

  • Extracts commits since the last tag and formats them for CHANGELOG.md

  • Identifies breaking changes (commits with !: in the subject)

  • Creates a git tag and pushes it to the remote repository

  • Creates a GitHub release with the changelog content

📄 License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

6 tools
get_dataservice_openapi_specGet third-party API OpenAPI specA
Read-onlyIdempotent

Fetch and summarize the OpenAPI/Swagger spec for a third-party API (dataservice).

Retrieves machine_documentation_url from catalog metadata (dataservice record), fetches the spec, and returns a summary of available endpoints with their parameters. Use this to understand how to call the API.

Typical workflow: search_dataservices → get_dataservice_info → get_dataservice_openapi_spec → call the API using base_api_url per spec.

ParametersJSON Schema
NameRequiredDescriptionDefault
dataservice_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds valuable process details: retrieving machine_documentation_url from catalog metadata, fetching the spec, and returning a summary. It does not contradict annotations and provides context beyond the structured fields. Missing potential edge cases or error conditions, but still good.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise paragraphs with no fluff. The first sentence immediately states the main action. It front-loads the purpose and provides a workflow, making it easy to parse. Every sentence adds value.

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

Completeness4/5

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

Given that an output schema exists, the description does not need to detail return values. It adequately explains the tool's role in a multi-step workflow. However, it could mention that the spec is fetched from an external URL, which might have latency or availability implications. Overall sufficient for the complexity.

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?

The only parameter dataservice_id has 0% schema description coverage. The description indirectly explains its role by mentioning 'dataservice record' and 'catalog metadata', implying it identifies the dataservice. However, it does not explicitly describe the parameter's type, format, or how to obtain valid IDs, leaving the agent to infer. Since schema coverage is low, the description should do more.

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 it fetches and summarizes the OpenAPI/Swagger spec for a third-party API (dataservice). The verb 'fetch and summarize' and specific resource 'third-party API OpenAPI spec' make the purpose unambiguous. It distinguishes from sibling tools like get_dataservice_info by focusing on the API spec retrieval.

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

Usage Guidelines5/5

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

The description provides an explicit typical workflow: search_dataservices → get_dataservice_info → get_dataservice_openapi_spec → call the API. It tells when to use this tool (to understand how to call the API) and places it in context with siblings, effectively guiding the agent on sequencing.

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

get_dataset_infoGet dataset infoA
Read-onlyIdempotent

Get detailed metadata about a specific dataset.

Returns title, description, organization, tags, resource count, creation/update dates, and license information.

ParametersJSON Schema
NameRequiredDescriptionDefault
dataset_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, covering safety and idempotency. The description adds value by listing specific return fields (title, description, organization, etc.), which provides context on the data structure beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief, with two sentences that front-load the purpose and follow with specific return fields. No extraneous content.

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

Completeness4/5

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

Given the tool's simplicity (one parameter, no nested objects), the presence of annotations, and an output schema, the description adequately covers the key aspects. It mentions the primary return fields, though it could note that a missing dataset might return an error.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, and the tool description does not explain the dataset_id parameter (e.g., format, expected values). Although the parameter is self-explanatory, the description should compensate for the missing schema documentation.

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 explicitly states 'Get detailed metadata about a specific dataset' with a clear verb and resource, and lists specific metadata fields. It distinguishes itself from sibling tools like get_resource_info by focusing on dataset-level metadata.

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

Usage Guidelines3/5

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

The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites. However, for a straightforward retrieval tool, the intended use is implicitly clear.

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

get_metricsGet usage metricsA
Read-onlyIdempotent

Get usage metrics (visits, downloads) for a dataset or resource.

Returns monthly statistics sorted by most recent first. At least one of dataset_id or resource_id must be provided. Note: Only available in production environment (not demo).

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
dataset_idNo
resource_idNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already indicate read-only, non-destructive, idempotent, and open-world behavior. The description adds value by stating the return format (monthly statistics, sorted most recent first) and the environment restriction, which are behavioral details beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise, front-loading the purpose and following with constraints in two short sentences. No wasted words.

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

Completeness4/5

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

Given 3 parameters (0 required), an output schema, and annotations, the description covers the key behavioral aspects. It mentions the sorted monthly statistics and environment restriction. Missing the default limit value and any pagination details, but still adequate.

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 coverage is 0%, so description must compensate. It mentions the metric types (visits, downloads) and the mutual exclusivity constraint for dataset_id/resource_id, but does not explain the 'limit' parameter. This adds some meaning but is incomplete.

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 retrieves usage metrics (visits, downloads) for a dataset or resource, with specific verb and resource. It distinguishes from sibling tools that focus on info, specs, or queries.

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 constraints: at least one of dataset_id or resource_id must be provided, and it is only available in production. It does not explicitly mention when to use versus alternatives, but the context is clear enough.

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

get_resource_infoGet resource infoA
Read-onlyIdempotent

Get detailed information about a specific resource (file).

Returns format, size, MIME type, URL, and checks Tabular API availability. Helps decide whether to use query_resource_data (if Tabular API is available) or fetch the raw file URL directly for unsupported formats or large files.

ParametersJSON Schema
NameRequiredDescriptionDefault
resource_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.9/5.0
Behavior5/5

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

Adds context beyond annotations (readOnly, idempotent) by explaining it checks Tabular API availability and guides next steps. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four concise sentences, front-loaded with purpose, no fluff. Every sentence adds value.

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?

Fully adequate for a one-param read tool with output schema and annotations. Explains how to use the returned info for decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% but the single parameter 'resource_id' is self-explanatory from context. Description doesn't add extra param details but is sufficient.

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 it gets detailed resource info (format, size, MIME, URL, Tabular API availability) and distinguishes from siblings like query_resource_data.

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

Usage Guidelines5/5

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

Explicitly describes when to use this tool vs alternatives: decides whether to use query_resource_data or fetch raw file URL directly.

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

search_dataservicesSearch third-party APIsA
Read-onlyIdempotent

Search for third-party APIs (dataservices) on data.gouv.fr by keywords.

Third-party APIs (or dataservices) are APIs registered in the data.gouv.fr catalog that provide programmatic access to data (unlike datasets which are static files). Use short, specific queries (the API uses AND logic, so generic words like "données" or "fichier" may return zero results).

Typical workflow: search_dataservices → get_dataservice_info → get_dataservice_openapi_spec → call the API using base_api_url per spec.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNo
queryYes
page_sizeNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds value by explaining the AND query logic and the expected workflow. It does not contradict annotations. Could mention pagination or dynamic output nature, but overall adds useful context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two brief paragraphs. The first sentence front-loads the purpose, and the rest adds essential context without fluff. Every sentence earns its place.

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

Completeness4/5

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

Given the presence of an output schema, the description does not need to detail return values. It covers query behavior and workflow but omits mention of pagination (page/page_size) and the open-world hint. These are minor gaps for a search tool.

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 coverage is 0%, so description must compensate. It explains the 'query' parameter's behavior (use short, specific terms, AND logic) but does not elaborate on 'page' or 'page_size'. This is adequate for the key parameter but incomplete for pagination controls.

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 searches for third-party APIs (dataservices) by keywords, distinguishes them from static datasets, and provides a specific usage tip about AND logic. This makes the purpose distinct from sibling search tools like search_datasets and search_organizations.

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 advises using short, specific queries due to AND logic and outlines a typical workflow (search_dataservices → get_dataservice_info → ...). It does not explicitly state when not to use the tool, but the distinction from datasets and the workflow provide clear context. Minor omission of explicit alternatives.

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

search_organizationsSearch organizationsA
Read-onlyIdempotent

Find publishing organizations on data.gouv.fr (who publishes datasets and reuses).

Pass a short query with distinctive words (acronym, ministry name, city, "INSEE", etc.). Generic or very broad terms often return large result sets; combine with page / page_size or add badge / name / business_number_id when you need a narrow list.

Leave query empty to list organizations with pagination (same as browsing the catalog). Use sort to order results (e.g. name, datasets, reuses, followers, views, created, last_modified, or the same with a leading '-' for descending, such as -datasets).

badge filters by publisher type: public-service, certified, association, company, local-authority.

The reply includes how many organizations matched, the current page, and for each hit: name (and acronym if any), id, slug, badges, optional usage metrics, and links to the organization page.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameNo
pageNo
sortNo
badgeNo
queryNo
page_sizeNo
business_number_idNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A5/5.0
Behavior5/5

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

Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which align with the description's mention of search functionality. The description adds detail about the response structure (matched count, page, per-org data with metrics and links) without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with four sentences, each serving a purpose: stating the tool's function, offering usage tips, detailing pagination, and listing sort options. It is well-structured and front-loaded.

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?

Given the 7 parameters (0 required), presence of output schema, and clear annotations, the description covers all necessary aspects: search behavior, filtering, sorting, pagination, and response details. It is fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description explains all parameters well: query, page, page_size, sort (with examples), badge (with allowed values), name, and business_number_id. It provides meaningful context that the schema lacks.

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: 'Find publishing organizations on data.gouv.fr'. It provides specific use cases like searching by acronym, ministry, city, and 'INSEE', which distinguishes it from sibling tools that search datasets or dataservices.

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

Usage Guidelines5/5

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

The description gives explicit guidance on when to use the tool (short query, combine with filters) and when not to (generic broad terms). It also advises on alternatives to narrow results using badge, name, or business_number_id, and states that leaving query empty lists all organizations.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct entity (organizations, datasets, resources, dataservices, metrics) with no overlapping purposes. Search tools are clearly separated by entity type, and data retrieval tools are specific to each resource.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., search_organizations, get_dataset_info, query_resource_data). The naming convention is uniform and predictable.

Tool Count5/5

With 10 tools, the server covers search, metadata retrieval, resource listing, data querying, and metrics—well-scoped for exploring a data catalog. The count is neither too sparse nor too heavy.

Completeness4/5

The tool set covers the main workflows: searching, inspecting metadata, listing resources, and querying tabular data. Missing a direct file download tool, but get_resource_info provides the URL. Otherwise, it enables a complete exploration journey.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Data Gouv MCP Server

    csonigo
    F
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that enables interaction with Datagouv APIs, primarily allowing users to search for up-to-date information about companies registered in France.
    11

  • mcp-gouv-fr

    gghez
    F
    license
    Not graded
    quality
    D
    maintenance
    MCP server for exploring French public open data via APIs like data.gouv.fr, geo.api.gouv.fr, INSEE Sirene, and Radio France.

  • opendata-az-mcp

    mustafa-ahmadov
    A
    license
    A
    quality
    D
    maintenance
    MCP server that enables AI chatbots to search, explore, and obtain download links for datasets from the Republic of Azerbaijan's Open Data Portal (opendata.az).
    3
    1
    MIT

Appeared in Searches

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/datagouv/datagouv-mcp'

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