check_temporal

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

With no annotations, the description carries the behavioral disclosure burden. It states the output size ('small') and the precise detection criteria, indicating a read-only sanity check. It does not explicitly rule out side effects, but the nature of the tool makes that implicit.

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 the tool's purpose and follows with a compact bullet-style list of detections. It is appropriately sized and avoids filler.

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 tool is moderately complex with three parameters and an output schema. The description covers detection behavior and output size, and the output schema can define return values. The meaning of 'Level 4' is left unexplained and source_id is underdescribed, but overall it's adequate.

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 0%, so the description must explain parameters. It explains time_column by specifying DATE/TIMESTAMP and mentions value_columns implicitly via 'per numeric column'. However, source_id is not described at all, leaving a semantic gap.

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 performing time-series sanity checks with a specific list of detections (gaps, monotonicity, sampling frequency, drift, seasonality). This distinguishes it from sibling check_* tools, which are general or target different data types. The verb 'Detects' makes the action explicit.

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 specifies a prerequisite (requires time_column of type DATE/TIMESTAMP) and implies it's for time-series data. However, it does not explicitly compare to alternatives like check_stability or plot_timeseries, so the guidance is clear but not exhaustive.

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