Brighter

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

No annotations are provided, so the description must carry the full behavioral burden. It discloses the return granularity (daily closing prices) and scope (one asset, calendar year), but omits auth requirements, rate limits, adjustment details, and response format specifics. It partially compensates but leaves meaningful behavioral gaps.

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 what the tool does and its intended use. Every clause earns its place with no wasted words.

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 retrieval tool with full schema documentation and no output schema, the description conveys the returned data type and scope well. Edge cases like missing trading days or price adjustments are not covered, but the core information an agent needs is present.

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 schema fully documents both the ticker and year parameters. The description adds no meaningful syntax, format, or constraint details beyond loosely mapping to 'one asset' and 'calendar year', 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 names the resource and scope clearly: 'Daily closing prices for one asset over a calendar year'. This is specific enough for an agent to understand what the tool returns, but it does not explicitly differentiate itself from siblings like find_assets or backtest_strategy.

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 checking a rule's premise against what actually happened' gives a clear usage context against a rule-verification workflow. However, it does not name alternatives or state when not to use this tool, so it falls short of full when/when-not guidance.

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?

With no annotations, the description carries the full burden and does real work: it discloses that execution is against real prices, is not cached per call, and should be run deliberately, plus that only metrics are returned ('never the curve'). It is silent on runtime, cost/quota, and failure modes, so it is strong but not exhaustive.

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 tight sentences, front-loaded with purpose and immediately followed by the operational caveat and return-value scope. Every clause earns its place with 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?

For a simple two-parameter tool with no output schema, the description usefully compensates by stating that only metrics are returned and never the equity curve. The one remaining gap is sibling differentiation from backtest_strategy, which would matter for correct tool selection.

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% — 'code' is documented as the strategy in Brighter's language and 'range' as the test window with an enum — so the schema already carries the parameter meaning. The description adds no syntax, format, or validity guidance beyond it, making the baseline 3 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?

States a specific verb and resource ('Run a strategy you have written against real market history') and clarifies the nature of the execution (real prices, not a simulation). It does not, however, distinguish itself from the sibling 'backtest_strategy', which an agent must disambiguate on its own.

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?

Gives a concrete sequencing rule — run it deliberately, after check_strategy passes — which is actionable when-to-use guidance. It stops short of naming when to prefer this over the sibling backtest_strategy, so no explicit exclusion is provided.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses that out-of-range values are snapped rather than rejected, that results are compared against a benchmark, and that backtests are real/expensive — but it omits how costly, whether there are rate limits, or any auth/permission prerequisites.

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?

Four short sentences, front-loaded with the core action and then the return content, the snapping behavior, and a cost warning. Every sentence roughly earns its place, with only mild rhetorical padding in the last clause.

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 steps in to say results are "figures against its benchmark," and it covers the enum window behavior, default handling, and value snapping. For a 3-parameter tool with full schema coverage, this is nearly complete; only cost/limit specifics are 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 id, range, and params semantics are already documented (including the enum window values and the default-for-omitted-keys behavior). The description's range note ("only these are kept warm; anything else is refused") and the snapping rule add context but little that the schema doesn't already carry.

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 and resource: run a published strategy over real market history with chosen parameters. "Published strategy" implicitly separates it from the sibling backtest_code (which would run user-supplied code), though that sibling is not named explicitly.

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?

No explicit when-to-use or alternative routing; the closing "This is a real backtest, so make each one count" only implies the operation is costly and should not be spammed. An agent must infer that backtest_code is the alternative for custom logic.

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?

With no annotations, the description carries the full burden and does so well: it discloses that the call costs nothing, makes no upstream calls, and returns faults with line and column positions. That covers side-effect and cost profile, though it doesn't say whether the result is cached or how large inputs are handled.

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 compact sentences, front-loaded with what is validated, followed by the return shape and the cost/side-effect guarantee. Every sentence earns its place with 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?

There is no output schema and no annotations, yet the description supplies the essentials: no cost, no upstream calls, and a return value of faults with positions. For a stateless validation tool with one well-documented parameter, nothing needed to invoke it correctly 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% for the single required parameter, so the schema already documents `code`. The description adds no syntax or format detail about Brighter's language beyond restating that the code is written in it — 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?

States a specific verb (check) and resource (a strategy in Brighter's language), and enumerates the three things checked: syntax, semantics, and ticker tradability. This clearly distinguishes it from siblings like backtest_strategy, format_strategy, and dsl_reference.

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?

"check before you backtest" gives explicit sequencing guidance and implies the backtest_strategy sibling as the follow-on action. It stops short of naming the alternative tool or stating when checking is unnecessary, so it is clear context without full exclusions.

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?

No annotations are provided, so the description carries the behavioral burden alone. It signals this is a read-only lookup and that guessing the syntax costs a turn, but it never says what the reference actually returns or how it is structured (there is no output schema either). Adequate for a low-risk documentation fetch, but thin.

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, front-loaded with what the reference contains followed by the call-to-action. Both sentences earn their place, though the trailing rationale about wasting a turn is persuasion rather than specification.

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 doc-retrieval tool with no annotations and no output schema, the description covers purpose, contents, and when to read it. The only real gap is the absence of any signal about the shape or size of the returned reference, which an agent would need to plan context usage.

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 both optional booleans (limits, indicators) are already fully documented in the schema, including the default behavior of 'indicators'. The description adds no parameter-level meaning beyond that, which matches the baseline 3 for a high-coverage schema.

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 resource — the Brighter strategy DSL — and enumerates its coverage: blocks, indentation rules, indicators and limits. It is clearly distinguishable from siblings like strategy_schema or format_strategy, which operate on a strategy rather than describing the language.

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?

Gives explicit when-to-use guidance: 'Read this before writing any rule,' tied to a concrete reason (the syntax is small and specific). It does not name an alternative reference tool such as strategy_schema or explain when this is NOT needed, so it stops short of full when/when-not routing.

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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read/search operation but says nothing about pagination behavior (limit/offset), whether results are ordered, what a result contains, or how an empty query behaves — all relevant to a search tool with paging parameters.

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 short sentences, zero filler, and the asset scope is front-loaded ahead of the rule constraint. Nothing is redundant or buried.

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 4-parameter search tool with no annotations and no output schema, the description covers the domain and a key constraint but omits return shape, pagination behavior, and the semantics of calling it with no filters. Adequate but with clear gaps.

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 schema already documents query, tickers, limit, and offset; the baseline is 3. The description adds no parameter-level detail (e.g., query vs. exact-ticker lookup distinction, paging semantics) beyond what the schema provides.

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 (Search) and resource (assets a Brighter strategy can hold), then enumerates the asset universe (tokenized US stocks, ETFs, T-bills). It is clearly distinguishable from the sibling strategy/documentation tools, though it doesn't explicitly name a sibling to differentiate itself.

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?

"A rule may only name a ticker that appears here" gives a concrete condition for using this tool: validating tickers before authoring a rule. This is clear usage context, but it does not spell out when-not-to-use or name alternatives for looking up assets.

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?

No annotations are provided, so the description carries the full behavioral burden. It reveals that output is a rewritten canonical form, but says nothing about behavior on invalid or unparsable input, whether the operation is pure/read-only, or how errors surface — a meaningful gap for a transformation 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?

Two short sentences, with the core action front-loaded before the motivating use case. No filler, though the second sentence is somewhat colloquial rather than informational.

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 single-parameter tool with full schema coverage but no annotations and no output schema, the description covers the basic purpose adequately. However, it omits error behavior and the expected shape of the return value, which the absent output schema leaves undocumented.

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 single `code` parameter is documented as 'The strategy, in Brighter's language.' The description adds no syntactic or format detail beyond the schema, so the baseline 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?

States a specific verb (rewrite) and resource (strategy) plus the target form (the language's canonical spelling as shown in Studio's editor). It is distinguishable from siblings like get_strategy or check_strategy, though it does not explicitly contrast itself with the adjacent check_strategy tool.

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 'useful for checking that what you wrote means what you think it means' implies a validation/verification use case, but gives no explicit when-to-use versus alternatives such as check_strategy or strategy_schema, and no exclusions or prerequisites.

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?

Without annotations, the description carries the full behavioral burden. It usefully discloses that the value is a live target computed from the latest close and expressed in basis points, but it omits permissions, error cases, and how the optional params affect the result.

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 efficient sentences with no wasted words. The unit and freshness are front-loaded, and the key semantic distinction—live target versus historical or static rule—is stated immediately.

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?

There is no output schema and no annotations, so the description should carry more detail. It explains the unit and derivation but does not describe the return shape, how nested params influence the allocation, or what happens for an unpublished strategy.

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 both id and params are documented in the schema. The description adds no additional meaning or syntax for the parameters, which is the baseline when the schema already does the heavy lifting.

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 and scope: a published strategy's current rule-based allocation, expressed in basis points and based on the latest close. It does not explicitly distinguish itself from sibling tools such as get_strategy or check_strategy.

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?

No guidance is provided on when to use this tool instead of alternatives like get_strategy, check_strategy, or backtest_strategy. The description implies it returns a live allocation, but offers no context, prerequisites, or exclusions.

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?

No annotations are provided, so the description must carry the behavioral burden. It does describe the returned data shape in useful detail, but it does not state that the operation is read-only, nor does it mention authentication, rate limits, or error behavior for a simple getter.

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 tightly written sentences, front-loaded with what the tool returns, followed by a usage note. Every phrase adds value and there is 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?

For a single-parameter getter with no output schema, the description adequately covers the return fields (rule, parameters, assets, benchmark) and points to downstream use. It would be slightly stronger with an explicit read-only declaration, but no critical information 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?

There is only one parameter (id) and the schema fully documents it (100% coverage). The description adds no extra meaning for the id argument, and its remark about parameter keys refers to the strategy's tunable parameters, not to this tool's input. 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 a specific verb and resource: retrieves one strategy in full. It enumerates the returned content (rule, tunable parameters with ranges/defaults, assets, benchmark), clearly distinguishing it from sibling list_strategies. It also names backtest_strategy as a downstream consumer.

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 explicitly says to use the returned parameter keys with backtest_strategy, giving a clear use case. However, it does not directly compare this tool with alternatives like list_strategies or strategy_schema for other purposes, leaving some routing inference to the agent.

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?

With no annotations, the description carries full burden and does disclose meaningful default behavior: leveraged strategies are excluded by default, default sort is newest/best-performing, and each item reports cadence, holdable assets, and period-relative return versus benchmark. It omits auth requirements, pagination limits, and error behavior, keeping it below a 5.

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 tight sentences, front-loaded with the core action and scope; every sentence earns its place by describing returned fields or the default exclusion. 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?

The description compensates for the absent output schema by enumerating what each strategy carries, and all 8 params are schema-documented. It is largely complete for a listing tool, with only pagination and permission/response-shape context 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%, so the schema already documents all 8 parameters, making 3 the baseline. The description adds only light meaning beyond the schema, clarifying that sort is newest vs best-performing and that period governs the reported return, without adding format or interaction detail.

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 and resource: "List the strategies published on brighter.fi," and clarifies scope with default ordering and returned fields. It is clearly differentiated from a singular get/single-strategy tool by implication, but names no sibling explicitly, so it stops short of the top score.

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 line about leveraged/inverse strategies being excluded "unless asked for" gives a real usage cue by pairing with the leveraged param, and ordering hints at the sort enum. However, there is no explicit when-to-use-this-vs-alternatives guidance (e.g., vs get_strategy or find_assets), so usage is only implied.

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?

With no annotations, the description carries the burden and implies a static, read-only schema retrieval. It also adds comparative context about text alternatives being easier. However, it does not explicitly state the absence of side effects or describe the schema's format in detail.

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, front-loaded with the tool's purpose and followed by usage guidance. Every sentence earns its place with no 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 zero-param tool that returns a schema, the description covers what it is and when to use it versus alternatives. No output schema exists, so no further detail is required.

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?

There are zero input parameters, so the description need not document any. The baseline of 4 is appropriate for a parameterless 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 identifies the tool's output (JSON schema for a strategy as an object) and distinguishes it from siblings that accept text. It's specific but does not use an explicit verb like 'returns' or 'gets'.

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 explicitly states when to use this tool (when you would rather build the rule tree than write text) and names alternatives (check_strategy and backtest_code) that accept text, noting they are usually easier. This is clear when-to-use and when-not-to-use guidance.

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