Skip to main content
Glama
Sign In
xippios-mcp

xippios-mcp

by xippios
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

usda_psd_list_commodity_attributes

Read-onlyIdempotent

List USDA PSD commodity attributes with their IDs and filter by name or ID to identify the correct attribute for data records.

Instructions

List PSD's commodity attributes with their ids, the attribute_id of every data record.

Answered from PSDData_GetCommodityAttributes as packaged with this version (reference/commodityAttributes.json), without an upstream call: 85 attributes when packaged, in upstream order, e.g. 28 Production, 57 Imports, 88 Exports, 176 Ending Stocks. Names are not unique: "Total Disappearance" is 126 and 173, "Fresh Dom. Consumption" 133 and 135; the id tells them apart. enums.AttributeId names the same ids. meta.retrieved_at is when the package fetched the list (2026-10-28, UTC); meta.vintage is empty, as upstream gives the list no release identifier.

Args: search: Keep the attributes where this text occurs, ignoring case, in the id (as digits) or the name, e.g. "stocks", "disappearance" (126 and 173 Total Disappearance, 151 Other Disappearance), "28" (28 Production, and 128 Dom. Leaf Consumption: the id matches as text). Omit (None) for all.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "usda_psd_list_commodity_attributes"
  }
}

Input Schema

NameRequiredDescriptionDefault
searchNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

The annotations already declare readOnly, idempotent, non-destructive, but the description adds real context: the data comes from a packaged reference file with no upstream call, contains 85 attributes in upstream order, and includes meta.retrieved_at (2026-10-28) with an empty meta.vintage. It also warns that names are not unique and ids disambiguate, which is behavioral detail found nowhere in the structured fields. Minor tension with openWorldHint=true, since the description says the list is static and packaged, but not enough to call a contradiction.

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, followed by source and caveat detail. It is longer than strictly necessary, with some redundancy in restating the non-unique-name example twice (in prose and inside the search examples), but nearly every sentence adds usable 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 one optional parameter, no output schema, and annotations covering safety, the definition is nearly complete: it describes the returned fields (id, name), the meta envelope fields, and the enums.AttributeId cross-reference. Only a fuller sketch of the response envelope would close the remaining gap.

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 whole burden for the single search parameter, and it does: case-insensitive substring matching against the id (as digits) or the name, with worked examples including the gotcha that '28' also matches 128 Dom. Leaf Consumption, and that None returns everything. That is more than the schema could convey.

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?

States a specific verb and resource: 'List PSD's commodity attributes with their ids, the attribute_id of every data record.' That distinguishes it from siblings such as usda_psd_list_commodities and usda_psd_get_data without needing their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the description explains that every data record carries an attribute_id, which suggests this list is the lookup for attribute-based queries, and the search arg says omit for all. However, it never explicitly says when to use this versus usda_psd_get_data or the other list_* siblings, so the agent must infer the routing.

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