Skip to main content
Glama

faostat-mcp-server: query observations

faostat_query_observations
Read-only

Query a FAOSTAT domain's data cube by area(s), item(s), element(s), and year range, returning observations (area, item, element, year, value, unit, and the data-quality flag). Resolve codes first with faostat_resolve_codes — the cube is unqueryable without them. Aggregate regions (World, continents, economic groupings) are EXCLUDED by default so a naive SUM does not double-count a region with its member countries; set include_aggregates=true to get the regional roll-ups, or pass explicit area_codes to query exactly what you name. Small result sets return inline; large ones spill to a DataCanvas table (returned canvas_id + table_name) for GROUP BY / ranking / time-series analysis via faostat_dataframe_query. Every row carries its flag — commonly A=Official, B=time-series break, E=Estimated, I=Imputed, M=Missing (value cannot exist), T=Unofficial, X=from an international organization, plus others FAOSTAT defines per domain — so honor it, treat any unrecognized flag as informational, and never assume an estimated, imputed, or unrecognized value is official.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax observations returned inline — also the preview size when the result stages to a canvas table. Rows past it are never dropped silently: a match larger than limit stages in full to a DataCanvas table (canvas_id + table_name), and when no table is staged the notice reports how many matched so you can raise limit or narrow the filters. Max 1000.
domainYesFAOSTAT domain code (e.g. "QCL"). Must be indexed locally.
year_endNoInclusive end year (e.g. 2022).
canvas_idNoCanvas ID from a prior call to stage onto. Omit to start a fresh canvas (a new id is returned).
area_codesNoArea codes from faostat_resolve_codes. When set, aggregates are NOT auto-excluded — the codes are honored verbatim.
item_codesNoItem codes from faostat_resolve_codes.
year_startNoInclusive start year (e.g. 2000).
element_codesNoElement codes from faostat_resolve_codes (e.g. 5510 Production).
include_aggregatesNoWhen false (default), exclude aggregate-region rows (codes ≥ 5000 plus a few curated sub-threshold roll-ups such as China=351) so sums are not double-counted. Set true for World/continent/grouping roll-ups. Ignored when explicit area_codes are passed.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
domainNoThe domain code echoed back.
noticeNoGuidance on empty results, aggregate exclusion, or how to reach the spilled set.
spilledNoTrue when the full result was staged on a DataCanvas table.
canvas_idNoCanvas ID holding the staged result — pass to faostat_dataframe_query / _describe.
truncatedNoTrue when the staged table hit the 50,000-row staging cap — the staged set is a PREFIX of the match, not the complete result. Partition the query by year or code ranges to capture the rest.
table_nameNoCanvas table name holding the full result set (present when spilled).
totalCountNoObservations matched. Exact when the result was returned inline or fully staged. A floor — more matched — in two cases, both named by the notice: the match exceeded the 50,000-row staging cap (truncated is then true), or staging failed and the response fell back to an inline page.
observationsNoInline observations (preview when the full set spilled to a canvas table).
staged_row_countNoRows actually staged on the canvas table (present when spilled). Equals the full match count unless truncated, in which case it is the 50,000-row cap.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, openWorldHint=false, idempotentHint=false — no behavioral detail. The description adds critical transparency: aggregate rows are excluded by default to avoid double-counting, large result sets stage to a canvas table via canvas_id/table_name, rows are never silently dropped, and the meaning of data-quality flags (A, B, E, I, M, T, X) is disclosed with guidance to treat unrecognized flags as informational. This goes far beyond what annotations provide and warns the agent about subtle data semantics.

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?

The description is long but densely informative — every sentence contributes (purpose, prerequisite, aggregation rule, spill mechanism, flag semantics). It is front-loaded with the core action and progressively adds edge cases. It's not padded, but its length is at the high end; a 4 acknowledges the efficient structure while noting it could be tightened without loss.

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?

For a tool with 9 parameters and an output schema, the description covers all necessary operational context: the need for pre-resolved codes, aggregate handling, result staging, and flag interpretation. It addresses potential failure modes (double-counting, silent truncation) and tells the agent how to avoid them. The output schema exists to document return structure, so the description's focus on behavior and constraints is exactly right. Nothing critical for correct invocation is missing.

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 100%, so the baseline is 3. The description adds value beyond parameter names: it clarifies limit's staging behavior and that exceeding it doesn't drop data, explains area_codes override aggregate exclusion, details include_aggregates' exact threshold (codes ≥ 5000 plus curated roll-ups like China=351), and links element_codes to resolve_codes with an example (5510 Production). Not every nuance of canvas_id is expanded, but the description materially enriches schema meaning, earning a 4.

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 opens with a precise action: 'Query a FAOSTAT domain's data cube by area(s), item(s), element(s), and year range, returning observations' — specifying the verb, resource, input dimensions, and output fields. It explicitly names prerequisites (faostat_resolve_codes) and differentiates from sibling faostat_dataframe_query, so an agent can immediately tell this tool gathers raw observations versus analyzing them. No ambiguity.

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?

State the required precondition: 'Resolve codes first with faostat_resolve_codes — the cube is unqueryable without them.' It explains the aggregate-exclusion default and how to override (include_aggregates=true or explicit area_codes), and tells when results spill to a DataCanvas table for faostat_dataframe_query. This gives clear when-to-use and when-not-to-use guidance, including the exact alternative tool.

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

Try in Browser

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.