Skip to main content
Glama

usda_nass_get_prices_received

Read-onlyIdempotent

Fetch prices farmers received for a commodity by year, returning monthly and marketing-year averages for national or state series.

Instructions

Prices farmers received for a commodity in a year, monthly and marketing-year.

statisticcat_desc PRICE RECEIVED at domain_desc TOTAL, state or national, sorted by frequency and period: the marketing-year average first, then the months. The national series also carries the price as a percentage of parity (unit_desc "PCT OF PARITY") next to the dollar price; the column tells them apart.

Args: commodity: Upstream commodity_desc, e.g. "CORN", "SOYBEANS", "MILK", "CATTLE". year: Calendar year of the months, e.g. 2023. state: Two-letter state code for the state series; None returns the national series. frequency: FreqDesc.MONTHLY or FreqDesc.ANNUAL to keep one; None returns both.

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": "<commodity>",
      "year": "<year>"
    },
    "name": "usda_nass_get_prices_received"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearYes
stateNo
commodityYes
frequencyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

The annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. Beyond that the description adds real behavioral detail: results are sorted with the marketing-year average first then months, and the national series mixes in 'PCT OF PARITY' rows distinguishable by unit_desc, which an agent would otherwise misread as dollar prices.

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 and the filtering/sorting rules are front-loaded in the first paragraph, with the per-argument notes cleanly delegated to an Args block. The backtick-quoted upstream field names add some visual noise, but every sentence carries substantive information.

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 responsibly explains what comes back: a marketing-year average followed by monthly periods, plus parity-percentage rows in the national series. It does not describe the output columns or units beyond that, so an agent still learns the shape of results only partially, but the calling contract is complete.

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 must carry all four parameters, and it does: commodity as an upstream commodity_desc with examples (CORN, SOYBEANS, MILK, CATTLE), year as the calendar year of the months, state as a two-letter code with None meaning national, and frequency with its enum values and None meaning both. This fully compensates for the bare schema.

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 description states a precise verb and resource: it returns prices farmers received for a named commodity in a given year, explicitly scoped to statisticcat_desc 'PRICE RECEIVED' and domain_desc 'TOTAL' at state or national level. That slice is distinct from the production, acreage, and inventory siblings, so an agent can recognize the resource without opening the 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?

It gives concrete selection guidance: pass a two-letter state to get the state series or None for the national one, and pass FreqDesc.MONTHLY/ANNUAL to keep one frequency or None for both. It does not name an alternative tool or state when-not-to-use cases, so it stops short of full routing guidance.

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