Skip to main content
Glama

faostat-mcp-server

by io.github.cyanheads

faostat-mcp-server: dataframe describe

faostat_dataframe_describe
Read-onlyIdempotent

List the canvas tables (faostat_xxxxxxxx) staged by faostat_query_observations and faostat_commodity_profile, each with its source tool, the query parameters that produced it, creation/expiry timestamps, row count, and column schema. Call this before faostat_dataframe_query to discover the exact table and column names to reference in SQL. Tables are listed newest-first and paged: pass name to describe one table outright, or page with offset + limit — when the response reports truncated, pass the returned nextOffset to fetch the rest.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoOptional table name (faostat_xxxxxxxx) to describe a single staged table. Takes precedence over `offset` / `limit`, which are ignored for a name lookup (always single-page).
limitNoMaximum staged tables to return on this page (max 100). Each entry carries a full column schema, so the default keeps a discovery call small.
offsetNoZero-based pagination offset into the staged tables (newest first). When the response reports truncated, pass the returned nextOffset here to fetch the next page. Ignored for `name` lookups.
canvas_idNoOptional canvas ID from a prior faostat_query_observations / faostat_commodity_profile call. Omit to list the tables staged in this session (the common case).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance when nothing is staged yet or more pages remain.
tablesNoActive staged tables for this session, newest first — one page of them. Empty when none are staged.
truncatedNoTrue when more staged tables remain beyond the returned page — fetch them with nextOffset. Always false for a single-table `name` lookup, which is never paged.
nextOffsetNoOffset to pass on the next call to fetch the following page. Present only when truncated is true; absent on the last page and for `name` lookups.
totalMatchesNoStaged tables on the resolved canvas, before the page limit is applied.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark readOnlyHint and idempotentHint true, which the description complements with valuable behavioral details: tables are listed newest-first, pagination is handled via a `truncated` flag and `nextOffset`, `name` overrides pagination, and each entry includes a full column schema (hence the default limit). No contradiction with annotations; the description adds context beyond the structured hints.

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—two sentences—yet packs all necessary behavioral and usage information. It opens with the core purpose, then layers the pagination and ordering details, with no redundant filler. Every clause earns its place.

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 tool's pagination logic, name precedence, and relationship to other faostat tools, the description covers everything an agent needs to call it correctly: what is listed, what each entry contains, how to handle truncation, and how to use `canvas_id`. The presence of an output schema also relieves the description from having to document the return structure.

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%, and each parameter's description in the schema is already detailed (e.g., precedence, pagination semantics, canvas_id context). The tool description adds no additional parameter-specific meaning—it largely repeats what the schema says. Baseline 3 is appropriate because the schema carries the full burden and the description does not need to compensate.

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 states a specific verb ('list') and resource ('canvas tables'), and enumerates exactly what each entry contains (source tool, query parameters, timestamps, row count, column schema). It clearly differentiates from sibling tools like faostat_dataframe_query, which consumes these tables, and faostat_query_observations / faostat_commodity_profile, which produce them.

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 explicitly instructs 'Call this before faostat_dataframe_query to discover the exact table and column names to reference in SQL.' It also clarifies when to use the `name` parameter versus pagination with `offset`/`limit`, and specifies that `name` takes precedence. This is direct, unambiguous usage guidance.

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

All faostat-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: discovery (list_domains), code resolution (resolve_codes), raw data query (query_observations), high-level profile assembly (commodity_profile), and dataframe management (describe/query). The composite profile tool overlaps slightly with query_observations, but its description clearly positions it as a convenience wrapper, eliminating ambiguity.

Naming Consistency4/5

All tools share the faostat_ prefix, and most use verb_noun structure (list_domains, query_observations, resolve_codes, dataframe_describe, dataframe_query). The exception is commodity_profile, which is a noun_phrase rather than verb-first, though it is still descriptive and follows the overall underscore convention. This minor deviation keeps the set mostly consistent.

Tool Count5/5

With 6 tools, the server is well-scoped for its purpose: it covers the essential workflow of discovering domains, resolving codes, querying data, and analyzing results via dataframes. Each tool has a clear role, and the count is appropriate for a focused statistical data server without excess or deficiency.

Completeness5/5

The tool surface covers the full data retrieval lifecycle: domain discovery, code resolution, raw data extraction, and flexible post-query analysis (including a high-level commodity profile shortcut). The descriptions handle edge cases like aggregation exclusion and flag validation, and no obvious gaps exist for a read-only FAOSTAT querying server.

Resources