crux_history

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

No annotations are provided, so the description carries the full burden. It discloses only the temporal nature of the data ('historical') and implies read-only via 'Gets'. It says nothing about how far back data goes, time-range granularity, whether both url and origin can be supplied, API quota limits, or failure behavior — all material for a data-fetching tool.

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?

An 11-word single sentence with zero waste, front-loaded with the verb and resource. It is efficient, though the brevity trades away the parameters and alternatives value that other dimensions require.

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 tool with four undocumented parameters, zero annotations, and no output schema, a one-liner is not enough. The agent is left without param semantics, valid metric values, usage boundaries vs crux_query, or any sense of the return shape — gaps that the description was the only place to fill.

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 description coverage is 0% with four undocumented parameters, yet the description compensates not once by mentioning url, origin, metrics, or formFactor. An agent cannot know the difference between URL-level and origin-level CrUX data, which metrics are valid, or the meaning of the optional formFactor enum beyond its literal values.

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?

States a specific verb ('Gets') and resource ('historical Chrome UX Report data') plus an explicit purpose ('for trend analysis'). The word 'historical' differingentiates it at least implicitly from the sibling crux_query, though it never names that tool and leaves the contrast to inference.

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 phrase 'for trend analysis' provides implied usage guidance — an agent can infer it should be selected when historical/trend analysis is the goal rather than single-point queries. However, it gives no explicit when-not-to-use guidance and names no alternative (cRux_query, cWyv_report, psi_analyze), so the routing decision is left to the agent.

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