Skip to main content
Glama
datagouv

datagouv-mcp

by datagouv

Query resource data

query_resource_data
Read-onlyIdempotent

Query tabular data from a resource via the Tabular API. Supports filtering, sorting, and pagination; for large datasets, retrieve the raw file URL directly.

Instructions

Query tabular data from a resource via the Tabular API (no download needed).

Works for CSV/XLSX files. Start with small page_size (20) to preview structure. Use filter_column/filter_value/filter_operator to filter, sort_column/sort_direction to sort. Filter operators: exact, contains, less, greater, strictly_less, strictly_greater. For large datasets requiring full analysis, paginate through pages or use get_resource_info to retrieve the raw file URL and fetch it directly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo
page_sizeNo
resource_idYes
sort_columnNo
filter_valueNo
filter_columnNo
sort_directionNoasc
filter_operatorNoexact

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removedv0.2.30
  3. Changed8 schema fields changedv0.2.26
    • addedInput schema / properties / filter_column
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Filter Column"
      +}
    • addedInput schema / properties / filter_operator
      Added value: +{
      +  "default": "exact",
      +  "title": "Filter Operator",
      +  "type": "string"
      +}
    • addedInput schema / properties / filter_value
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Filter Value"
      +}
    • addedInput schema / properties / page_size
      Added value: +{
      +  "default": 20,
      +  "title": "Page Size",
      +  "type": "integer"
      +}
    • removedInput schema / properties / question
      Removed value: -{
      -  "title": "Question",
      -  "type": "string"
      -}
    • addedInput schema / properties / sort_column
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Sort Column"
      +}
    • addedInput schema / properties / sort_direction
      Added value: +{
      +  "default": "asc",
      +  "title": "Sort Direction",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "question",
      -  "resource_id"
      -]New value: +[
      +  "resource_id"
      +]
  4. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds useful behavioral context such as 'no download needed' and pagination expectations, but does not detail the exact response shape beyond the existing output schema.

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, well-structured, and front-loaded with the core purpose. It uses short paragraphs to convey usage guidance without unnecessary fluff.

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?

The description gives sufficient context for invocation, including pagination strategy and an alternative for large datasets. It does not mention error cases or return format details, but the existing output schema and annotations cover some of this 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 schema has no parameter descriptions, so the tool description compensates by explaining filter_column, filter_value, filter_operator, sort_column, sort_direction, page_size, and the supported operators. It is slightly incomplete regarding sort_direction accepted values and the precise meaning of resource_id, though these are reasonably inferable.

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: querying tabular data from a resource via the Tabular API without downloading. It also distinguishes itself from the sibling get_resource_info by noting that raw file URLs can be retrieved separately.

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 explicit guidance on when to use this tool, including starting with a small page_size for previewing, using filter/sort parameters, and switching to the raw file URL for large datasets via get_resource_info. It also lists the supported filter operators.

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