datagouv-mcp

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.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.
Average 4.4/5 across 10 of 10 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 12 of 14 community issues answered or closed in the last 6 months
- 17 commits in the last 12 weeks
- Last stable release on July 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![datagouv-mcp MCP server](https://glama.ai/mcp/servers/datagouv/datagouv-mcp/badges/card.svg)](https://glama.ai/mcp/servers/datagouv/datagouv-mcp)

Score Badge

Copy to your README.md:

[![datagouv-mcp MCP server](https://glama.ai/mcp/servers/datagouv/datagouv-mcp/badges/score.svg)](https://glama.ai/mcp/servers/datagouv/datagouv-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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