Skip to main content
Glama

usda_psd_get_latest_release

Read-onlyIdempotent

List the countries and market years a commodity's newest PSD release revised, and poll for changes since a stored release month to see whether updates exist.

Instructions

Which countries and market years PSD's newest release of a commodity revised.

One request to PSDData_GetDataReleaseInfo, which lists the last release of every country and market year (7,754 records for wheat); the records of the newest release_year and release_month are kept, unchanged and in upstream's order. For wheat as recorded on 2026-10-23 that was release 2026-10, 146 records: 123 countries for market year 2026 and a few revisions of earlier years. meta.vintage names the release ("2026-10") in the form meta.vintage of get_data takes, so a stored vintage older than it means the listed countries and market years have changed since. To poll, pass your stored vintage as since: the answer is the newest release's records when that release is later than since, and an empty list when it is not, with meta.vintage still naming the newest release, so an empty list says nothing newer exists. A commodity without any release gives an empty list and meta.vintage None; meta.published_at stays empty, since PSD gives no day. A release that adds a market year and revises earlier ones lists many records: the wheat list recorded on 2026-10-23 had 146 records of 2026-10 and 130 more still carrying 2026-09, so the September answer held between 130 and 276 rows. get_release_dates(commodity_code, market_year=..., country_code=..., since=...) returns any part of the list.

Args: commodity_code: PSD commodity code, seven digits, e.g. "0410000" (Wheat), "0440000" (Corn), "2222000" (Oilseed, Soybean). since: A release month "YYYY-MM", e.g. "2026-09", typically the meta.vintage you stored last time: the newest release's records come back only when that release is later (strictly after), else an empty list. None always returns the newest release's records.

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

Input Schema

NameRequiredDescriptionDefault
sinceNo
commodity_codeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (readOnly, idempotent, openWorld, non-destructive), the description discloses that records are returned unchanged and in upstream order, that the call is a single request to PSDData_GetDataReleaseInfo, what meta.vintage and meta.published_at contain, and how empty results should be interpreted. This is unusually rich operational context that annotations cannot supply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is well front-loaded, but the body is padded with illustrative counts (7,754 records, 146 records, 123 countries) and the sentence about the September answer holding 'between 130 and 276 rows' is confusing and arguably contradicts the stated single-release semantics. The polling contract is valuable; several numeric asides are not.

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 must explain the return shape, and it does: a record list plus meta.vintage, meta.published_at, and the empty-list / null-vintage cases. For a two-parameter read tool with annotations covering safety, nothing essential to correct invocation 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 coverage is 0%, so the description carries the full burden and does so: commodity_code is documented as a seven-digit PSD code with three concrete examples, and `since` is documented as YYYY-MM with strict-after comparison semantics and the None behavior. No parameter meaning is left to inference.

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 precise verb and resource: which countries and market years the newest PSD release of a commodity revised. It also implicitly separates the tool from usda_psd_get_release_dates, which is described as returning 'any part of the list', and from get_data, whose vintage format it references.

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 explicit polling instructions: pass your stored vintage as `since`, get the newest release's records only when that release is strictly later, an empty list otherwise, and an empty list plus a null vintage when no release exists. The alternative (get_release_dates for arbitrary slices) is named, though not framed as an explicit when-not-to-use rule.

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