ilostat-mcp-server

Describe staged ILOSTAT dataframes

ilostat_dataframe_describe

Read-onlyIdempotent

Describe the df_ dataframes staged by ilostat_query_indicator and ilostat_compare_geographies or stored by ilostat_dataframe_query register_as: the tool and parameters that produced each, the datasets it holds (label, last update, and the unit with its measure, type, and multiplier — values stay in the published scale the multiplier names), coverage, basis counts, attribution, creation and expiry times, row count, and column schema. Pass name for one dataframe. Without it, every staged dataframe is listed, except on a deployment whose callers share one canvas, where listing is off and only the exact name works. Read the schema here before writing SQL for ilostat_dataframe_query.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ilostat_dataframe_describe"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No	One dataframe name as the producing tool returned it (df_XXXXX_XXXXX: letters and digits, five in each part; case-insensitive, as in SQL). Omit to list every staged dataframe; a deployment whose callers share one canvas refuses the listing and needs the name.

Output Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Guidance when the named dataframe does not exist.
`dataframes`	No	Staged dataframes, newest first; empty when none.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 15, 2026

changedOutput schema / properties / dataframes / items / properties / datasets / items / properties / unit / description
```
Previous value: -"Unit label, when resolved."New value: +"Unit label (its code when unlabelled), when resolved."
```

addedOutput schema / properties / dataframes / items / properties / datasets / items / properties / unit_measure

Added value: +{
+  "description": "Unit code (PT percent, PS persons, …), when resolved.",
+  "type": "string"
+}

addedOutput schema / properties / dataframes / items / properties / datasets / items / properties / unit_multiplier

Added value: +{
+  "description": "Power of ten the values are published in (0 units, 3 thousands, 6 millions), as in the staged unit_multiplier column; values are never rescaled. Absent when the unit did not resolve.",
+  "type": "number"
+}

addedOutput schema / properties / dataframes / items / properties / datasets / items / properties / unit_multiplier_label
```
Added value: +{
+  "description": "Multiplier label.",
+  "type": "string"
+}
```

addedOutput schema / properties / dataframes / items / properties / datasets / items / properties / unit_type

Added value: +{
+  "description": "Unit type code (RT rate, NB number, …), when resolved.",
+  "type": "string"
+}

addedOutput schema / properties / dataframes / items / properties / datasets / items / properties / unit_type_label
```
Added value: +{
+  "description": "Unit type label.",
+  "type": "string"
+}
```

First observedOct 4, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent, so the safety profile is covered; the description goes further by disclosing that values stay in the published scale the multiplier names, that entries carry creation and expiry times, and that shared-canvas deployments refuse listing. That is genuine behavioral context beyond the structured hints, though it stops short of saying what happens to expired dataframes.

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

Conciseness4/5

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

Front-loaded with the core verb and resource, and every clause after it carries information. It is dense, and the long enumeration of returned fields partly duplicates the output schema, which is the only mild redundancy.

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?

An output schema exists, so return values need no explanation, yet the description still covers storage provenance, deployment caveat, and the SQL prerequisite. Nothing an agent needs to call this correctly 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?

Schema coverage is 100% and the schema description already explains the df_XXXXX_XXXXX pattern, case-insensitivity, and the omit-to-list behavior. The description restates the same semantics rather than adding new meaning, so the baseline 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?

Names a specific verb and resource (describe the df_<id> dataframes) and pins down exactly which objects it covers by naming the two producing tools plus the register_as storage path. An agent can distinguish it from ilostat_dataframe_query and the query siblings without opening any schema.

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?

States the two invocation modes (pass name for one, omit to list all), names the deployment condition where listing is refused and only the exact name works, and gives an explicit prerequisite: read the schema here before writing SQL for ilostat_dataframe_query. Alternatives and exclusions are both present.

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

All ilostat-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.