SCRIPTMASTERLABS — Cascade Graph

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds determinism ('deterministic') and reinforces the no-side-effects contract, but says nothing about how evidence bounds the analysis or what happens on insufficient evidence.

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 with the operation front-loaded and the safety constraint immediately after. Nothing is padded, though the brevity comes at the cost of substance rather than being purely 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 an untyped array parameter, two required inputs, no output schema, and no annotations explaining return shape, the description leaves the most important caller question unanswered: what evidence format is required for the analysis to succeed. Adequate for a zero-param tool, not for this one.

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%, so the description carries the full burden for two required parameters — and it fails. It never explains what 'instrument' accepts (ticker, exchange-qualified symbol?) or what shape each 'evidence' array element must take, despite the array being untyped.

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 verb 'Run' and object 'market analysis' are identifiable, and 'Does not execute trades' clarifies the operation type. However, 'deterministic evidence-bounded' is opaque jargon, and nothing distinguishes this from siblings like cascade_capsule or cascade_status.

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 to choose this tool over cascade_capsule, cascade_review_jev, or cascade_status, nor any prerequisites or exclusions beyond the negative 'does not execute trades'. The agent must infer selection criteria from the name 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 readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description still adds real value by disclosing determinism (SHA256) and zero model spend, and the 'admitted state' precondition hints at a gating requirement, but it never explains what admission requires or what fails without it.

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, no filler, with the action front-loaded and the cost caveat trailing. It is tightly structured; the terseness is better counted against completeness than against conciseness.

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 tool with three undocumented required parameters and no output schema, the description should define what a Decision Capsule contains and what the caller must supply. It never describes the return value or the parameter expectations, leaving an agent unable to construct a correct call from the definition alone.

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?

All three required parameters (instrument, evidence, observed_at) have 0% schema description coverage, so the description carries the full burden and adds essentially nothing — no mention of instrument type, evidence shape, or timestamp semantics. The phrase 'from admitted Cascade state' is the only faint provenance hint.

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?

It pairs a specific verb (Build) with a named artifact (Decision Capsule) and a source (admitted Cascade state), but 'Decision Capsule' and 'admitted' are undefined jargon the agent cannot resolve without prior Cascade knowledge. Nothing in the sentence distinguishes it from cascade_analyze or cascade_review_jev, so purpose is only partially legible.

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 model spend' implicitly signals when to prefer this over a sibling that presumably incurs model cost, which is a usable but indirect selection cue. There is no explicit statement of when to use it, when not to, or which sibling it replaces, and no prerequisites are given for the 'admitted Cascade state' input.

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?

Goes well beyond the annotations: names the required X-JEV-API-KEY header, states that spend must be authorized, explains that deterministic vetoes short-circuit provider calls (cost behavior), and explicitly scopes the output as shadow research that never submits trades, signs payments, or uses an operator key. That is exactly the side-effect disclosure an agent needs for a non-readOnly, open-world 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?

Four tight sentences, each doing distinct work: what it does, auth requirement, cost/veto behavior, and safety scope. Front-loaded with the action and 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?

No output schema exists, and the description does characterize the return as a shadow research review, plus covers auth, cost, and safety for a mutation-adjacent tool. Missing only detail on the evidence payload format and what a review contains.

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 has to carry the load. It clarifies evidence (Cascade evidence) and model_spend_authorized (spend gate), but says nothing about instrument or observed_at semantics, nor the shape of evidence entries, leaving half the required parameters undocumented.

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 Jev jurors (by TypeSafe AI) over Cascade evidence, capped at five. It is clearly distinct from cascade_analyze/capsule/status by naming the jury mechanism, though it doesn't explicitly contrast itself with cascade_analyze.

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 one hard prerequisite (model_spend_authorized=true) and implies a BYOK key is needed, but never says when to reach for this over cascade_analyze or what evidence qualifies. Usage is implied rather than routed.

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=false, so safety is covered; the description adds genuinely new behavioral context by guaranteeing no model spend and no trade execution. It stops short of describing what state is reported or how fresh it is.

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 sentence with no filler, and the differentiating constraint (no spend, no execution) is placed where it is immediately visible. Nothing could be trimmed without losing signal.

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 and no parameters, the description is the only place an agent could learn what a "status" response contains, and it does not say. For a zero-argument inspection tool the cost/eafety profile is clear but the payload remains a mystery.

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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The schema is empty and fully specified.

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?

"Inspect Cascade Graph build/runtime truth" gives a verb and a resource, but "truth" is jargon that doesn't say what is actually returned (health? config? graph state?). The clause "without model spend or trade execution" usefully separates it from spending siblings like cascade_analyze, but the core deliverable stays ambiguous.

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 "without model spend or trade execution" implies this is the cheap, safe pre-check to run before costly siblings such as cascade_analyze or cascade_review_jev, but it never states that relationship explicitly or names an alternative. Usage is inferable rather than instructed.

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