health

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

With no annotations, the description carries the full burden of behavioral disclosure and does not meet it. It does not say whether the check makes live network calls to adapters (potentially slow or rate-limited), whether it is read-only, what constitutes pass/fail, or what happens when a source is unreachable. The output schema covers the return shape, but the operational character of the call remains unexplained.

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 clause that labels the tool type ('Kanarya testleri') before the specifics. There is no padding, though the brevity is partly the cause of the missing parameter and usage guidance rather than a virtue in itself.

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 output schema means return values need not be described, and the core intent is conveyed. However, for a diagnostic tool with an undocumented optional filter and no annotations, the description leaves the agent unable to predict cost, side effects, or how 'source' affects the check. Adequate as a minimum-viable definition, not sufficient for confident invocation.

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% for the single parameter 'source', which is optional with a null default, so the description must compensate and does not mention it at all. An agent cannot tell whether 'source' narrows the canary check to one adapter, names an adapter identifier, or accepts a URL. This is the most consequential gap: a wrong value here likely yields a misleading 'healthy' result.

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 names a concrete check: canary tests verifying that adapters can pull the latest observations from critical series. This is a specific activity that distinguishes it from sibling data-access tools like fetch_series or discover_series, though it never explicitly contrasts itself with them. The generic name 'health' is rescued by the description, but the connection between 'health' and 'canary test of adapters' requires the reader to bridge it.

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?

There is no statement of when an agent should call this versus fetch_series or list_sources, no prerequisites, and no exclusions. An agent can infer it is a diagnostic/validation call, but nothing confirms that inference or tells it what to do with a failing result. No alternatives are mentioned.

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