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

With no annotations, the description carries the full behavioral burden and mostly does: it explains the index construction, the units ('standard deviations from average 13-week growth', 0 = average), and the scope of the bulk-read behavior. It omits auth/permission needs, rate limits, and response shape, which is a gap for a zero-annotation tool but the semantic disclosure is unusually strong.

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?

A single front-loaded paragraph that opens with the resource and its nature, then usage rules, then the coverage list. The input-data enumeration ('electricity demand, freight, travel, card spending, jobless claims and job postings') is somewhat long but earns its place by defining the index.

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?

For a 2-parameter, no-output-schema read tool, the description covers purpose, units, semantics of the zero value, bulk-vs-single behavior, and the full set of valid economies. Missing return-format detail is acceptable absent an output schema, though permissions and limits are unaddressed.

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%, so 3 is the baseline, but the description adds meaning beyond the schema by explaining that omitting economy returns the latest reading for every economy while specifying one returns that economy's weekly history. The weeks parameter's effect on history depth is only lightly addressed.

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 uses a specific resource name ('Weekly Economic Pulse: weekly economic activity index') and defines it as a momentum gauge built from named high-frequency inputs, with the crucial clarification that it is 'not a GDP forecast'. It does not explicitly name which sibling (e.g. get_nowcast or get_aggregate) to prefer, so differentiation is left partly implicit.

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?

It gives concrete conditional usage: 'Omit economy for the latest reading of every covered economy; give one for its weekly history', which tells the agent exactly how to steer the call. It stops short of naming alternative sibling tools or when not to use this one.

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