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

With no annotations provided, the description carries the full behavioral disclosure burden. It discloses that the data is backed by a daily cron (implying freshness limits) and that at least one active Ampel is required, which are non-obvious operational constraints. However, it does not mention whether the operation is read-only, what happens on missing data or invalid combinations, or any error conditions. These gaps are significant for a tool with zero annotation coverage, though the disclosed constraints do add value.

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 two sentences and front-loads the core purpose with a direct question. The cron dependency and active-Ampel requirement are included compactly, and the [Free tier] tag is a briefnote. It is efficient and well-structured, though the question format is slightly informal; it still 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?

For a simple read-only tool with three required parameters and no output schema, the description covers the core concept and key dependencies. However, it omits expected return format (e.g., a color string, structured object) and behavior when no signal is available or when the combination is invalid. Given the lack of an output schema, these details would be valuable for correct invocation. The description is adequate but not complete.

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 100%, so each parameter (pair, interval, strategy) already has a description, including a detailed explanation of interval alignment and its impact on CAGR. The tool description adds the signal color concept (green/yellow/red) but does not elaborate on parameter formats or constraints beyond what the schema provides. The baseline 3 applies because the schema does the heavy lifting; the description provides marginal additional insight.

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 states a specific verb ('signalling buy or sell') and a well-defined resource ('signal-status (green/yellow/red) for a strategy on a pair+interval'). It clearly differentiates from sibling tools like arena_get_signal_context (which implies broader context) and arena_get_bullmarket_ampel (which targets a different signal type) by focusing on the current per-strategy signal state. The phrase 'Is this strategy signalling buy or sell right now?' is an immediate, unambiguous statement of purpose.

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 gives no guidance on when to use this tool versus alternatives. It mentions the cron dependency and the need for an active Ampel, but these are prerequisites, not usage directions. It does not state, for example, 'use this for a quick status check, use arena_get_signal_context for detailed explanations' — leaving the agent to infer appropriate invocation context from the sibling names alone.

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