Skip to main content
Glama

usda_psd_get_balance_sheet

Read-onlyIdempotent

Retrieve a USDA PSD supply and distribution balance sheet for one commodity, country, and market year, with attribute values and units for analysis.

Instructions

One country's PSD supply and distribution of a commodity in a market year, as one record.

One request to PSDData_GetCountryCommodityDataByYear; its records, one per attribute, become the entries of attributes, keyed by the attribute's upstream name ("Production", "Imports", "Ending Stocks", 15 of them for wheat in the United States), in upstream order. Each entry carries attribute_id, unit_id, value, calendar_year and month exactly as the record had them. Units differ per attribute (wheat US: 1000 HA for area, 1000 MT for quantities, MT/HA for yield), so read each entry's unit_id (enums.UnitId). Nothing is derived, converted or renamed. Names are not unique upstream: an id whose name the packaged list gives to several ids ("Total Disappearance" is 126 and 173, "Fresh Dom. Consumption" 133 and 135) is always keyed with its id, "Total Disappearance (126)", so an id has the same key in every answer of a package version; an id the packaged list lacks is keyed "attribute <id>". Keys come from the packaged list: a reference refresh that renames an attribute, or adds an id under an existing name, changes keys and is a breaking change (conventions §12), recorded in the CHANGELOG. meta.vintage is the PSD release that last revised the figures ("2026-07"); meta.published_at stays empty, since PSD gives no day. Codes and the year are checked before the call. Valid codes without data (PSD answers an empty list) raise NotFoundError, a market year without data errors.NoDataForYear, both naming commodity, country and year.

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). For the world use get_world_data. market_year: PSD market year, e.g. 2023, 2022, 2021; data goes back to 1960 for most commodities.

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

Input Schema

NameRequiredDescriptionDefault
market_yearYes
country_codeYes
commodity_codeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior3/5

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

Adds substantial context beyond annotations: attribute keying rules for non-unique upstream names, per-attribute unit variance, meta.vintage/published_at semantics, and distinct NotFoundError vs NoDataForYear failures. Annotations already cover the read-only/idempotent profile, and the extra disclosure here is genuinely useful, but the score reflects that much of the text is key-name mechanics rather than operation-level behavior such as call cost or response size.

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?

Purpose is front-loaded in the first sentence and the Args block is cleanly separated. The middle paragraph is dense and sprawling, with parenthetical asides about duplicate attribute names that cost more words than the case warrants, though most of it earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 must describe the return shape itself, and it does: the attributes mapping, per-entry fields, and meta fields are all spelled out. Error conditions are covered. What remains thin is how to page or bound the response, which is moot for a single-record call.

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 coverage is 0%, so the description must carry the full burden and it does: commodity_code is specified as a seven-digit PSD code with three worked examples, country_code is flagged as not ISO with US/BR/E4 examples, and market_year is described with coverage back to 1960. That is enough to construct all three required values without further lookup.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb-free but precise scope: one country's PSD supply and distribution for a commodity in a market year, returned as a single record. It distinguishes from get_world_data explicitly and implicitly from the time-series sibling by fixing a single market year. It does not clearly contrast with usda_psd_get_data, which the name-similarity leaves ambiguous.

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?

Gives an explicit alternative for the world case ('For the world use get_world_data') and the single-country/single-year lens is stated clearly enough to select on. However, it never states exclusions against the other PSD data-retrieval siblings, so the agent must infer when a balance sheet beats a generic data pull.

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