mcp-data-gouv-fr

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Tools target distinct resources (sources, datasets, organizations, dataservices, vocabulary). However, 'get_sources' and 'fetch_source_excerpt' both relate to curated sources, requiring a clear two-step workflow, and 'explain_scope'/'list_reference_items' are meta/utility tools that might overlap in edge cases. Overall, clear separation of purpose is evident.
Naming Consistency4/5
All tools follow a consistent pattern: 'data_gouv_fr_' prefix plus a verb-noun or verb-object structure (get_sources, search_data_gouv, get_dataset, fetch_source_excerpt, list_reference_items). Minor deviation: 'explain_scope' is a meta-utility rather than a data operation, but naming remains predictable.
Tool Count4/5
9 tools for this server's scope (discovering and exploring data.gouv.fr resources) is reasonable and well-balanced. It's not too sparse nor overloaded. The inclusion of utility tools like 'explain_scope' and 'list_reference_items' slightly widens scope, but overall count is appropriate.
Completeness4/5
Covers discovery (search datasets, organizations, dataservices), inspection (get_dataset, list resources), and curated source access (get_sources, fetch_source_excerpt). Minor gap: no direct download or full text fetch of a resource (only excerpt), and no tool to browse dataset metadata beyond basic inspection, but core workflows are present.
Average 3.8/5 across 9 of 9 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- 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.
This repository includes a glama.json configuration file.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it searches public datasets via the official API, omitting details such as rate limits, authentication requirements, default query behavior, or response structure. This is a minimal disclosure that leaves the agent to guess at pagination, error handling, and search semantics.
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 a single, clear sentence that front-loads the verb and resource. No word is wasted, and it earns its place by providing immediate understanding of the tool's primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with only two optional parameters and no output schema, the description is minimally sufficient. However, it does not mention the default query or page_size, which are in the schema, nor does it disclose any usage limits or response wrapping. Given the tool's low complexity, it does not need extensive documentation, but a note on returning results or next-page handling would push it higher.
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%, with both parameters having descriptions in the schema ('Search query.' and 'Number of datasets to return.'). The tool description does not add any additional parameter-level detail, but given the high schema coverage, the baseline of 3 is appropriate. The description does not need to repeat what the schema already provides.
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 description uses a specific verb ('Search') and resource ('public datasets on data.gouv.fr'), which clearly differentiates from sibling tools like 'search_organizations' and 'search_dataservices'. However, it is somewhat generic and does not mention search scope (e.g., title vs. full text) beyond 'public datasets'. It meets the 'specific verb+resource' criterion but lacks differentiation finesse.
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?
No guidance is provided on when to use this tool versus its siblings (e.g., search_organizations, search_dataservices). The description does not mention exclusions, prerequisites, or alternative tools. The only implied usage is from the tool name itself, which is not sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does add the caveat 'when available', implying that the result may be empty or the feature may not exist in some contexts. However, it does not explain what 'reference items' are or whether the operation has any side effects, though a list operation is inherently non-destructive.
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 a single sentence that directly conveys the action and scope without any filler. It is appropriately sized for a parameterless list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no params, no output schema), the description is mostly complete. However, 'reference items' is left undefined, so an agent may not know what to expect in the response or how this tool fits into a workflow. A brief clarification of what qualifies as a 'reference item' would improve completeness.
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?
The tool has zero parameters, so the schema provides complete coverage. The description adds no parameter information, but none is needed. Baseline for 0 parameters is 4, and the description does not diminish that.
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 description states a specific action ('List') and a resource ('built-in reference items for this MCP'). It distinguishes from siblings, which focus on datasets, sources, organizations, etc., by clearly referring to the MCP's own internal reference data. The phrase 'when available' introduces mild ambiguity but the core purpose is clear.
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?
No guidance is given on when to use this tool versus alternatives. The description merely states what it does without suggesting use cases, prerequisites, or exclusions. Siblings like 'data_gouv_fr_get_sources' or 'data_gouv_fr_explain_scope' are not mentioned, so an agent has no basis for choosing between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the basic behavior—explaining MCP usefulness and source combination—but does not state output format, whether it consults other tools, or any side effects. For a simple no-parameter explainer, this is adequate but not rich.
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 a single, front-loaded sentence that directly states the tool's purpose. Every word earns its place, with no filler or repetition.
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?
For a zero-parameter meta-explainer with no output schema or annotations, the description is reasonably complete: it tells the agent what the tool does and what kind of guidance it provides. It could be more explicit about what 'sources' refers to, but sibling tool names supply enough context.
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?
The tool has zero parameters, so the schema already fully covers parameter semantics. The description has no need to add parameter-level detail; baseline 4 is appropriate.
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 uses a specific verb ('Explain') with a clear resource ('this MCP') and scope ('what this MCP is useful for and how an agent should combine its sources'). It clearly distinguishes itself from the sibling data-fetching/search tools by being a meta-orientation tool.
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?
The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The intended use is only implied by the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It states 'Search' which implies a read-only operation, but it does not mention return format, pagination behavior, rate limits, or any other operational traits. The description is minimal and leaves important behavioral aspects undisclosed.
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 extremely concise, consisting of two sentences that immediately convey the tool's purpose and usefulness. There is no fluff, and the information is front-loaded and easy to scan.
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?
For a simple search tool with only two parameters and no output schema, the description adequately conveys the core purpose and typical use case. It does not mention limitations or edge cases, but given the tool's simplicity, the current level of detail is sufficient.
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% for both parameters, so the schema already documents query and page_size with examples and ranges. The description adds no additional semantic value beyond what the schema provides, making the baseline 3 appropriate.
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 verb (search) and resource (data.gouv.fr public API / dataservice catalog), and adds context that it is useful for discovering reusable French public APIs by topic. This distinguishes it from sibling tools like search_data_gouv (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 provides a clear usage context (discovering APIs by topic) but does not explicitly mention alternative tools or when not to use it. The purpose it implies by mentioning 'dataservice catalog' differentiates it from siblings, but no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates this is a read-only listing operation ('List'), which is behaviorally informative. However, with no annotations provided, the description carries the full burden, and it doesn't disclose important behavioral traits like whether this returns paginated results, the format/schema of the returned sources, whether network calls are made (vs. cached), or if any authentication is required. The term 'List' is helpful but minimal; it meets the baseline without adding beyond the obvious.
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 a single, efficient sentence with no fluff or repetition. 'List curated official and high-value sources for data.gouv.fr.' earns its place by adding qualifying terms ('curated', 'official', 'high-value') that communicate value proposition without being verbose. Perfectly sized for the tool's scope.
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?
For a zero-parameter list tool with no output schema and no annotations, the description does an adequate job: it communicates the action and the resource. The description is likely complete for the tool's purpose, though it could be improved by adding a note about the response format or typical use case (e.g., 'use this to get a list of sources to feed into other tools'). However, gives its simplicity, this is largely sufficient and only a small extra clarification (e.g., what constitutes a 'source') would push it to a 5.
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?
The tool has zero parameters, and the schema coverage is 100% (vacuously, with an empty properties object). The description does not need to explain parameters. The description accurately reflects a parameterless list operation, and the sibling tools handle more complex queries. Full credit is appropriate here since there is no parametric burden to clarify.
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 description 'List curated official and high-value sources for data.gouv.fr' clearly states the tool's action (list) and resource (curated official and high-value sources for data.gouv.fr). The use of 'curated' and 'high-value' adds specificity and helps distinguish it from sibling tools like the search-based tools. Only docking a point because it could further clarify what 'sources' means in this context (e.g., data sources, organizations?) or explicitly name alternatives.
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 implies this is the go-to tool for listing curated sources, which implicitly suggests it's for browsing/high-level discovery rather than targeted search (which would use sibling search tools like data_gouv_fr_search_data_gouv). However, it doesn't explicitly state when to use it vs. alternatives, such as for exploring known sources vs. finding specific ones. No explicit exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It notes the optional format filter and that the output provides direct URLs, but does not mention pagination behavior, authentication requirements, or potential empty results. This is acceptable but not rich in detail.
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 compact and front-loaded with the core purpose ('List resources/files'), followed by the optional filter and usage guidance. Every sentence contributes useful information without redundancy.
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?
For a low-complexity tool with a complete schema, the description is sufficient. It explains the tool's role in the workflow, the nature of the output (URLs), and the optional filter. It could add more about the exact return structure, but is not incomplete given the simple scope.
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%, so parameters are already well-documented. The description adds minimal value by highlighting the optional format filter, but does not go beyond the schema's own descriptions for 'dataset', 'limit', or 'format'.
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 that the tool lists resources/files for a data.gouv.fr dataset with an optional format filter. This distinguishes it from sibling tools like data_gouv_fr_get_dataset, and the 'use after' instruction reinforces its specific role.
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?
Provides explicit usage context: 'Use after data_gouv_fr_get_dataset when the agent needs direct CSV/API/file URLs.' This tells when to invoke the tool, but does not explicitly mention when not to use it or name alternative tools for other resource-related needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. 'Search' clearly implies a read-only operation, and the description states what is being searched. However, it does not mention result shape, pagination behavior, ordering, rate limits, or any other limits, leaving some behavioral ambiguity.
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 sentences long, front-loaded with the core action and resource, and every sentence adds useful context. The examples are concise and help clarify the intended search space without unnecessary detail.
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?
For a simple two-parameter, read-only search with full schema coverage, the description gives enough context to invoke the tool correctly. It does not describe the expected return shape because there is no output schema, but the tool name and action make the fundamentals clear.
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%, with both 'query' and 'page_size' already well described in the schema. The description adds no new parameter-level semantics beyond context about what kinds of organizations are relevant, so the baseline score of 3 is appropriate.
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 specific action and resource: 'Search data.gouv.fr organizations and producers.' It further distinguishes itself from sibling tools by focusing on organizations/producers rather than datasets, sources, or dataservices, and gives concrete example producers like INSEE and IGN.
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 has a clear use case: 'Useful to find certified public producers such as Etalab, INSEE, IGN, ministries, regions, departments, or municipalities.' It does not explicitly mention when not to use it or name alternative tools, but the target resource is distinct enough for an agent to make a reasonable selection.
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?
With no annotations provided, the description carries the full burden of disclosing behavior. It does so reasonably well by stating it 'Fetch[es]' a 'short text excerpt', which implies a read-only, benign operation with a bounded return size. However, it could elaborate on error handling, rate limits, or what happens with invalid keys.
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?
Two sentences, completely void of fluff. The first sentence states the core purpose, the second provides essential usage direction. Every word serves a purpose. An exemplary model of concise, front-loaded writing.
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?
For a simple 2-parameter tool with no output schema and no annotations, the description covers the essentials: what is fetched, from where, and how to construct the key. The only minor gap is not explaining the max_chars parameter's purpose or default, but that's adequately handled by the schema. The guidance is complete enough for effective tool selection and invocation.
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 100% with clear parameter descriptions ('Source index, title keyword, or URL fragment' and 'Maximum excerpt length.'). The description adds marginal value by reinforcing the source_key format and connecting it to get_sources, but this doesn't go far beyond what the schema already provides. Baseline 3 is appropriate.
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?
Uses a specific verb-resource pairing: 'Fetch a short text excerpt from one curated source URL.' This distinguishes it from siblings that search or list datasets/organizations, and the mention of 'curated source URL' plus the reference to get_sources clearly positions it as a focused retrieval tool.
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 gives clear context that source keys originate from get_sources ('...or URL fragment from get_sources'), providing a dependency pointer to a sibling tool. It doesn't explicitly state when NOT to use it or name alternatives for exclusions, but the guidance on key construction is actionable for an agent.
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?
No annotations are provided, so the description carries the burden. 'Inspect...using the official public API' signals a read-only, public operation with no modification side effects. It doesn't describe return format or edge cases, but for a single-dataset lookup this is reasonable.
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 one compact sentence, front-loaded with the action verb, and contains no filler. Every part contributes to deciding the purpose or origin of the API.
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?
For a one-parameter, no-output-schema, known-dataset lookup, the description supplies the essential context needed for selection and invocation. It could be improved by saying what the returned inspection data looks like, but nothing critical is missing.
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 schema already covers the parameter fully with 'Dataset slug or id' at 100% coverage. The tool description repeats this notion but adds no new semantic detail about the parameter, so the high schema-coverage baseline of 3 applies.
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 uses a specific verb ('Inspect') and a precise target ('one data.gouv.fr dataset') identified by slug or id. This distinguishes it from sibling tools like search_data_gouv, list_dataset_resources, or get_sources, which operate at different levels or with different scopes.
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 clear context is: use this when you need details about one known dataset, identified by slug or id. It does not, however, explicitly name alternatives or say what to use for search/resource-listing instead, so it misses the top score.
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:

[![mcp-data-gouv-fr MCP server](https://glama.ai/mcp/servers/Hug0x0/mcp-data-gouv-fr/badges/card.svg)](https://glama.ai/mcp/servers/Hug0x0/mcp-data-gouv-fr)

Score Badge

Copy to your README.md:

[![mcp-data-gouv-fr MCP server](https://glama.ai/mcp/servers/Hug0x0/mcp-data-gouv-fr/badges/score.svg)](https://glama.ai/mcp/servers/Hug0x0/mcp-data-gouv-fr)

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/Hug0x0/mcp-data-gouv-fr'

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