faostat-mcp-server
Server Details
UN FAOSTAT global food & agriculture statistics over a local SQLite mirror, via MCP.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/faostat-mcp-server
- GitHub Stars
- 1
- Server Listing
- @cyanheads/faostat-mcp-server
Available Tools
6 toolsfaostat_commodity_profilefaostat-mcp-server: commodity profileARead-onlyInspect
Assemble a global profile for one commodity in a single call: top-producing countries, the annual production trend, and trade flows (top exporters and importers). Accepts a commodity name, resolves it to item codes, then queries the production (QCL) and trade (TCL) domains and merges the results. Each ranking is a per-country sum across the resolved items, taken at that country's own latest year with data and grouped by unit so incomparable quantities are never added. The trend is returned inline as year/value points. Country-level only (aggregates excluded). When a required domain is not indexed locally, returns a partial profile with a notice naming the gap rather than failing. The full merged observation set spills to a DataCanvas table for deeper SQL via faostat_dataframe_query.
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | Number of top producers / exporters / importers to return. Max 50. | |
| year_end | No | Inclusive end year for the trend (e.g. 2022). | |
| canvas_id | No | Canvas ID from a prior call to stage onto. Omit to start a fresh canvas. | |
| item_query | Yes | Commodity name to profile (e.g. "maize", "wheat", "coffee green"). Matched by relevance; the 5 best-matching items are folded into one profile, so a broad name such as "milk" is narrowed — the response discloses how many items matched in total. | |
| year_start | No | Inclusive start year for the trend (e.g. 1990). |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Names any required domain that was not indexed, item-resolution truncation, mixed units in the rankings, or other partial-result context. |
| spilled | No | True when the merged observation set was staged on a canvas table. |
| canvas_id | No | Canvas ID holding the merged set — pass to faostat_dataframe_query / _describe. |
| truncated | No | True when the STAGED CANVAS TABLE hit the 50,000-row staging cap and is therefore a PREFIX of the merged observation set — re-query faostat_query_observations partitioned by year to stage the rest. The rankings and production_trend above are SQL aggregates over the complete match and stay exact either way. |
| item_query | No | The commodity query echoed back. |
| table_name | No | Canvas table holding the staged observations — production plus trade when the trade domain (TCL) is indexed, production only when it is not (present when spilled). The notice names which of the two the table holds. |
| trend_points | No | Total production observations aggregated into production_trend. Exact — the aggregation runs over the complete filtered match, not a capped page. |
| top_exporters | No | Top exporters by summed export quantity (empty when trade is not indexed). |
| top_importers | No | Top importers by summed import quantity (empty when trade is not indexed). |
| top_producers | No | Top producers by summed production (countries only). |
| itemsTruncated | No | True when the commodity name matched more items than the profile folded in — the profile then covers only the most relevant few. |
| resolved_items | No | Commodities the query resolved to (the profile aggregates across all of them). |
| production_trend | No | The annual production series for the resolved commodity, summed over countries and items per year and ordered oldest-first. Aggregated in SQL over the complete filtered match, so it is not affected by the canvas staging cap. |
| staged_row_count | No | Rows actually staged on the merged canvas table (present when spilled). Equals the 50,000-row cap when truncated. |
| resolvedItemCodes | No | Item codes the commodity query resolved to. |
| resolvedItemMatches | No | Total items the commodity query matched in QCL, before the 5-item profile cap. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only (readOnlyHint=true) and non-mutating. The description adds valuable behavioral context: it resolves item codes, groups rankings by unit to avoid adding incomparable quantities, returns partial profiles with a notice if a domain is missing, and stages the full dataset to a DataCanvas table. These details go beyond the annotations and help the agent anticipate failure modes and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is several sentences long but each sentence earns its place: it covers purpose, method, edge cases, and the downstream handoff to a DataCanvas table. It is front-loaded with the key operation and resource, and the logical flow from purpose to behavior to failure handling makes it dense yet clear without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—multiple domains, merging, partial failures—the description covers the main scenarios: how rankings are computed, country-level scope, partial profile behavior when a domain is missing, and where to go for deeper analysis. The existence of an output schema covers return specifics, so the description doesn't need to explain that. It is complete enough for an agent to invoke correctly and know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All five parameters are fully described in the schema (100% coverage), so the schema carries the parameter documentation burden. The description mostly repeats schema content, such as item_query matching by relevance and year range semantics. It adds no new parameter-specific meaning; the useful notes about unit grouping are behavioral rather than parameter-level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Assemble a global profile for one commodity in a single call: top-producing countries, the annual production trend, and trade flows (top exporters and importers).' It specifies a concrete verb and resource, and the composite nature (merging production and trade domains) distinguishes it from the granular sibling tools like faostat_query_observations or faostat_resolve_codes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for quickly building a commodity profile and mentions that deeper SQL is possible via faostat_dataframe_query after staging to a DataCanvas table. However, it does not explicitly contrast this composite tool with alternatives such as faostat_query_observations for raw data or faostat_resolve_codes for code resolution, leaving the decision of when to use this tool over others somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
faostat_dataframe_describefaostat-mcp-server: dataframe describeARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional 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). | |
| limit | No | Maximum staged tables to return on this page (max 100). Each entry carries a full column schema, so the default keeps a discovery call small. | |
| offset | No | Zero-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_id | No | Optional 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
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when nothing is staged yet or more pages remain. |
| tables | No | Active staged tables for this session, newest first — one page of them. Empty when none are staged. |
| truncated | No | True 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. |
| nextOffset | No | Offset 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. |
| totalMatches | No | Staged tables on the resolved canvas, before the page limit is applied. |
TDQS
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.
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.
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.
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.
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.
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.
faostat_dataframe_queryfaostat-mcp-server: dataframe queryARead-onlyIdempotentInspect
Run a single-statement SELECT against the canvas tables staged by faostat_query_observations and faostat_commodity_profile (table names look like faostat_xxxxxxxx). Use this for cross-country and cross-item aggregation, GROUP BY rankings, joins, and time-series analysis over the full result set the inline preview only sampled. Standard DuckDB SQL — joins, aggregates, window functions, CTEs all work. Read-only: writes, DDL, DROP, COPY, PRAGMA, ATTACH, and external-file table functions are rejected; system catalogs (information_schema, sqlite_master, duckdb_*) are denied — list staged tables via faostat_dataframe_describe. Every row carries its data-quality 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 — keep it in projections, treat any unrecognized flag as informational, and never assume it is official.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | Single-statement read-only SELECT against staged faostat_<id> tables. Columns: area_code, area, item_code, item, element_code, element, year, unit, value, flag. CAST(value AS DOUBLE) for arithmetic. | |
| canvas_id | No | Optional canvas ID from a prior faostat_query_observations / faostat_commodity_profile call. Omit to query the tables staged in this session (the common case). | |
| row_limit | No | Hard cap on rows in the response. Default 1000, max 10000. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rows | No | Materialized result rows, bounded by row_limit. |
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when the query returned no rows or when results were capped. |
| columns | No | Column names in projection order. |
| row_count | No | Rows returned in this response — the materialized count, equal to rows.length. When truncated is true this is NOT the full result total (this path computes no exact total); page or aggregate to reach the rest. |
| truncated | No | True when row_limit capped the result and more rows exist than were returned. To reach them: page with ORDER BY + SQL LIMIT/OFFSET, raise row_limit (max 10000), or aggregate with GROUP BY. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description details enforcement: writes, DDL, DROP, COPY, PRAGMA, ATTACH, and external-file functions are rejected, and system catalogs are denied. It adds critical flag semantics (A, B, E, I, M, T, X) with a caution not to assume flags are official. This is rich, actionable disclosure that materially helps the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured: purpose first, then usage, restrictions, and flag guidance. Every sentence earns its place, though it is on the longer side. It is front-loaded and organized, but a slightly tighter phrasing could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (free-form SQL, read-only enforcement, flag fields), the description covers all operational essentials: table naming, allowed SQL, denied constructs, flag handling, and sibling tool references. An output schema exists, so return details are already specified elsewhere. No critical operational detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter already has a description. The tool description adds only marginal param-specific nuance (e.g., column list and CAST hint) that is also present in the schema. It does not compensate beyond the baseline expected when structure is fully documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Run a single-statement SELECT against the canvas tables staged by faostat_query_observations and faostat_commodity_profile'. It clearly distinguishes itself from siblings like faostat_dataframe_describe (for listing tables) and staging tools, and lists concrete use cases (aggregation, GROUP BY, joins, time-series). This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool ('Use this for cross-country and cross-item aggregation...') and points to an alternative for a different need ('list staged tables via faostat_dataframe_describe'). It also clarifies the common case for the canvas_id parameter and enumerates disallowed SQL constructs, giving clear boundaries for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
faostat_list_domainsfaostat-mcp-server: list domainsARead-onlyIdempotentInspect
Discover FAOSTAT statistical domains (production, trade, food balances, food security, land use, agri-emissions, prices, value) with their codes, descriptions, last-update date, upstream row count, and local index status. Every query keys on a domain code from here. The indexed flag tells you which domains are queryable right now; un-indexed domains exist in the catalog but must be added to FAOSTAT_DOMAINS and re-synced before faostat_query_observations can read them. The catalog runs to ~69 domains with long descriptions, so responses are paged: narrow with topic / indexed_only, pass code to fetch one domain outright, or page with offset + limit — when the response reports truncated, pass the returned nextOffset to fetch the rest.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | Exact domain code lookup (e.g. "RL"), case-insensitive. Returns that one domain's full record on a single page. Takes precedence over `topic` / `indexed_only` when provided. | |
| limit | No | Maximum domains to return on this page (max 200 — above the catalog size, so raise it to fetch everything at once). Domain descriptions are long; the default keeps a browse call small. | |
| topic | No | Case-insensitive substring filter over domain code, name, and topic (e.g. "trade", "emissions", "QCL"). Omit to list the full catalog. | |
| offset | No | Zero-based pagination offset into the matching domains (code-sorted). When the response reports truncated, pass the returned nextOffset here to fetch the next page. Ignored for exact-code lookups (always single-page). | |
| indexed_only | No | When true, return only domains indexed in the local mirror (queryable now). |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Guidance when a filter matched nothing, more pages remain, or no domains are indexed yet. |
| domains | No | Matching domains, sorted by code. |
| truncated | No | True when more matches remain beyond the returned page — fetch them with nextOffset. |
| nextOffset | No | Offset to pass on the next call to fetch the following page. Present only when truncated is true; absent on the last page and for exact-code lookups. |
| totalCount | No | Total domains in the FAOSTAT catalog, independent of any filter. |
| indexedCount | No | Domains currently indexed in the local mirror. |
| totalMatches | No | Domains matching the current filters, before the page limit is applied. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint:true and idempotentHint:true, and the description does not contradict these. Beyond annotations, it discloses substantial behavioral traits: pagination with the truncated flag and nextOffset, the indexed flag meaning queryability, the precedence of code over other filters, and the absence of un-indexed domains from queries. This adds rich context beyond what annotations provide, fully satisfying the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long (roughly 200 words) but every sentence contributes: purpose, indexing semantics, pagination, and filter guidance. It is front-loaded with the core purpose and then elaborates on usage. It could be trimmed slightly without loss, but the density of value justifies a 4 rather than a 5, as a more compact version would be possible while retaining clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's five parameters, pagination, and indexing logic, the description covers everything an agent needs to call it correctly: the exact fields, filter behavior, precedence, pagination with truncated/nextOffset, and the relationship to querying. The presence of an output schema means return values are defined there, and the description still mentions the truncated flag and nextOffset, which are key for iterative calling. It is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed per-parameter descriptions, so the baseline is 3. The description adds cross-parameter semantics such as code's precedence over topic/indexed_only, the pagination flow with offset/limit, and the meaning of indexed_only in the broader workflow. It also clarifies the purpose of limit relative to catalog size. This goes beyond simply restating schema fields, though the schema already covers much, so a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Discover FAOSTAT statistical domains' and enumerates the specific attributes returned (codes, descriptions, last-update date, etc.). It uses a specific verb (discover/list) and resource (domains), and distinguishes itself from siblings by explaining that domain codes from here are the entry point for faostat_query_observations, a sibling tool. This gives unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: 'Every query keys on a domain code from here' and states that un-indexed domains must be added to FAOSTAT_DOMAINS before faostat_query_observations can read them. It also explains when to narrow with filters, when to pass a code, and how to page. This is direct 'when to use' advice, including interplay with a named sibling tool, exceeding mere implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
faostat_query_observationsfaostat-mcp-server: query observationsARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max 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. | |
| domain | Yes | FAOSTAT domain code (e.g. "QCL"). Must be indexed locally. | |
| year_end | No | Inclusive end year (e.g. 2022). | |
| canvas_id | No | Canvas ID from a prior call to stage onto. Omit to start a fresh canvas (a new id is returned). | |
| area_codes | No | Area codes from faostat_resolve_codes. When set, aggregates are NOT auto-excluded — the codes are honored verbatim. | |
| item_codes | No | Item codes from faostat_resolve_codes. | |
| year_start | No | Inclusive start year (e.g. 2000). | |
| element_codes | No | Element codes from faostat_resolve_codes (e.g. 5510 Production). | |
| include_aggregates | No | When 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
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| domain | No | The domain code echoed back. |
| notice | No | Guidance on empty results, aggregate exclusion, or how to reach the spilled set. |
| spilled | No | True when the full result was staged on a DataCanvas table. |
| canvas_id | No | Canvas ID holding the staged result — pass to faostat_dataframe_query / _describe. |
| truncated | No | True 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_name | No | Canvas table name holding the full result set (present when spilled). |
| totalCount | No | Observations 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. |
| observations | No | Inline observations (preview when the full set spilled to a canvas table). |
| staged_row_count | No | Rows 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
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.
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.
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.
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.
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.
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.
faostat_resolve_codesfaostat-mcp-server: resolve codesARead-onlyIdempotentInspect
Resolve human terms to the opaque integer codes faostat_query_observations needs, within a dimension: areas (countries/regions), items (commodities), or elements (metrics like production, yield, import quantity). Pass query for fuzzy full-text matching ("maize" → item 56), name_contains for a substring filter, or code for an exact-code lookup; omit all three to list the whole dimension. Item and element results are scoped to the requested domain — only codes present in that domain's cube are returned, so a resolved code is always queryable there (areas are shared across domains). Page large listings with offset + limit: when the response reports truncated, pass the returned nextOffset to fetch the next page. Every area match is flagged country or aggregate — aggregates (World, continents, economic groupings — codes ≥ 5000 plus a few curated sub-threshold roll-ups such as China=351, which sums mainland + Taiwan + Hong Kong + Macao) double-count if summed with their member countries, so resolve before querying and exclude aggregates unless you want the regional roll-up.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | Exact code lookup. Takes precedence over `query`/`name_contains` when provided. | |
| limit | No | Maximum matches to return (max 200). | |
| query | No | Full-text search term, FTS5-matched against the dimension labels with prefix matching (e.g. "wheat", "import quantity"). Relevance-ranked. | |
| domain | Yes | FAOSTAT domain code (e.g. "QCL"). Item and element resolution is scoped to the codes present in this domain's data; area code lists are shared across all indexed domains. | |
| offset | No | Zero-based pagination offset into the match set. When the response reports truncated, pass the returned nextOffset here to fetch the next page. Ignored for exact-code lookups (always single-page). | |
| dimension | Yes | Which dimension to resolve: "area" (countries/regions), "item" (commodities), or "element" (metrics). | |
| name_contains | No | Case-insensitive substring filter over the label. Used only when `query` is omitted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| domain | No | The domain code echoed back. |
| notice | No | Guidance when nothing matched, more pages remain, or the dimension is not yet indexed. |
| matches | No | Matching codes, relevance-ranked for query mode, else by code. |
| dimension | No | The dimension resolved. |
| truncated | No | True when more matches remain beyond the returned page — fetch them with nextOffset. |
| nextOffset | No | Offset to pass on the next call to fetch the following page. Present only when truncated is true; absent on the last page and for exact-code lookups. |
| totalMatches | No | Total matches in this domain before the result cap. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavior beyond annotations: domain scoping of item/element results, the 'country' vs 'aggregate' flag, the ≥5000 code heuristic (plus curated exceptions like China=351), double-counting risk, and the truncated/nextOffset pagination contract. It never contradicts readOnlyHint or idempotentHint—it enriches them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence contributes: purpose, three matching modes, domain scoping, pagination mechanics, aggregate warning with specific examples. It is front-loaded with the core purpose and ends with the critical usage caveat. No filler; each clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with an output schema and annotations, the description leaves nothing ambiguous: it covers all parameter relationships, pagination, domain scoping, and a major data-quality pitfall. Given the existence of an output schema, the lack of return-value details is appropriate. It is fully complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds real meaning: it gives a concrete example ('maize' → item 56), clarifies precedence relationships among query/name_contains/code, states that code takes precedence and name_contains is used only when query is omitted, and explains offset/limit behavior. This is more than the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource ('Resolve human terms to the opaque integer codes... within a dimension') and enumerates the three dimensions (areas, items, elements). It explicitly distinguishes itself from faostat_query_observations by saying these codes are what that tool needs, so agents can tell them apart without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use this tool ('resolve before querying') and what to exclude (aggregates unless you want the regional roll-up). It also details the three matching modes and when each applies, plus pagination instructions with nextOffset. This is among the best guidance seen, covering both when and how.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
6 tool updates
- Changed
faostat_commodity_profile6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "item_query", + "resolved_items", + "top_producers", + "top_exporters", + "top_importers", + "production_trend", + "trend_points", + "spilled", + "truncated", + "resolvedItemCodes", + "resolvedItemMatches", + "itemsTruncated" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `no_match`: The item query resolved to no commodity code. `index_not_ready`: The production (QCL) mirror is cold — its initial sync has never completed. `invalid_year_range`: year_start is greater than year_end — a self-contradictory range that can never match. The bounds reach the production, trade, and merged canvas-stream queries alike, so every one of them would return nothing. Other values are possible when a failure originates below the handler.", + "examples": [ + "no_match", + "index_not_ready", + "invalid_year_range" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "item_query", - "resolved_items", - "top_producers", - "top_exporters", - "top_importers", - "production_trend", - "trend_points", - "spilled", - "truncated", - "resolvedItemCodes", - "resolvedItemMatches", - "itemsTruncated" -]
- Changed
faostat_dataframe_describe14 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / limitAdded value: +{ + "default": 20, + "description": "Maximum staged tables to return on this page (max 100). Each entry carries a full column schema, so the default keeps a discovery call small.", + "maximum": 100, + "minimum": 1, + "type": "integer" +} - changed
Input schema / properties / name / descriptionPrevious value: -"Optional table name (faostat_xxxxxxxx) to describe a single staged table. Omit to list all."New value: +"Optional 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)." - added
Input schema / properties / offsetAdded value: +{ + "default": 0, + "description": "Zero-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.", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +} - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "tables", + "totalMatches", + "truncated" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `canvas_disabled`: The DataCanvas service is not configured for this deployment. `canvas_not_found`: An explicit canvas_id does not resolve to a live canvas — unknown, expired, or owned by another tenant. `missing_table`: A name filter was supplied but no staged table on the resolved canvas matches it. Other values are possible when a failure originates below the handler.", + "examples": [ + "canvas_disabled", + "canvas_not_found", + "missing_table" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - added
Output schema / properties / nextOffsetAdded value: +{ + "description": "Offset 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.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" +} - added
Output schema / properties / noticeAdded value: +{ + "description": "Guidance when nothing is staged yet or more pages remain.", + "type": "string" +} - changed
Output schema / properties / tables / descriptionPrevious value: -"Active staged tables for this session, newest first. Empty when none are staged."New value: +"Active staged tables for this session, newest first — one page of them. Empty when none are staged." - added
Output schema / properties / totalMatchesAdded value: +{ + "description": "Staged tables on the resolved canvas, before the page limit is applied.", + "type": "number" +} - added
Output schema / properties / truncatedAdded value: +{ + "description": "True 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.", + "type": "boolean" +} - removed
Output schema / requiredRemoved value: -[ - "tables" -]
- Changed
faostat_dataframe_query6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "columns", + "row_count", + "rows", + "truncated" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `canvas_disabled`: The DataCanvas service is not configured for this deployment. `canvas_not_found`: An explicit canvas_id does not resolve to a live canvas — unknown, expired, or owned by another tenant. `missing_table`: The SQL references a faostat_<id> table that has expired or was never staged. `system_catalog_access`: The SQL references a denied system catalog (information_schema, sqlite_master, duckdb_*). `invalid_sql`: The SQL has a syntax or execution error, or is not a single read-only SELECT. Other values are possible when a failure originates below the handler.", + "examples": [ + "canvas_disabled", + "canvas_not_found", + "missing_table", + "system_catalog_access", + "invalid_sql" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "columns", - "row_count", - "rows", - "truncated" -]
- Changed
faostat_list_domains6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "domains", + "totalCount", + "totalMatches", + "truncated", + "indexedCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode.", + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "domains", - "totalCount", - "totalMatches", - "truncated", - "indexedCount" -]
- Changed
faostat_query_observations6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "domain", + "observations", + "spilled", + "truncated", + "totalCount" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `domain_not_indexed`: The domain is not in the local mirror selection (FAOSTAT_DOMAINS) — whether a valid FAOSTAT code or not. `index_not_ready`: The domain mirror is cold — its initial sync has never completed. `canvas_disabled`: The result is too large to inline but DataCanvas is off, so it cannot be staged for SQL. `invalid_year_range`: year_start is greater than year_end — a self-contradictory range that can never match. Other values are possible when a failure originates below the handler.", + "examples": [ + "domain_not_indexed", + "index_not_ready", + "canvas_disabled", + "invalid_year_range" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "domain", - "observations", - "spilled", - "truncated", - "totalCount" -]
- Changed
faostat_resolve_codes6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "domain", + "dimension", + "matches", + "totalMatches", + "truncated" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `unknown_domain`: The domain code is not a selected (indexed) FAOSTAT domain. `index_not_ready`: The dimension tables are not yet populated (mirror has never completed a sync). Other values are possible when a failure originates below the handler.", + "examples": [ + "unknown_domain", + "index_not_ready" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "domain", - "dimension", - "matches", - "totalMatches", - "truncated" -]
1 tool update
- Changed
faostat_query_observations2 fields changed- changed
Input schema / properties / limit / descriptionPrevious value: -"Max observations returned inline when the result does not spill. Max 1000."New value: +"Max 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." - changed
Output schema / properties / totalCount / descriptionPrevious value: -"Observations matched. Exact when the result was returned inline or fully staged; when the match set exceeded the 50,000-row staging cap this is that cap — a floor, not the exact count (truncated is then true)."New value: +"Observations 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."
1 tool update
- Changed
faostat_commodity_profile33 fields changed- changed
Input schema / properties / item_query / descriptionPrevious value: -"Commodity name to profile (e.g. \"maize\", \"wheat\", \"coffee green\")."New value: +"Commodity name to profile (e.g. \"maize\", \"wheat\", \"coffee green\"). Matched by relevance; the 5 best-matching items are folded into one profile, so a broad name such as \"milk\" is narrowed — the response discloses how many items matched in total." - added
Output schema / properties / itemsTruncatedAdded value: +{ + "description": "True when the commodity name matched more items than the profile folded in — the profile then covers only the most relevant few.", + "type": "boolean" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Names any required domain that was not indexed, or other partial-result context."New value: +"Names any required domain that was not indexed, item-resolution truncation, mixed units in the rankings, or other partial-result context." - added
Output schema / properties / production_trendAdded value: +{ + "description": "The annual production series for the resolved commodity, summed over countries and items per year and ordered oldest-first. Aggregated in SQL over the complete filtered match, so it is not affected by the canvas staging cap.", + "items": { + "additionalProperties": false, + "description": "One annual trend point.", + "properties": { + "flags": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Distinct data-quality flags across the summed observations, comma-separated and sorted — 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; treat any unrecognized flag as informational, never assume official. Null when no summed observation carried a flag. More than one flag means the total mixes data qualities." + }, + "observations": { + "description": "Observations summed into value — read it alongside value, since a change in coverage moves the total independently of production.", + "type": "number" + }, + "unit": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Unit of measure for value; null when unspecified. Points are grouped by unit, so a year can appear once per unit rather than summing incomparable quantities." + }, + "value": { + "description": "Production summed across every country and resolved item reporting that year.", + "type": "number" + }, + "year": { + "description": "Observation year.", + "type": "number" + } + }, + "required": [ + "year", + "value", + "observations", + "unit", + "flags" + ], + "type": "object" + }, + "type": "array" +} - added
Output schema / properties / resolvedItemMatchesAdded value: +{ + "description": "Total items the commodity query matched in QCL, before the 5-item profile cap.", + "type": "number" +} - changed
Output schema / properties / table_name / descriptionPrevious value: -"Canvas table holding the merged production+trade observations (present when spilled)."New value: +"Canvas table holding the staged observations — production plus trade when the trade domain (TCL) is indexed, production only when it is not (present when spilled). The notice names which of the two the table holds." - changed
Output schema / properties / top_exporters / descriptionPrevious value: -"Top exporters by export quantity (empty when trade is not indexed)."New value: +"Top exporters by summed export quantity (empty when trade is not indexed)." - removed
Output schema / properties / top_exporters / items / properties / flagRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Data-quality 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; treat any unrecognized flag as informational, never assume official. Null when unflagged." -} - added
Output schema / properties / top_exporters / items / properties / flagsAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Distinct data-quality flags across the summed observations, comma-separated and sorted — 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; treat any unrecognized flag as informational, never assume official. Null when no summed observation carried a flag. More than one flag means the total mixes data qualities." +} - added
Output schema / properties / top_exporters / items / properties / observationsAdded value: +{ + "description": "Observations summed into value — one per resolved item reporting that year.", + "type": "number" +} - changed
Output schema / properties / top_exporters / items / properties / unit / descriptionPrevious value: -"Unit of measure; null when unspecified."New value: +"Unit of measure for value; null when unspecified. Rows are grouped by unit, so values in different units are never summed together — a country can appear once per unit." - changed
Output schema / properties / top_exporters / items / properties / value / descriptionPrevious value: -"Export quantity in the latest year present."New value: +"Export quantity summed across the resolved items for this country, in its latest reporting year." - changed
Output schema / properties / top_exporters / items / properties / year / descriptionPrevious value: -"The latest year the ranking is drawn from."New value: +"This country's own latest year with data, computed per country — a country whose series ends earlier still ranks, at its own last reported year." - changed
Output schema / properties / top_exporters / items / requiredPrevious value: -[ - "area_code", - "area", - "value", - "unit", - "year", - "flag" -]New value: +[ + "area_code", + "area", + "value", + "observations", + "unit", + "year", + "flags" +] - changed
Output schema / properties / top_importers / descriptionPrevious value: -"Top importers by import quantity (empty when trade is not indexed)."New value: +"Top importers by summed import quantity (empty when trade is not indexed)." - removed
Output schema / properties / top_importers / items / properties / flagRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Data-quality 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; treat any unrecognized flag as informational, never assume official. Null when unflagged." -} - added
Output schema / properties / top_importers / items / properties / flagsAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Distinct data-quality flags across the summed observations, comma-separated and sorted — 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; treat any unrecognized flag as informational, never assume official. Null when no summed observation carried a flag. More than one flag means the total mixes data qualities." +} - added
Output schema / properties / top_importers / items / properties / observationsAdded value: +{ + "description": "Observations summed into value — one per resolved item reporting that year.", + "type": "number" +} - changed
Output schema / properties / top_importers / items / properties / unit / descriptionPrevious value: -"Unit of measure; null when unspecified."New value: +"Unit of measure for value; null when unspecified. Rows are grouped by unit, so values in different units are never summed together — a country can appear once per unit." - changed
Output schema / properties / top_importers / items / properties / value / descriptionPrevious value: -"Import quantity in the latest year present."New value: +"Import quantity summed across the resolved items for this country, in its latest reporting year." - changed
Output schema / properties / top_importers / items / properties / year / descriptionPrevious value: -"The latest year the ranking is drawn from."New value: +"This country's own latest year with data, computed per country — a country whose series ends earlier still ranks, at its own last reported year." - changed
Output schema / properties / top_importers / items / requiredPrevious value: -[ - "area_code", - "area", - "value", - "unit", - "year", - "flag" -]New value: +[ + "area_code", + "area", + "value", + "observations", + "unit", + "year", + "flags" +] - changed
Output schema / properties / top_producers / descriptionPrevious value: -"Top producers by production value (countries only)."New value: +"Top producers by summed production (countries only)." - removed
Output schema / properties / top_producers / items / properties / flagRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "description": "Data-quality 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; treat any unrecognized flag as informational, never assume official. Null when unflagged." -} - added
Output schema / properties / top_producers / items / properties / flagsAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Distinct data-quality flags across the summed observations, comma-separated and sorted — 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; treat any unrecognized flag as informational, never assume official. Null when no summed observation carried a flag. More than one flag means the total mixes data qualities." +} - added
Output schema / properties / top_producers / items / properties / observationsAdded value: +{ + "description": "Observations summed into value — one per resolved item reporting that year.", + "type": "number" +} - changed
Output schema / properties / top_producers / items / properties / unit / descriptionPrevious value: -"Unit of measure; null when unspecified."New value: +"Unit of measure for value; null when unspecified. Rows are grouped by unit, so values in different units are never summed together — a country can appear once per unit." - changed
Output schema / properties / top_producers / items / properties / value / descriptionPrevious value: -"Production value in the latest year present."New value: +"Production summed across the resolved items for this country, in its latest reporting year." - changed
Output schema / properties / top_producers / items / properties / year / descriptionPrevious value: -"The latest year the ranking is drawn from."New value: +"This country's own latest year with data, computed per country — a country whose series ends earlier still ranks, at its own last reported year." - changed
Output schema / properties / top_producers / items / requiredPrevious value: -[ - "area_code", - "area", - "value", - "unit", - "year", - "flag" -]New value: +[ + "area_code", + "area", + "value", + "observations", + "unit", + "year", + "flags" +] - changed
Output schema / properties / trend_points / descriptionPrevious value: -"Count of production trend observations analyzed for the resolved commodity. Capped at the 50,000-row staging limit — when truncated is true this is a floor, not the true count."New value: +"Total production observations aggregated into production_trend. Exact — the aggregation runs over the complete filtered match, not a capped page." - changed
Output schema / properties / truncated / descriptionPrevious value: -"True when the producer ranking / trend and/or the staged canvas table were drawn from a set capped at the 50,000-row staging limit — treat the profile as a PARTIAL view and query faostat_query_observations directly (partitioned by year) for the complete series."New value: +"True when the STAGED CANVAS TABLE hit the 50,000-row staging cap and is therefore a PREFIX of the merged observation set — re-query faostat_query_observations partitioned by year to stage the rest. The rankings and production_trend above are SQL aggregates over the complete match and stay exact either way." - changed
Output schema / requiredPrevious value: -[ - "item_query", - "resolved_items", - "top_producers", - "top_exporters", - "top_importers", - "trend_points", - "spilled", - "truncated", - "resolvedItemCodes" -]New value: +[ + "item_query", + "resolved_items", + "top_producers", + "top_exporters", + "top_importers", + "production_trend", + "trend_points", + "spilled", + "truncated", + "resolvedItemCodes", + "resolvedItemMatches", + "itemsTruncated" +]
1 tool update
- Changed
faostat_list_domains9 fields changed- added
Input schema / properties / codeAdded value: +{ + "description": "Exact domain code lookup (e.g. \"RL\"), case-insensitive. Returns that one domain's full record on a single page. Takes precedence over `topic` / `indexed_only` when provided.", + "type": "string" +} - added
Input schema / properties / limitAdded value: +{ + "default": 20, + "description": "Maximum domains to return on this page (max 200 — above the catalog size, so raise it to fetch everything at once). Domain descriptions are long; the default keeps a browse call small.", + "maximum": 200, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / offsetAdded value: +{ + "default": 0, + "description": "Zero-based pagination offset into the matching domains (code-sorted). When the response reports truncated, pass the returned nextOffset here to fetch the next page. Ignored for exact-code lookups (always single-page).", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +} - added
Output schema / properties / nextOffsetAdded value: +{ + "description": "Offset to pass on the next call to fetch the following page. Present only when truncated is true; absent on the last page and for exact-code lookups.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Guidance when a topic filter matched nothing or no domains are indexed yet."New value: +"Guidance when a filter matched nothing, more pages remain, or no domains are indexed yet." - changed
Output schema / properties / totalCount / descriptionPrevious value: -"Total domains in the FAOSTAT catalog."New value: +"Total domains in the FAOSTAT catalog, independent of any filter." - added
Output schema / properties / totalMatchesAdded value: +{ + "description": "Domains matching the current filters, before the page limit is applied.", + "type": "number" +} - added
Output schema / properties / truncatedAdded value: +{ + "description": "True when more matches remain beyond the returned page — fetch them with nextOffset.", + "type": "boolean" +} - changed
Output schema / requiredPrevious value: -[ - "domains", - "totalCount", - "indexedCount" -]New value: +[ + "domains", + "totalCount", + "totalMatches", + "truncated", + "indexedCount" +]
2 tool updates
- Changed
faostat_commodity_profile3 fields changed- changed
Output schema / properties / top_exporters / items / properties / flag / descriptionPrevious value: -"Data-quality flag; null when unflagged."New value: +"Data-quality 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; treat any unrecognized flag as informational, never assume official. Null when unflagged." - changed
Output schema / properties / top_importers / items / properties / flag / descriptionPrevious value: -"Data-quality flag; null when unflagged."New value: +"Data-quality 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; treat any unrecognized flag as informational, never assume official. Null when unflagged." - changed
Output schema / properties / top_producers / items / properties / flag / descriptionPrevious value: -"Data-quality flag; null when unflagged."New value: +"Data-quality 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; treat any unrecognized flag as informational, never assume official. Null when unflagged."
- Changed
faostat_query_observations2 fields changed- changed
Input schema / properties / include_aggregates / descriptionPrevious value: -"When false (default), exclude aggregate-region rows (codes ≥ 5000) so sums are not double-counted. Set true for World/continent/grouping roll-ups. Ignored when explicit area_codes are passed."New value: +"When 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." - changed
Output schema / properties / observations / items / properties / flag / descriptionPrevious value: -"Data-quality flag (A=Official, E=Estimated, I=Imputed, B=break, X=external); null when unflagged."New value: +"Data-quality 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; treat any unrecognized flag as informational, never assume official. Null when unflagged."
1 tool update
- Changed
faostat_resolve_codes6 fields changed- changed
Input schema / properties / domain / descriptionPrevious value: -"FAOSTAT domain code to verify the index is ready (e.g. \"QCL\"). Dimension code lists (areas, items, elements) are shared across all indexed domains."New value: +"FAOSTAT domain code (e.g. \"QCL\"). Item and element resolution is scoped to the codes present in this domain's data; area code lists are shared across all indexed domains." - added
Input schema / properties / offsetAdded value: +{ + "default": 0, + "description": "Zero-based pagination offset into the match set. When the response reports truncated, pass the returned nextOffset here to fetch the next page. Ignored for exact-code lookups (always single-page).", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +} - added
Output schema / properties / nextOffsetAdded value: +{ + "description": "Offset to pass on the next call to fetch the following page. Present only when truncated is true; absent on the last page and for exact-code lookups.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Guidance when nothing matched or the dimension is not yet indexed."New value: +"Guidance when nothing matched, more pages remain, or the dimension is not yet indexed." - changed
Output schema / properties / totalMatches / descriptionPrevious value: -"Total matches before the result cap."New value: +"Total matches in this domain before the result cap." - changed
Output schema / properties / truncated / descriptionPrevious value: -"True when matches were capped at the limit."New value: +"True when more matches remain beyond the returned page — fetch them with nextOffset."
1 tool update
- Changed
faostat_query_observations1 field changed- changed
Output schema / properties / totalCount / descriptionPrevious value: -"Total observations matched before any inline cap."New value: +"Observations matched. Exact when the result was returned inline or fully staged; when the match set exceeded the 50,000-row staging cap this is that cap — a floor, not the exact count (truncated is then true)."
3 tool updates
- Changed
faostat_commodity_profile4 fields changed- added
Output schema / properties / staged_row_countAdded value: +{ + "description": "Rows actually staged on the merged canvas table (present when spilled). Equals the 50,000-row cap when truncated.", + "type": "number" +} - changed
Output schema / properties / trend_points / descriptionPrevious value: -"Count of production trend observations staged for the resolved commodity."New value: +"Count of production trend observations analyzed for the resolved commodity. Capped at the 50,000-row staging limit — when truncated is true this is a floor, not the true count." - added
Output schema / properties / truncatedAdded value: +{ + "description": "True when the producer ranking / trend and/or the staged canvas table were drawn from a set capped at the 50,000-row staging limit — treat the profile as a PARTIAL view and query faostat_query_observations directly (partitioned by year) for the complete series.", + "type": "boolean" +} - changed
Output schema / requiredPrevious value: -[ - "item_query", - "resolved_items", - "top_producers", - "top_exporters", - "top_importers", - "trend_points", - "spilled", - "resolvedItemCodes" -]New value: +[ + "item_query", + "resolved_items", + "top_producers", + "top_exporters", + "top_importers", + "trend_points", + "spilled", + "truncated", + "resolvedItemCodes" +]
- Changed
faostat_dataframe_query3 fields changed- changed
Output schema / properties / row_count / descriptionPrevious value: -"Total rows the query produced (may exceed rows.length when capped)."New value: +"Rows returned in this response — the materialized count, equal to rows.length. When truncated is true this is NOT the full result total (this path computes no exact total); page or aggregate to reach the rest." - added
Output schema / properties / truncatedAdded value: +{ + "description": "True when row_limit capped the result and more rows exist than were returned. To reach them: page with ORDER BY + SQL LIMIT/OFFSET, raise row_limit (max 10000), or aggregate with GROUP BY.", + "type": "boolean" +} - changed
Output schema / requiredPrevious value: -[ - "columns", - "row_count", - "rows" -]New value: +[ + "columns", + "row_count", + "rows", + "truncated" +]
- Changed
faostat_query_observations3 fields changed- added
Output schema / properties / staged_row_countAdded value: +{ + "description": "Rows 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.", + "type": "number" +} - added
Output schema / properties / truncatedAdded value: +{ + "description": "True 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.", + "type": "boolean" +} - changed
Output schema / requiredPrevious value: -[ - "domain", - "observations", - "spilled", - "totalCount" -]New value: +[ + "domain", + "observations", + "spilled", + "truncated", + "totalCount" +]
6 tool updates
- First observed
faostat_commodity_profile - First observed
faostat_dataframe_describe - First observed
faostat_dataframe_query - First observed
faostat_list_domains - First observed
faostat_query_observations - First observed
faostat_resolve_codes
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.
Eurostat MCP — wraps Eurostat Statistical Data API (no auth required)
Query SEC EDGAR filings, XBRL financials, and company data through MCP. STDIO & Streamable HTTP.
World Bank MCP — wraps the World Bank Data API v2 (free, no auth)
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceMCP server that exposes SQLite datasets as queryable tools and resources via Streamable HTTP, enabling read-only exploration and SQL queries.Apache 2.0
- AlicenseNot gradedqualityBmaintenanceProvides an MCP server for querying and managing Monarch Money personal finance data through a local SQLite mirror with read-only SQL access. It enables users to sync transaction history from the Monarch API and analyze accounts, categories, and tags.1MIT
- FlicenseNot gradedqualityCmaintenanceCustom MCP server connected to a read-only SQLite database, exposing a schema resource and a query tool for safe data retrieval.-
- AlicenseAqualityBmaintenanceLocal-first MCP server for discovering, downloading, and analyzing official IBGE microdata using DuckDB and Parquet.221MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
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.
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.
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.
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.