Skip to main content
Glama
Sign In
xippios-mcp

xippios-mcp

by xippios
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

usda_nass_get_milk_production

Read-onlyIdempotent

Retrieves USDA NASS milk production in pounds by year, state or national, with monthly, quarterly, and annual breakdowns for production analysis.

Instructions

Milk produced in a year, in pounds, by month and quarter and for the year.

The milk production series, state or national (commodity_desc MILK, class_desc ALL CLASSES, statisticcat_desc PRODUCTION, unit_desc LB, domain_desc TOTAL, source_desc SURVEY; short_desc MILK - PRODUCTION, MEASURED IN LB); ALL CLASSES leaves out the manufactured dairy products (dry and condensed milk) that upstream files nationally under the same statistic and unit. Sorted by frequency, then period: the year first (freq_desc ANNUAL, reference_period_desc YEAR), then the months, each quarter (JAN THRU MAR, ...) after its first month, since upstream files months and quarters alike as MONTHLY. value is the quantity in pounds as published.

Args: year: Calendar year, e.g. 2024. state: Two-letter state code for the state series, e.g. StateAlpha.WI, StateAlpha.CA; None returns the national US TOTAL series. frequency: FreqDesc.MONTHLY (the months and quarters) or FreqDesc.ANNUAL (the year) to keep one; None returns both. FreqDesc.WEEKLY, FreqDesc.SEASON and FreqDesc.POINT_IN_TIME raise NotFoundError, since upstream files no milk production under them.

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": {
      "year": "<year>"
    },
    "name": "usda_nass_get_milk_production"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearYes
stateNo
frequencyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, open-world and non-destructive behavior, so the description earns credit for what it adds: the ordering guarantee (year first, then months with each quarter after its first month, because upstream files months and quarters alike as MONTHLY), the meaning of 'value' as pounds as published, and explicit error behavior. It doesn't discuss result size or how partial years are handled.

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?

Front-loaded with the one-line purpose, followed by series definition, ordering, value semantics, then an Args block — a sensible order with no filler sentences. The dense backtick-and-key-value formatting makes it heavier to read than necessary, and some of the series detail is duplicated between the prose and the Args section.

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 still explains the return semantics (value in pounds as published) and the row ordering, plus the error surface for unsupported frequencies. An agent has everything needed to call it correctly and interpret the result without opening anything else.

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% — the schema only labels the enums with provenance notes — so the description carries the full burden and does: year as a calendar year, state as a two-letter code with None meaning the national US TOTAL series, and frequency mapping MONTHLY to months-plus-quarters, ANNUAL to the year, None to both, with named failures for the other enum values.

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?

The opening sentence states a specific verb+resource+measure ('Milk produced in a year, in pounds, by month and quarter') and the body pins the exact upstream series filters (commodity_desc MILK, class_desc ALL CLASSES, statisticcat_desc PRODUCTION, unit_desc LB). That implicitly separates it from the generic usda_nass_get_production, but the description never names the alternative, so the differentiation must be inferred from the series definition.

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-not guidance: FreqDesc.WEEKLY, SEASON and POINT_IN_TIME raise NotFoundError because no milk production is filed under them, and state=None selects the national US TOTAL series. It also warns that ALL CLASSES excludes manufactured dairy products filed nationally under the same statistic. It stops short of routing the agent to a sibling tool for those excluded products.

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

Deploy Server

Other Tools