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

With no annotations provided, the description carries the full burden and does so excellently. It discloses real-time status, emergency ETF fallbacks (SPY×10, QQQ×41, IWM×10), null behavior for DJIA, plausibility guards that null out-of-band values with an `error.implausible_value` field, and a 60s cache. This goes well beyond basic description.

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 dense and front-loaded with the core purpose, but the opening 'NOW WITH' is a changelog-style intro. The field-by-field detail is extensive and useful, yet the overall structure feels a bit sprawling. Every sentence adds value, so it earns a 4.

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?

The description thoroughly covers return fields, data sources, fallbacks, error handling, and caching—critical because no output schema exists. The only noticeable gap is the undocumented freshness parameter, which prevents full completeness.

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?

The description never mentions the single `freshness` parameter, and schema description coverage is 0%. The enum values (off, live, strict) are listed in the schema but their meaning is left undefined, so the agent cannot infer how they affect data freshness or caching.

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 description clearly identifies the tool as a 'cross-asset macro composite' that returns 'REAL underlying values' and enumerates specific fields (VIX, yields, USD indices, commodities, equity indices). This is a specific resource and scope, distinguishing it from generic or placeholder-data tools.

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?

The description implies usage for obtaining a quick, current macro snapshot by describing the composite and its freshness (60s cache), but it does not explicitly state when to prefer this over sibling tools like tengu_macro or tengu_v3_macro_treasury_curve. It only references the full credit series endpoint as an alternative for deeper credit data.

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