Skip to main content
Glama

usda_psd_get_data

Read-onlyIdempotent

Retrieve USDA PSD supply and distribution forecasts for a commodity and market year, optionally filtered by country, to compare production, trade, consumption, and stocks.

Instructions

PSD supply and distribution forecasts for one commodity and market year, by country.

One record per country and attribute (area, production, imports, exports, consumption, stocks, ...): attribute_id and unit_id are PSD's integer ids, which enums.AttributeId and enums.UnitId name; value is in that unit. Codes and the year are checked against the packaged lists before any call; an unknown code raises InvalidRequestError naming the closest ones. Each record's calendar_year and month are the PSD release that last revised it: for one country all records share one release, for every country they differ by country. meta.vintage is the latest of them as upstream names it ("2026-07"); meta.published_at stays empty, since PSD gives no day. An empty list means PSD has no records for that combination; a market year without data raises NotFoundError. Every country is up to about 1,900 rows (1,875 for corn in 2023).

Args: commodity_code: PSD commodity code, seven digits, e.g. "0410000" (Wheat), "0440000" (Corn), "2222000" (Oilseed, Soybean). market_year: PSD market year, e.g. 2023; data goes back to 1960 for most commodities. country_code: PSD country code (not ISO), e.g. "US" (United States), "BR" (Brazil), "E4" (European Union). Omit it (None) for every country: one record per country and attribute. For the world total use get_world_data.

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>",
      "market_year": "<market_year>"
    },
    "name": "usda_psd_get_data"
  }
}

Input Schema

NameRequiredDescriptionDefault
market_yearYes
country_codeNo
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?

Annotations already cover the safety profile (readOnly, idempotent, openWorld, not destructive), and the description still adds substantial behavioral context: row granularity (one record per country and attribute), the meaning of `calendar_year`/`month` as the revising release, `meta.vintage` vs the intentionally empty `meta.published_at`, and expected volume (~1,900 rows per country, 1,875 for corn in 2023). It also distinguishes failure modes — an empty list for no records versus `NotFoundError` for a market year without data, and `InvalidRequestError` for unknown codes.

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 purpose leads, followed by return-shape details, then an Args block — a sensible front-loaded structure with no filler sentences. It is dense and long, and a few clauses (the exact 1,875-row corn figure, the vintage-vs-published_at nuance) sit close to the edge of what earns its place, but each does convey usable information.

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?

With no output schema, the description properly compensates by explaining the record shape (attribute_id/unit_id integer ids, value in that unit) and the meta block. For a three-parameter read tool with strong annotation coverage, nothing an agent needs in order to call it correctly or interpret the response 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?

Schema description coverage is 0%, so the description carries the full burden and does so: `commodity_code` is seven digits with three concrete examples, `market_year` is illustrated with 2023 and notes data back to 1960 for most commodities, and `country_code` is explicitly called out as PSD-not-ISO with US/BR/E4 examples plus the None semantics. Every parameter gains meaning that the bare schema lacks.

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 names a specific verb-and-resource pair — PSD supply and distribution forecasts — plus the exact scope (one commodity, one market year, per country). The final sentence routes the world-total case to `get_world_data`, so an agent can distinguish this tool from its closest sibling without opening either schema.

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?

Explicit conditions are given: omit `country_code` (None) for every country, and use `get_world_data` instead for the world aggregate. What's missing is guidance on discovering valid codes (no pointer to `usda_psd_list_commodities`/`list_countries`) and no hint about when to prefer `get_time_series` or `get_top_countries`, so it stops short of a full when/when-not map.

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