Skip to main content
Glama

usda_psd_get_time_series

Read-onlyIdempotent

Retrieve USDA PSD time-series data for a commodity and country across market years, optionally limited to selected attributes, returning upstream records without gap filling.

Instructions

One country's PSD figures for a commodity over a range of market years.

One request to PSDData_GetCountryCommodityDataByYear per market year, oldest first, at the client's pace of one request per second, and each counts against api.data.gov's quota of 1,000 requests per hour per key: 2021 to 2023 is three requests and about three seconds, 1960 to 2026 sixty-seven, so ask for the years you need; a range of more than 100 market years is refused. Of each answer the records of the attributes asked for, or all of them when attribute_id is omitted, are kept exactly as upstream sent them, ordered by market year and within a year in upstream's order: value is in its unit_id, and calendar_year and month name the release that last revised that year, which may differ from year to year. A market year PSD has no data for (its empty HTTP 404, recorded for 1900), or whose answer has no record for the attributes, is absent from the list: no gap is filled, nothing interpolated, no error raised; a range without any record is an empty list. A year beyond PSD's forecasts is expected to answer the same 404 (not recorded) and still costs its request. Any other error, the gateway's own 404 included, is raised. meta.vintage is the latest release across the records ("2026-07"); meta.published_at stays empty. Codes, every attribute id, both years and the range are checked before the first request.

Args: commodity_code: PSD commodity code, seven digits, e.g. "0410000" (Wheat), "0440000" (Corn), "2222000" (Oilseed, Soybean). country_code: PSD country code (not ISO), e.g. "US" (United States), "BR" (Brazil), "E4" (European Union). start_year: First PSD market year, 1960 or later (PSD: "PSD Database has data for most commodities since year 1960"), e.g. 2021. end_year: Last PSD market year, included, e.g. 2023; not before start_year and at most 99 years after it. No other bound. attribute_id: PSD attribute id, or a list of them, e.g. 28 (Production), [28, 88] (Production and Exports), 176 (Ending Stocks); list_commodity_attributes lists them. Omit it (None) for every attribute of each answer, 15 a year for wheat in the United States. An empty list is refused.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "commodity_code": "<commodity_code>",
      "country_code": "<country_code>",
      "start_year": "<start_year>",
      "end_year": "<end_year>"
    },
    "name": "usda_psd_get_time_series"
  }
}

Input Schema

NameRequiredDescriptionDefault
end_yearYes
start_yearYes
attribute_idNo
country_codeYes
commodity_codeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Far beyond the readOnly/openWorld/idempotent annotations, it discloses the request mechanics (one upstream call per market year, oldest first, throttled to one request per second), the 1,000/hour api.data.gov quota, and that a 1900-sample range costs 67 requests. It also spells out failure semantics precisely: empty upstream 404s and attribute-less years are silently absent, nothing is interpolated, an all-empty range yields an empty list, and other errors (including the gateway's own 404) are raised.

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 lead sentence is a model of front-loading, and nearly every clause adds operational value (quota, throttling, gap semantics). It is nonetheless dense and long, with some detail repeated across the prose and the Args block, such as the 404/forecast-year behavior and the 'no gap filled' restatement.

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 five-parameter, network-bound, quota-limited tool with no output schema, the definition covers cost, ordering of output records, unit and calendar_year/month semantics, meta.vintage versus an empty meta.published_at, and validation-before-request behavior. There is no output schema, so return shape is appropriately described in prose, and nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description carries the full burden and does so: concrete PSD codes with examples for each parameter, non-ISO country codes, year bounds (1960 floor, end_year inclusive, max 99 years after start), and attribute_id accepting an int or list with sample ids (28, 88, 176) and explicit behavior for None versus an empty list.

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 opening sentence states a specific verb and resource with full scope: one country's PSD figures for a commodity across a range of market years. It is immediately distinguishable from world-level or balance-sheet siblings by the explicit 'one country' framing plus the single-commodity, multi-year shape.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete when-to-use guidance ('ask for the years you need', bounded at 100 market years) and routes attribute discovery to ``list_commodity_attributes``. It does not explicitly contrast itself with siblings such as ``usda_psd_get_data`` or ``usda_psd_get_world_data``, so the agent must infer when this narrow per-country time-series is preferred.

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