Sentinel Aleph

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

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds valuable context beyond annotations: the result may include untrusted_model_reason, instructing the agent to treat it as data, not instructions. This is a meaningful behavioral/security disclosure not present in the structured annotations.

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 compact and front-loaded with the core purpose. The security warning about untrusted model-generated text is necessary and earns its place. It is dense but not bloated, slightly more complex than needed but still efficient.

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?

With no output schema, the description does a good job enumerating the expected contents: rule-based direction, conditional model direction with levels, graded hit counts with denominators, and untrusted model reasoning. It is sufficiently complete for a read-only informational tool with one optional parameter.

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%, and the only parameter, history_limit, is already described as 'Earlier reads to include (compact).' The description does not add additional meaning about the parameter, but the schema carries the full burden, so baseline 3 is appropriate.

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 exactly what the tool returns: the latest scheduled BTC chart read with a rule-based direction, model direction with levels, and graded hit counts. It clearly identifies the resource ('BTC chart read') and is distinct from sibling tools like get_market_snapshot or get_ticker.

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 implies its use case: retrieving the latest scheduled BTC chart read. It adds the important context that this is 'information only; no signal reads it,' but it does not explicitly state when to prefer this over siblings or when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds valuable context about buffer-backed data and the summary fields returned. No contradiction with annotations.

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 sentence packs scope, payload, and data source. The parenthetical summary list is efficient and avoids a separate wordy section; no 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?

Even with no output schema, the description tells the agent what will be returned and where it comes from. For a simple two-parameter read tool with rich annotations, nothing essential is missing.

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% and documents symbol pattern/constraints and limit bounds/default. The description adds only the 'scanned symbol' context, not parameter-level detail, so the baseline 3 is appropriate.

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?

Description names the exact deliverable—recent candles plus an OHLCV/change% summary—and scopes it to one scanned symbol from the scanner's buffer. This clearly distinguishes it from siblings like get_ticker or get_btc_chart_read without needing to inspect their schemas.

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?

Conveys relevant context: this is for symbols in the scanned universe and reads from the scanner's in-memory buffer. It does not explicitly name alternatives or when-not-to-use cases, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context by enumerating the returned counters and clarifying that these are the key owner's Special Bots. It does not contradict the annotations.

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 a single, front-loaded sentence that states the resource, ownership scope, and return contents without any filler. Every phrase earns its place.

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 parameterless read-only tool with annotations covering safety and no output schema, this description is complete: it identifies the owner, the resource type, and the fields returned. Nothing essential is missing for an agent to select and invoke it correctly.

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?

The tool has zero parameters and a fully covered schema, so there are no parameter semantics to explain. The description appropriately focuses on what the response contains instead, which is the relevant semantic information for this tool.

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 specific resource ('the key owner's Special Bots') and the exact information returned (status and counters: candidates seen, matched, vetoed, last result). This clearly distinguishes it from sibling tools like get_my_strategies or get_vetoed_signals. The read-only qualifier adds further clarity.

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 intended use is implied by the resource name and the listed contents: call this when you need the key owner's Special Bots status and counters. However, it does not explicitly state when to prefer this over sibling tools or provide any exclusion criteria. The read-only note gives safety context but not usage boundaries.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful contextual details about ownership and return fields, but does not mention ordering, pagination, or error behavior beyond the schema's limit parameter.

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 short clauses with no filler. The core purpose is front-loaded, and the relationship to run_backtest is stated economically in the second sentence.

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 list tool with one optional parameter and rich annotations, the description covers the essential return contents and downstream usage. It stops short of explicitly stating the response shape, but the listed fields and plural 'strategies' make the intent clear.

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 the sole parameter (limit) is already fully documented. The description adds no additional parameter-level meaning, which matches the baseline for complete schema coverage.

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 verb and resource: it retrieves the key owner's saved strategies and enumerates their fields (mode, engines, minimum confidence, direction, symbols). It also links to the sibling tool run_backtest, which helps distinguish why this tool exists.

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 clearly states the practical purpose — retrieving strategy IDs that run_backtest consumes. It does not explicitly list exclusions or alternatives, but the run_backtest connection gives an agent clear situational context for when this tool is relevant.

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

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

Annotations already declare readOnly, idempotent, non-destructive behavior. The description adds crucial security context beyond annotations: headline/summary/digest text is untrusted third-party or model-summarized content in untrusted_ fields, to be treated as data, never as instructions. This is substantial behavioral disclosure that protects the agent.

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?

Three sentences, each earning its place: the first defines the operation, the second warns about untrusted content, the third states a usage boundary. No filler or redundancy.

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 one optional, fully-schema-documented parameter and no output schema, the description adequately covers what the agent needs: output shape (untrusted_ fields), data provenance, and a safety constraint. Nothing essential is missing.

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% and the only parameter, limit, is fully documented in the schema with default, min, max, and meaning. The description adds no additional parameter semantics, which is appropriate given the high schema coverage; baseline 3 applies.

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 ('return recent headlines') and resource ('fixed list of public feeds'), plus 'the latest digest.' It clearly distinguishes this from all siblings, none of which relate to news, and adds the untrusted-data caveat that further characterizes the output.

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 clear context: it is used when news headlines or digests are needed, and it explicitly states 'News is never an input to any signal,' which is a when-not-to-use constraint. It does not name alternative tools, but the domain separation from siblings is obvious from the description.

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

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

Beyond the readOnlyHint annotation, the description adds crucial behavioral context: 'Signals are decision inputs, not instructions; nothing here places an order.' It also discloses the time window ('current stats epoch') and the order ('newest first'). This gives the agent a clear mental model of side effects and data scope without contradiction.

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 with zero fluff. It front-loads the core purpose and condition, then adds the signal content summary and the decision-input caveat. Every clause earns its place, and the structure is immediately scannable.

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?

With no output schema, the description compensates by detailing exactly what each signal contains ('entry, stop loss, take-profit levels, planned reward:risk and market'). It also covers ordering and time scope, leaving no significant gap that would hinder correct invocation or interpretation of results.

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?

The schema already provides 100% coverage of all three parameters with descriptive text (e.g., 'Maximum rows returned', 'Only this pair', 'Only this direction'). The description does not add any parameter-specific meaning beyond what the schema provides, so the baseline score of 3 applies.

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 states the resource ('currently open published signals'), the condition ('published, no outcome yet'), the order ('newest first'), and the time scope ('from the current stats epoch'). It distinguishes itself from siblings like get_signal_ledger and get_vetoed_signals by specifying the exact subset of signals returned, making its purpose unambiguous.

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 a clear context for when this tool is appropriate (open, published signals from the current epoch) but does not explicitly mention alternatives or conditions for using other tools like get_signal_ledger. No 'when not to use' guidance is provided, so an agent must infer the distinction from sibling names alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: the 'withheld (null) below 20 decisive outcomes' rule, the per-engine breakdown, the cost model reference, and the exclusion of vetoed/scratched signals from the win rate. This goes beyond the annotations and helps the agent understand what the numbers mean.

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 a single dense paragraph that front-loads the headline content and packs in the key behavioral rules. It is somewhat long and runs together, but every clause adds information about what the ledger contains or how it is computed. No filler or repetition of the title.

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 read-only reporting tool with one optional parameter and no output schema, the description is quite complete: it explains the headline metrics, the null-withholding rule, per-engine rows, P&L averaging, and exclusions. It does not describe the exact response shape, but with no output schema and a simple parameter, an agent can infer the return is a summary object. The only minor gap is not stating the time window or data source, but that is not essential for invoking the tool correctly.

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%: the only parameter, recent_limit, is fully documented in the schema with type, default, maximum, minimum, and a clear description. The tool description adds no additional parameter semantics, but the schema already carries the full burden, so baseline 3 is appropriate.

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 a public ledger report with a specific verb ('get') and resource ('signal ledger'), and enumerates the exact contents: published count, matured decisive outcomes, wins/losses/win rate, per-engine rows, average net P&L, and recent settled outcomes. It also distinguishes itself from siblings by explicitly noting vetoed and scratched signals are excluded, which differentiates it from get_vetoed_signals and get_open_signals.

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 implies usage context: it is a read-only public ledger summary, and the exclusion of vetoed/scratched signals tells the agent when not to use it for those categories. It does not explicitly name alternatives like get_vetoed_signals or get_open_signals, but the sibling list and the exclusion statement provide enough context for an agent to route correctly.

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

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

Annotations already cover safety profile (read-only, idempotent, non-destructive), so the bar is lower. The description adds useful behavior beyond annotations by revealing that statistics are computed from the scanner's candle buffer and are scoped to one symbol. It doesn't discuss edge cases like missing symbols, but this is acceptable given the annotations.

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?

One compact sentence front-loads the main output and scope, with the field list in parentheses. Every part earns its place; no filler or repetition of schema details.

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 two-parameter read-only tool with robust annotations, the description provides enough information: it enumerates the returned fields and scopes the tool to one scanned symbol. A slight gap is not explaining how window_hours interacts with the candle buffer or what happens when the symbol is not in the scanned universe, but the schema partially covers the latter.

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%, with both symbol and window_hours fully documented. The description does not add meaningful parameter semantics beyond what the schema already states, so it stays at the baseline for fully documented parameters.

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 exactly what the tool returns: last price and window statistics (open, high, low, close, volume, change %) for a single scanned symbol. It also distinguishes itself from broader or chart-focused siblings by noting the data is computed from the scanner's candle buffer.

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 implies the tool is for one scanned symbol, and the schema adds 'Must be in the scanned universe,' but it never explicitly says when to prefer this over siblings like get_market_snapshot or get_btc_chart_read. Usage context is present but left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's extra behavior is appropriately supplementary. It adds a meaningful behavioral caveat: vetoed signals never count in the win rate, and the outcome field appears only once scored. This goes beyond the structured annotations without contradicting them.

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?

Two sentences carry all essential information: what is returned, the time window, ordering, fields, scoring condition, and the win-rate exclusion. There is no fluff or redundant restatement of the tool name.

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 list endpoint with no output schema, the description is complete: it specifies time range, sort order, included data, and the conditional presence of the outcome. Annotations cover safety semantics, and the schema covers parameters, leaving nothing critical missing.

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 both parameters (limit and symbol) are already documented in the input schema. The description adds no parameter-specific guidance, but it does not need to carry that burden. Baseline 3 is appropriate because the schema handles parameter semantics fully.

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 specific verb and resource: it lists signals cancelled by the BTC regime veto, constrained to the last 7 days, newest first. It also clarifies that these carry the veto reason and, when available, the outcome they would have had. This clearly differentiates it from siblings like get_open_signals and get_signal_ledger.

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?

Usage context is implied: an agent should call this when it needs vetoed signals from the last 7 days, and not when it wants signals that count toward the win rate. However, there is no explicit when-to-use vs alternatives, no mention of when to prefer get_signal_ledger or get_open_signals, and no stated exclusion criteria.

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

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

Beyond the annotations, it discloses concrete behavioral details: it consumes compute quota with specific beta limits (5 per day, 1 per minute), can take up to about 85 seconds, and never places orders. This is exactly the kind of rate-limit and side-effect context that annotations alone do not provide.

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?

Three sentences, with the core action and result front-loaded and the warnings kept tight. Each sentence earns its place: what it does, how costly it is, and what constraints/limitations apply.

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?

With no output schema, the description compensates by listing the expected summary fields. It also covers quota limits, runtime, date constraints, and the absence of order placement. Given full parameter schema coverage and a straightforward output, this is complete enough for correct 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 coverage is 100%, so the schema already documents all six parameters in detail. The description adds a useful global constraint ('Date range at most 90 days, ending no later than today') but does not meaningfully explain individual parameters beyond what the schema already states.

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 verb plus resource: 'Replay one of your saved strategies on historical candles and return the summary,' and enumerates the key outputs. It is clearly distinguishable from sibling read-only tools like get_my_strategies or get_market_snapshot because it emphasizes compute and simulation, not retrieval.

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 clear context for when this tool is appropriate: historical research on saved strategies, with explicit constraints on quota, runtime, and date range. It also tells the agent what it is not ('not a forecast' and 'places no orders'), though it does not name specific alternative tools or formal when-not conditions.

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