Get Amdrs

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

With no annotations, the description carries the full behavioral burden. It helpfully discloses the conceptual nature of the data (ranges as percent of total energy) and enumerates the supported age groups, but says nothing about caching behavior, latency, or what happens when an unsupported age range is passed; the force_refresh semantics live only in the schema.

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

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

The description is front-loaded with a one-line purpose statement, then definition, then available inputs, then use cases, so the agent can stop reading early. The five 'Use this tool when' bullets are somewhat generic and could be trimmed, but each is short and the structure is easy to scan.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the description covers purpose, valid inputs, and application contexts for a simple read-only reference lookup. The remaining gap is behavioral detail around caching and invalid-input handling, which is minor for a static lookup tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and there is effectively one nested parameter, so the baseline is 3. The description still earns credit by enumerating all three valid age groups (1-3 years, 4-18 years, 19 years and over) with qualitative labels, which is slightly more exhaustive than the schema's two 'e.g.' examples and reduces the chance of an invalid string.

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

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

The first sentence names a specific verb and resource (get AMDRs) and scopes it to an age group, and the expanded acronym plus the list of returned ranges makes clear this is a percentage-of-energy reference lookup. This implicitly separates it from the many DRI-table siblings, but no sibling is named explicitly, so differentiation is inferential rather than stated.

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

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

A dedicated 'Use this tool when' block lists five concrete scenarios (dietary pattern evaluation, meal planning, education materials, guideline development), which gives the agent solid positive routing signals. There is no when-not guidance and no pointer to the DRI siblings that an agent might confuse with this one, which keeps it short of a 5.

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